75ccdc6147
These are not configuration but business logic, similar to the canonical names that are in NamespaceInfo.php, these must always exist and cannot be altered or unset. They were previously unconditionally assigned during all requests in Setup.php and passed down as "site configuration". Changes: * Move them to MessagesEn.php where they can be cached and processed the same way as other core-provided aliases. Document and confirm with tests that this is a mergeable attribute that follows the language chain. * Remove the duplicated code in a few places that was reading this variable + Language::getNamespaceAliases(), to instead just call the latter and move the logic there, centralised, and tested. In doing so I noticed that these were applied in an inconsistent order. Sometimes the config won, sometimes not. There's no obvious right or wrong way here, but I've chosen to standardise on the way that Language::getNamespaceIds() did it, which is that config wins. This because that method seems to be most widely used of the three (it decides how URLs and titles are parsed), and thus the one I least want to change the behaviour of. * Document that $wgNamespaceAliases may only be used to define (extra) aliases, it is and never was a way to access the complete list of aliases. Bug: T189966 Change-Id: Ibb14181aba8c1b509264ed40523e9ab4000fd71a
11 lines
192 B
PHP
11 lines
192 B
PHP
<?php
|
|
/**
|
|
* This the test fixture for a message file in the Example Bar language (x-bar).
|
|
*/
|
|
|
|
$namespaceAliases = [
|
|
'Cat' => NS_FILE,
|
|
'Cat_toots' => NS_FILE_TALK,
|
|
];
|
|
|
|
$fallback = 'x-foo';
|