Page MenuHomePhabricator

LanguageConverter should not inspect global state to determine the variant
Closed, DuplicatePublic


Currently the determination of which variant is used by a Language object is done by LanguageConverter inspecting global state, including $wgUser and $wgRequest. There is no straightforward method for a caller to directly specify which variant should be used for a particular Language object.

Inspection of global state should instead be done before the Language object is constructed, for example in RequestContext::getLanguage() where it already inspects state (including request parameters and user preferences) to determine the language itself. The determined variant should then be passed to the Language object, which will use the passed value without further reference to global state.

While Language::factory() itself could do that global state inspection in the absence of the caller specifying a variant, and that would most straightforwardly maintain backwards compatibility, I (@Anomie) think that would be a poor interface to maintain long-term.

How to specify the variant on a Language object is open for discussion. Possibilities, not necessarily mutually exclusive, include:

  • Determining it from the $code passed to Language::factory(), e.g. Language::factory( 'en-x-piglatin' ) would select language 'en' using variant 'x-piglatin'.
  • Passing it as a separate parameter to Language::factory(), e.g. Language::factory( 'en', 'x-piglatin' ).
  • Having a setter on Language and/or LanguageConverter to change the variant after creation.

Original report, reformatted from bugzilla to Phabricator syntax:

See T34906#381134 and following comments. I (@liangent) made some attempts in gerrit 33969.

See Also: T59562: Stop using $wgTitle in LanguageConverter::autoConvert() subclasses



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:44 AM
bzimport set Reference to bz42240.
bzimport added a subscriber: Unknown Object (MLST).

Next step: move variant setting to ParserOption. Maybe have ParserOption accept a $context, then populate the variant setting from $lang->getPreferredVariant( $context ).

Barrier: there's not always some context available (eg. when parsing messages. Don't convert text in this case? That's bug 34832.) or language available (it's tied to title, and title is usually unknown when ParserOption is constructed...

SPQRobin might be interested. Adding to CC.

Krinkle added a project: Technical-Debt.
Krinkle set Security to None.
Krinkle removed a subscriber: Unknown Object (MLST).
Anomie renamed this task from Refactor LanguageConverter to decouple it from various $wg objects to LanguageConverter should not inspect global state to determine the variant.Jul 11 2018, 5:46 PM
Anomie updated the task description. (Show Details)
Anomie subscribed.