Language handling

Created on 14 December 2022, almost 2 years ago

Updated 25 October 2023, about 1 year ago

Problem/Motivation

I'm currently creating ECA models on a multi-language site. I've noticed the following behaviors of Drupal core's language handling:

Determining the language to be used, is done with a language negotiator service. The language manager lets the negotiator do the negotiation, and then keeps the negotiated language in mind (some could say it's caching in-memory) for the rest of the whole PHP process.
The determination, which language is to be used, depends on the enabled and configured negotiators in the language.types configuration. There are various negotiators available, for example using a given langcode from URL, and/or the preferred language of the currently logged in user.
Besides the language manager, there are more services that affect the currently used language. For example, the string_translation service independently stores the language to use on its own. There is also another service "language.default" that provides the default language - also storing that on its own.

I had a requirement to setup a model that performs a queued operation to send out e-mails to multiple users, and each user may have a different preferred language. Of course the sent out mails need to be translated in the proper language.

Because of the described behaviors above, achieving this requirement was not an easy task. I ended up using a "helper action" that resets the in-memory cached negotiated language, and then switched to a different user with the according preferred langcode, and finally generated the translated mails.

This leads to some aspects I'd like to discuss here:

Shall we try to find a way to ease the handling of a current language? For example, providing an action that gets the current langcode, and another action that allows to set the current langcode? It should be noted though, that such an action may not look straightforward as multiple services are involved and need to be set or reset accordingly.
If so, should be create a new sub-module for that topic alone, like eca_language? In that case we might want to move the Translate action from eca_base to that new sub-module.
Does it make sense to provide a negotiator plugin that negotiates the current language via ECA? It should be noted though, that negotiation gets cached in memory, thus that plugin would be called usually only once per PHP process.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request

Status

Fixed

Version

1.2

Component

Miscellaneous

Created by

🇩🇪Germany mxh Offenburg

Live updates comments and jobs are added and updated live.

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment about 1 year ago →
🇫🇷France Toki Caen, Normandy
First of all, thank you for this module, it becomes more and more a "must-have" module in Drupal.

I had a requirement to setup a model that performs a queued operation to send out e-mails to multiple users, and each user may have a different preferred language. Of course the sent out mails need to be translated in the proper language.

I have the exact same case than you @mxh but I can't build the right model.
Do you mind sharing your solution or a few guidelines?

Some details : I am using Easy Email to send HTML emails and custom templates. Unfortunately they can't be translated through the Drupal configuration translation UI so I thought I can create two different email templates (one for each language) and then decide which one to send with ECA and user's preferred language.

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024