Drush does not implement language negotiation

[zaporylie]

Describe the bug In the HTTP Request context, the translation_manager's default language is set via LanguageRequestSubscriber but in CLI context this doesn't seem to happen. I observed this when I've noticed that all emails sent with Drush don't follow the current (negotiated) language.

Not sure whether this should be a core or drush issue but imho should be fixed in one of those 2 places (probably here).

To Reproduce

• Set English as the default site language. (/admin/config/regional/language)
• Add language negotiator that will unconditionally resolve another language as current (/admin/config/regional/language/detection)
• drush ev "var_dump((string) t('Front page'))" <- string should be translated but it is not

Expected behavior When casting TranslatableMarkup to string, the text should be in the current language, as resolved by language_negotiator.

Actual behavior When casting TranslatableMarkup to string, the text is in the site's default language.

Workaround Adding the following to DrupalBoot8 did the trick:

        /** @var \Drupal\Core\Language\LanguageManagerInterface $languageManager */
        $languageManager = \Drupal::service('language_manager');
        /** @var \Drupal\language\LanguageNegotiatorInterface $negotiator */
        $negotiator = \Drupal::service('language_negotiator');
        $negotiator->setCurrentUser(\Drupal::currentUser());

        if ($languageManager instanceof ConfigurableLanguageManagerInterface) {
            $languageManager->setNegotiator($negotiator);
            $languageManager->setConfigOverrideLanguage($languageManager->getCurrentLanguage());
        }
        $translation = \Drupal::translation();
        $translation->setDefaultLangcode($languageManager->getCurrentLanguage()->getId());

one can also install this drush plugin: https://github.com/zaporylie/drush-current-language

System Configuration

Q	A
Drush version?	9.7.2
Drupal version?	8.9.3
PHP version	7.3
OS?	Linux

Additional information Add any other context about the problem here.

[weitzman]

I'm not sure Drush core needs to care about language negotiation. Perhaps @Sutharsan has input?

[zaporylie]

Not sure. For me the issue is though the following:

$ drush ev "var_dump(\Drupal::languageManager()->getCurrentLanguage()->getId()); echo t('Front page');"
/var/www/html/vendor/drush/drush/src/Commands/core/PhpCommands.php(29) : eval()'d code:1:
string(2) "nb"
Front page

Please notice that there's a mismatch between the resolved current language and the language in which the string is printed. This is taken care of in Drupal Core here: https://api.drupal.org/api/drupal/core%21modules%21language%21src%21EventSubscriber%21LanguageRequestSubscriber.php/function/LanguageRequestSubscriber%3A%3AsetLanguageOverrides/8.9.x

[Sutharsan]

I think this is opening a can of worms, let's not do it thoughtlessly. Language negotiation depends on context, your example code uses the user. But there are more scenarios one should consider. Two I can think of now: 1. config:export exports in the default language, but what about forcing it to English. In my experience multilingual sites that don't use English as default language could benefit from this. 2. Entities created via Drush, for example with user:create are created in the default language, but there may be use cases where you want to change this.

As far as I can find out now, Drush uses the default language. Which I think is a good starting point (as it has proven to be). Core's language negotiation is specific for the web interface, and many options do not apply to CLI (URL, session, browser).

I think there is room for a better control over the Drush language, but it should work with different 'contexts' than Drupal core. It should work with default language, interface language and, although of a lower priority, content language too. Whether or not this should be in Drush core, is not up to me. But I think a separate (new) project could do the same and has the freedom to investigate the various use cases and scenario's it should support.

[geek-merlin]

We are having an ugly bug here, that maybe is related:

Wrong language field labes, (only) after drush cr [#3221375] | Drupal.org

Unfortunately, @zaporylie's pre-command hook component linked above does not fix the issue, nor did some derivatives i made (that e.g. alway bootstrap full).

[daften]

Why was this closed? Is this something that won't be fixed or does this not happen? Cause we have an issue regarding webform data export through drush where this is the basis of the problem.

[sakonn]

I agree that this issue should be reopened and resolved in some way. I am using drush to export products from commerce site. I have multilanguage site where every language has own domain so I am using domain as negotiation for correct language. Also I am using currency exchange module to resolve correct currency and price based on language. The title and content feeds are exported proprerlly but currency is not resolved properlly since the exchange module use language manager to get current language which is then used to resolve correct currency and price. So when the export is run through the drush language is not resolved correctly.

The plugin mentioned in issue description worked fine for me.

[Pasqualle]

I have the case when a non-English website is developed by a big international team. Everything is translated from English, but the default language is not English. English is not even available for anonymous users. I would really like to use drush in English, otherwise I don't understand the errors from drush. Simple variable to set drush language would be sufficient for me.