Config override language is in the general case different from interface language, but lacks cache context.
From #3446084-26: EntityTypeBundleInfo static caching is not language aware → :
> ::getConfigOverrideLanguage() always calls ::getCurrentLanguage() with no arguments, which always returns the current interface language
@catch: Yes, i used to belive this too, but it's a myth.
One thing is the difference between language negotiation and LanguageRequestSubscriber, and in the meantime a lot can happen (we can change this by making interface language negotiation setting ConfigLanguage instantly, but the current way of working might have reasons, and a change might have unforseeable consequences).
It's also that there are a lot of places where ConfigLanguage is **intentionally** changed. Look e.g. at ConfigurableLanguageManager::getNativeLanguages. It changes ConfigOverrideLanguage to retrieve the respective translations. And there are a handful of other places that do it like this.
In a well designed API, there would be sth like Config::get($name, $language) (TODO: add issue). But there is not, and so messing w/ global config language is the only way of getting the result.
And yes, this means essentially that there **should** be a ConfigOverrideLanguageCacheContext, and not having and using one is a design flaw. And indeed, in TranslationBliss module we maintain this cache context for exactly this reason. (TODO: Add issue.)
And yes, you are right, a proper memory cache (do we need variation cache?) would be the "proper" thing and (TODO:) i can add a followup for this.
- Creata a ConfigOverrideLanguageCacheContext (copy it from TranslationBliss module)
- use it in LanguageConfigFactoryOverride.
Do it, write tests, review commit.
None.
None.
None.
None.
New language_config cache context.
Active
11.0 🔥
configuration system
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
No activities found.