Proposed by @pounard in #1763640: Introduce config context to make original config and different overrides accessible:

+    // If there is a user set in the current context, set the language based on
+    // the preferred language of the user. Otherwise set it based on the
+    // negotiated interface language.

Problem is, it actually should be If there is a user set in the current context stack? I don't see the point if not, this means that any code at any moment can break any context: for example if I am displaying a node, and I have a NodeContext, and the node context doesn't give any language, my langauge manager would revert the current language to default, and forget the user provided one, but I could still want to display field labels within the node using the config translated labels.

The context free context is non existant per definition, instead of fetching a context free context-config we should fetch a real context-free-config (i.e. a config object with no context set, i.e. null or a null implementation, or a global state default context or whatever). Entering a non context is not entering a context, but fetching the instance outside of any context, a non-context should not be stacked into contextes?

I understand how it works, and what it does, but it still sounds very weird to proceed like this. For forms, for example, what you need is a context-free raw instance, but for building the form you might want the context-full config instance at the same time (for example, a context-full instance for fetching a translated form element title, while the context-free instance would give you the non translated value to put into the exact same field). With the current stack having both at the same time seems not possible.

Postponed for now on resolving #1929136: Fix override-free context, move global config overrides back to an event listener first.


mtift’s picture

alexpott’s picture

Status: Active » Closed (won't fix)