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();
}
Add a mechanism to ConfigurableLanguageManager to temporarily switch the render language to another value analogous to the switching of the language config override.
N/A
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;N/A
✄ TBD?
Show commandsStart 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:
changes
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 commentedComment #26
smustgrave commentedThis is looking good to me @mglaman as the original reporter what do you think?
Comment #27
mglamanFollowing up on #10 with a closer look at the MR.
The direction is right. A language override on the language manager beats exposing
TranslationManager::setDefaultLangcode(), and it keeps that method internal like @penyaskito asked.This should be a scoped API instead of a setter/getter pair:
With
setRenderOverrideLanguage(), every caller has to restore the language in afinallyblock. Nested overrides also break: passingNULLfalls back to the negotiated language, not the previous override.executeInLanguage()can save and restore the previous state itself, the same wayRendererInterface::executeInRenderContext()does.It should also cover everything needed to render in another language.
HelpTopicSectionstill callsLanguageDefault::set(). Commerce'sMailHandler::changeActiveLanguage()does too, plussetConfigOverrideLanguage(), to getTYPE_CONTENTand config translated. One call should handle all of that. Otherwise Commerce swaps one workaround for three.This needs a change record for the interface addition.
Comment #28
znerol commentedFixed BC and removed
getNegotiatedLanguagefrom the interface.Re #27
I think this MR should just provide the low-level API (analogous to the existing
setConfigOverrideLanguage()/getConfigOverrideLanguage(). There is #3536307: Execution environment: Safely run code inside an environment with partially substituted system state / config for a more generic high level API. In the long run commerce, search and mailer should be switched to that one.I think
LanguageDefaultshouldn't be changed at all. I cannot reconstruct whether the call toset()was necessary at the times of #2664830: Add search capability to help topics, but nowadays it isn't. I removed the dependency and verified the result manually (with the ex core search module which recently moved to contrib).Comment #29
znerol commentedAdded a change record.
Comment #30
nicxvan commented