$wgContLang will be replaced by a service called ContLang or some similar name.
It may be best to only soft-deprecate in the initial commit, considering about 320 files in Gerrit-hosted extensions refer to the global. This means adding @deprecated to its doc comment in Setup.php.
166 files in core refer to $wgContLang. Ideally they should be updated to use the service.
Tests that use MediaWikiTestCase::setMwGlobals() can be migrated to use setService().
$wgParser is a prior example of this kind of project, but there are some issues with it which make it not an ideal example to follow. StubObject replaces the global variable with a direct object reference on the first __call() invocation, which is nice for type hinting and performance, but it means that to set the service, both the global variable and the service itself need to be reset. Existing test cases fail to do this correctly. For example, MessageTest just sets $wgParser with setMwGlobals() and apparently neglects to set the service with MediaWikiTestCase::setService(), meaning that the test would fail if MessageCache were migrated to use the service.
Implementation options for $wgContLang initial assignment:
- In Setup.php have simple assignment $wgContLang = MediaWikiServices::getInstance()->getContLang();.
- In Setup.php set $wgContLang to a StubObject similar to $wgParser
- In Setup.php set $wgContLang to a new kind of object proxy which forwards calls to MediaWikiServices::getInstance()->getContLang() without replacing the global
If 1 or 2 is used, the following implementation options for keeping $wgContLang in sync with the service occur to me:
- Introduce MediaWikiTestCase::setContLang() which will call both setMwGlobals() and setService()
- Have MediaWikiTestCase::setService() call setMwGlobals() if ContLang is to be set
Ultimately, I imagine $wgContLang will be hard-deprecated, by setting it to a DeprecatedGlobal or similar, allowing it to raise a deprecation warning when it is used. But that can be left for another subtask of T160815.