Currently the ParserCache is split over the language variant via heavy use of globals:
- ParserOptions::optionsHash which stringifies the used ParserOptions to be used as the ParserCache key is using global state to retrieve the page language and get a language converter for it. It calls LanguageConverter::getExtraHashOptions on the converter and appends that to the key.
- LanguageConverter::getExtraHashOptions for languages that support variants is calling LanguageConverter::getPreferredVariant, which uses global $wgRequest to figure out what variant was requested.
This system magically works because Parser independently calls LanguageConverter::convert which as well uses the getPreferredVariant and global state to figure out the necessary language variant.
The two places need to be kept in sync, and it seems they are not, for example, ParserOptions::getDisableContentConversion is not respected in ParserOptions::optionsHash, unnecessarily splitting the ParserCache on language variant when the variant conversions might have been disabled. There probably are other bugs in this system.
Instead, neither ParserOptions nor Parser should use global state to find out the language variant.
The following needs to happen (not exact plan, a rough straw man)
- target variant should become a cache-splitting ParserOptions key. It should be set automatically when ParserOptions::newFromContext is called, and all the calls that require language conversion have to use the correct way of constructing the ParserOptions
- Parser should take the target language variant from ParserOptions and not from global state
- ParserOptions shouldn't append language variant from global state to the key.
- LanguageConverter::convert should be deprecated and replaced with LanguageConverter::convertTo