Language handling

Issue information

From user: mxh

Related to !283 (merged)

Contribution record

Fork management

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