Webform rendering should use the content language, not interface

I think most people are expecting or are used to a Webform using interface language translation.

I could see us implementing "Add checkbox to allow of content language rendering."

A few thoughts...

• The "Add checkbox to allow of content language rendering." should be a global behavior.
• Maybe this could be implemented as a dedicated contrib module

I am not exactly sure who we would go about implementing content language rendering for a webform. If you could provide some sample code it would help me understand the complexity of the solution.

I think interface and content translation should use the same detection method because content may be rendered with interface translations like the label for a "back to top" link in a TOC.

I think this should be handled in a dedicated contrib module or custom code

Any news here? Is there any module or tip for custom code which handle this?

Do we still have no options for webform to show the content language and not the interface language?

@jrockowitz are you open to discuss reopening this? (see below)

I think you closed this as you didn't experience this issue yet, and it wasn't described well, why the form should be displayed in content language (user selected language) and not in interface language?

Let me try to explain why I think this is important for multilanguage sites and should not be contrib or custom code:

Why separate languages?

Having a multilang site, for example being a company in Germany with website translated to English and Czech, you typically want:

• Visitor content language selection in the frontend, changing the URLs to /de/... | /en/... | /cs/....
• Admin / site owner / ... interface language selected in the Drupal user profile as he / she might not speak (or understand) Czech or English!

So you split interface (administration ui) from content language (frontend). See the screenshot below for a typical best-practise configuration to have admin language (interface) split from content language (visitor language selector / URL):

Why should webform use content language (in the form display)?

Webform currently seems to only use interface language, which is correct for administrative pages, but not the form displayed to users. This leads to a combination where all texts on the page are displayed in content language but the form is displayed in interface language.

This is simply wrong and not a special case. So for the webform rendering the content language variable should be used. Anyway, if content language special handling switch (see screenshot) is off, both are the same and the variable falls back to the interface language.

Hope my explanation can be understood? Otherwise, please let me know for further explanations :)

I understand the explanation. I am not seeing how we can support the content's language. I could use some guidance.

I am fine with reopening this ticket but I might not have the bandwidth to commit a patch that does not include test coverage and a significant amount of code review.

Hey @jrockowitz,

thank you very much for your super-fast reply! I think we should perhaps have some others have a look at this and wait for further feedback. I'd like to be sure that I understood and configured everything correctly before we start coding here.

If you should have any ideas how this could be solved or where the relevant language variables are set in webform code, please leave your notes. I'll to the same. Also if you should talk to anyone who's more experienced with these separated language options, perhaps he could have a look. Thanks a lot! :)

This can be managed with the language manager.

// instead of getCurrentLanguage with default param
$language = $this->languageManager->getCurrentLanguage();
// use method with param "LanguageInterface::TYPE_CONTENT". 
$language = $this->languageManager->getCurrentLanguage(LanguageInterface::TYPE_CONTENT);

Whenever a webform is rendered, the current language must be retrieved beforehand. This is also done in Webforms with the LanguageManager. I suspect, the only thing that is required, is that the parameter must be entered everywhere in the getCurrentLanguage function.
I know Webforms is very complex and maybe my guess is naive.

Thank you very very much for your help @JFeltkamp! @jrockowitz as you might know the points where the language is fetched - what do you think about that change for the end-user display of the form? Possible?

@Anybody, re: #9 - OMG YES!! You have no idea how much trouble i have explaining to people on Drupal what "content" is. My clients on the other hand, all, 100% agree that typical users should see everything as content.

My site is almost perfectly set this way where basically users (anon or auth) see that site in the content language based on the url prefix and editors/admins can set interface language in their profile so that they can work on the site without having to know 5 different languages.

I use the code similar to what is mentioned in #13 for handling block config elements that should be seen as content - combined with setting $language_manager->setConfigOverrideLanguage($language); Views is the one bright spot in Drupal core that lets you handle most things as required by simply setting render language as required. The tranc module also helps things a lot.

All that being said, i have now hit the webform blocker for this. Has this issue gone anywhere? It is listed as Needs Work; but has no patches.. so i think that means Active. Was someone going to look at adding option and then using that in webform's LanguageManager as mentioned in #12?

Thank you for your feedback @liquidcms! Totally agree. Same for us... still a technical solution has to be found here, correct.

I assumed no one is looking at this anymore so i took a look last night at the code. Didn't see obvious place where language is being set. Likely will get back to this within next 2 weeks to come up with a solution (assuming someone doesn't beat me to it).

Right now it looks like as Anon, no translation is done at all (not even using Interface language, which, as Anon is the same as Content language). But different issue.

The error persists, always showing the language of the interface instead of the language of the content

All the calls in the various module files are:
languageManager->getCurrentLanguage()

instead of:
getCurrentLanguage(LanguageInterface::TYPE_CONTENT)

where the language of the content is specified.

Ive been trying to resolve this with form process and since our editors add webforms via paragraphs Ive even tried to see if I could get the translated webform from a paragraph preprocess but no luck. Cant find any methods that allow to set language on the webform either.

This is a pain point our editors and translators have been having since they can not accurately review translated pages with webforms in them before publishing. When user is logged in all content on page is in the page language except the form.

Currently the pages have to get published and a translation reviewer has to be logged out so they can review the full page in expected language.

Im at a road block on how to proceed resolving this but just wanted to chime in and follow this issue.

The attached patch adds a new checkbox to both the global configuration and the webform entity settings form under a new group called "Multilingual".
This adds the ability to force all webforms to be rendered using the content language, or to select specific webforms to be rendered using the content language.
This is an old issue and I really hope this gets merged soon.

Webform entity settings

Global configuration

Updated forms settings and schema for tests to pass.
Next step is to add a test for this new functionality.

I applied the patch to V6.1.x by removing all the hunks for test files.

Generally speaking, this patch works like charm! Thanks for the work. :-) I have some improvements, since the functionality can be confusing.

I think it's not clear enough that the global settings overrides all webform-specific settings. This could be improved. When the global setting is set to content language, the webform-specific setting should be disabled. Otherwise I would expect, that the specific setting overrides the global config.

Or to have a third option in the webform-specific setting like this (which I prefer):

• Use global setting - Default
• Use Interface language
• Use content language

Hi @droprocker,

Thank you for your feedback.

The patch follows the general implementation of webform config/settings.

Referring to

When the global setting is set to content language, the webform-specific setting should be disabled.

In fact, this is the case as shown in #20, you have the following options:

• If you have multiple webforms and you need all of them to use the interface language, you can just keep both checkboxes unchecked (global and webform-specific).
• If you have multiple webforms and you need all of them to use the content language, you will need to check the global checkbox and as a result, the checkbox inside each webform-specific settings will be disabled.
• If you have multiple webforms and you need only some of them to use the content language instead of the interface language, then you will need to keep the checkbox in the global settings unchecked, and check the checkboxes for the webforms you desire to render in the content language inside the settings of each of them.

Since the implementation of the current patch covers all use cases, I don't think there is a need for what you suggested lastly:

Or to have a third option in the webform-specific setting like this (which I prefer):

• Use global setting - Default
• Use Interface language
• Use content language

Plus, going with such suggestion will create an inconsistency in the UX since other settings work exactly this way (the way that the current patch is implemented).

On a side note, neither the webform-specific checkbox nor the global checkbox will be available unless the site is multilingual.

Added compatibility with 6.2.0-rc2 version.

@Zulljin could you perhaps prepare this as MR?

Thank you very much! #26 applies perfectly and resolves the issue rendering the form using content language (in my case url).

I still have issue with confimrations emails. The form values are translated but the subject/body and other fields are still using default language. Has anybody else encountered the same issue?

1) Thanks! I can confirm that the latest patch from #26 (3175374-23.patch) works against Webform version 6.2.

I came across this issue after a bit of searching as I couldn't quite figure out why my webforms' translations were not getting applied. There is definitely a need for translation based on content as I would've had to take a different approach for translating our site. My use case is that only certain content types from our native French website are offered in English. The rest of the site, we simply offer Google translation.

2) As per @gbotis, I've noticed the same issue with the patch where specifically the subject, the body and the confirmation message cannot be translated. Happy to test out any future patches.

I'd like to offer up an solution that seems to have worked nicely for my use case without the need for a patch. Perhaps this will work for others.

No issues with content translation with Webform when using the following language and detection configuration:

• Interface text language detection: Session enabled
• Contenu language detection: Session enabled

Previously I did not have an option enabled for "Interface text language selection" and only had "Content language" enabled for "Content language detection". Now, with both having "Session" enabled, everything works as expected and cleaner URLs (?language=en vs using ?language_content_entity=en and does not get added to the default site language).

#31 isn't a real solution. If webforms are used as content and content and interface language differ (for example interface language English for Chinese content language), the webform will display in English while Chinese is expected.

This is by design and can only be fixed in code by adding a setting or sth. like that as proposed.

The patch still needs to be turned into a MR for review.

@anybody, MR is ready: https://git.drupalcode.org/project/webform/-/merge_requests/510

Thanks @zulljin that looks like a good first step. I left a comment and tests are failing that need to be fixed. Also tests for the new functionality need to be added.

Maybe insted of the checkbox we should be more clear here and use a select for

• Content language
• Interface language

selection?