In general, I recommend against adding new mw.config variables with the exception of doing so as a significant and measurable performance optimisation for highly visible functionality. I leave it up to Parsing Team and Language Engineering to understand whether wgUserLanguage, wgContentLanguage, and wgPageContentLanguage is suffcient or whether there truly is a need for a fourth one. I don't have the needed context and understanding in mind to assess this.

It seems like three ought to suffice for everything to work right, including one that is appropiate for things like jquery.tablesorter (and other functionality that relates to the language of the displayed content) to do its job correctly. But if someone can explain/document on https://www.mediawiki.org/wiki/Manual:Interface/JavaScript#mw.config what these three variables mean in a way that myself and most core and extension devs will understand when to use them and when not, and then make the case for the missing fourth, I won't stand in the way :)

\cc @cscott as per involvement on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/769394 and as knowing LanguageConverter variants well, which I think is what this fourth variable is meant to solve?

So PageContentLanguage is definitely misnamed: the page language is *never* a variant. Only the user interface language can be a variant. I'm in favor of renaming/deprecating in order to clarify this, because it can be very confusing and not many folks know the differences. How exactly is PageContentLanguage different from UserLanguage?

I'm in favor of exporting the LanguageFactory::getParentLanguage() functionality to the client rather than tempt them to try to do language code parsing client side, and it seems like it makes sense to start by just exporting :getParentLanguage(<user interface language>) under some name.

In T326997#8641093, @cscott wrote:

How exactly is PageContentLanguage different from UserLanguage?

Well, real "page content language" can be retrieved via $title->getPageLanguage();, and "user language" is unrelated to the page.
And the wgPageContentLanguage for now is "page view language", which is one of the variants of "page content language". It can be changed e.g. via the uselang= query string.

it seems like it makes sense to start by just exporting :getParentLanguage(<user interface language>) under some name.

Then that is yet another thing. I think we'd better focus on "page content language" in this task to avoid more confusion.

(table sorting would not be affected)