Problem/Motivation
For the life of me, I have no idea what component an issue for items under the `Core\StringTranslation` would belong to. There is no "translation system." I am assuming "base system."
\Drupal\Core\StringTranslation\TranslationManager implements \Drupal\Core\StringTranslation\TranslationInterface and \Drupal\Core\StringTranslation\Translator\TranslatorInterface.
When constructed it sets the langcode to be used in translations from the language ID derived from the default language service:
public function __construct(LanguageDefault $default_language) {
$this->defaultLangcode = $default_language->get()->getId();
}
That means if the default language is ever changed, the translation manager's langcode is never updated.
There is, however, the \Drupal\Core\StringTranslation\TranslationManager::setDefaultLangcode method. This allows changing the default language code for the translation manager (ie: updating to match the changed default language.) The problem is that this method is not on any of its implementing interfaces.
In order to provide a translation that is different than the site's current language (ie: destination email, something over cron or CLI) you need checks like:
use StringTranslationTrait;
$string_translation = $this->getStringTranslation();
if ($string_translation instanceof TranslationManager) {
$string_translation->setDefaultLangcode($language->getId());
$string_translation->reset();
}
Proposed resolution
Add a mechanism to ConfigurableLanguageManager to temporarily switch the render language to another value analogous to the switching of the language config override.
Remaining tasks
- Review
- Commit
User interface changes
N/A
API changes
API additions:
Drupal\Core\Language\LanguageManagerInterface
public function setRenderOverrideLanguage(?LanguageInterface $language = NULL, $type = LanguageInterface::TYPE_INTERFACE): static;public function getRenderOverrideLanguage($type = LanguageInterface::TYPE_INTERFACE): ?LanguageInterface;
Data model changes
N/A
Release notes snippet
✄ TBD?
Issue fork drupal-3029003
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
mglamanComment #13
smustgrave commentedThis came up as the daily BSI target.
Checking TranslationManager and this still seems to be the case.
Would be +1 for adding to TranslationInterface
May be a good novice task as the summary is pretty clear (does need solution cleared up if agreed upon)
Comment #14
penyaskitoIf you need to translate a string, you can pass
$options['langcode']totranslate()/t().For config,
\Drupal\Core\Language\LanguageManager::setConfigOverrideLanguage.I agree we could document this better. But this is not an overlook.
Setting the default language happens:
\install_begin_request)\Drupal\language\EventSubscriber\LanguageRequestSubscriber)\Drupal\help\Plugin\HelpSection\HelpTopicSection::renderTopicForSearchfor indexing help topics, which are twig templates, but not actually Drupal templates)This is not in any interface because you are (almost) never supposed to call it. This is the most low level part of the translation system.
Comment #16
mglamanSee the linked issues. This is about rendering in a different language. We can change and retitle it if this isn't the right approach.
It's like renderInContext but if we could substitute a language in that one context. Or like wkrkspace has a way to execute in or out of a workspace.
Drupal Commerce has this hack still to allow emails to go into a user's language vs the current site language when rendering the template (not just input strings from config)
Comment #17
penyaskitoMissed those, sorry!
I'd rather add a new
\Drupal\Core\Language\LanguageManagerInterface::setDefaultLanguage()than exposing this one.Comment #18
gábor hojtsyHm does this mean that it is not possible to set the options language and be applied to what it needs to, we need to globally set the language manager language too? I think setDefaultLanguage() could be confusing if used generally dynamically because it does not persist.
Comment #21
znerol commentedOpened an MR, no tests yet. Looking for feedback from reporter and maintainer whether this is going into the right direction.
Comment #22
mglamansetRenderOverrideLanguage on LanguageManagerInterface is the right surface for this API since the naming clearly signals a temporary contextual override, it eliminates the instanceof TranslationManager workaround that projects like Commerce have long relied on. +1 from me
Comment #23
smustgrave commentedThanks for following up @mglaman
@znerol does that help? Besides tests not sure if major tweaks are needed.
Comment #24
znerol commentedComment #25
znerol commented