Webform rendering should use the content language, not interface

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

The last submitted patch, 20: 3175374-20.patch, failed testing. View results →

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 📌 Webform rendering should use the content language, not interface Needs review , 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.

zulljin → closed merge request !509

zulljin → changed the visibility of the branch 3175374-webform-rendering-should to hidden.

@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.