Problem
There isn't a way to determine if a wiki namespace is a default namespace or not and it is not documented what even makes a namespace a default namespace.
Use case
For software to interact with a (page namespace ID, page title) pair and know whether it is safe to localise in the current wiki context. If the namespace ID is from an extension, then this may be something else on a different wiki, or not expected to exist locally, and thus should not be localized.
See also T200938
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Move list of core namespaces to NamespaceInfo | mediawiki/core | master | +40 -19 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | TheDJ | T190350 Epic: ⚡️ Partial blocks | |||
| Open | None | T226651 Replace local namespaces with real links on Special:CentralAuth | |||
| Open | None | T229895 Refactor user management logic into a UserManager service | |||
| Open | None | T238235 Update API meta=globaluserinfo to include the same blocking info on the special page | |||
| Resolved | dbarratt | T200938 Special:CentralAuth should provide the same blocking information as Special:BlockList does | |||
| Resolved | dbarratt | T226657 Add a mechanism to determine if a namespace is a default MW namespace |
What would be the purpose of this?
FWIW, I always understood the term "core namespaces" to be the 18 namespaces found in Defines.php in MediaWiki core.
In T200938 we needed to know whether a namespace was in core or not, we ended up hard-coding the above logic into MediaWiki-extensions-CentralAuth
The term default namespace is not defined and does not seem to cleanly map to any existing implicit or explicit concept.
There are really three kinds of namespaces:
| Type / Feature | Configured in | Always present | Always same id | Has canonical name (English) | Localisation |
| MediaWiki core namespaces | MessagesEn.php | Disabling these is unexpected and causes bugs. New ones could possibly be added, not present in older versions. | Yes | Yes | MessagesXX.php |
| MediaWiki extension namespaces | Usually extension.json | Depend on enabled extensions and their configuration | Can sometimes be overriden | Yes | Namespaces.i18n.php + hooks |
| User configured namespaces | LocalSettings.php (and equivalent) | Only if configured | It depends. At WMF this is not consistently done | Only if explicitly added | Difficult – in practice not done to my knowledge |
So in this use case, the requirement is to know which of the namespaces in another wiki in the wikifarm are "Always present" and "Always same id" so that they can be shown "Localised". Only the core namespaces and the extension namespaces of extensions that are always loaded [1][2] satisfy this criteria.
[1] If extension is not loaded, we cannot load namespace i18n. Namespace itself doesn't need to be enabled I believe.
[2] Assuming the ids are consistent across the wiki farm.
For naming the concept, I suggest something that relates to the requirements "Always present" and "Always same id".... stable, permanent, fixed, pre(set|configured|defined)...
PS: I wish that I could turn off some of the core namespaces, such as help and NS_PROJECT, that are often unused and just make the list of namespaces longer and less useful.
This seems wrong:
return $index < 90 && $this->exists( $index );
Why 90? The convention is to start extension namespaces at 100. But it's just a convention, nothing prevents a wiki from seting up a custom namespace with index 22. It would be much better to have the definitive list of core namespaces defined in code. It's currently hard coded in Setup.php for initializing $wgCanonicalNamespaceNames, but $wgCanonicalNamespaceNames then gets modified to include extension namespaces as well. That logic should probably move from Setup.php into NamespaceInfo.php. That would break any code that relies on the $wgCanonicalNamespaceNames global directly (or via a Config object), but at least in core, I see no such code.
Because of LiquidThreads:
https://github.com/wikimedia/mediawiki-extensions-LiquidThreads/blob/b8f8d6ac918c69ad35071cf878568da33df1f7a4/extension.json#L15-L36
It would be much better to have the definitive list of core namespaces defined in code. It's currently hard coded in Setup.php for initializing $wgCanonicalNamespaceNames, but $wgCanonicalNamespaceNames then gets modified to include extension namespaces as well. That logic should probably move from Setup.php into NamespaceInfo.php. That would break any code that relies on the $wgCanonicalNamespaceNames global directly (or via a Config object), but at least in core, I see no such code.
That seems like a good solution to me.
Change 526293 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Move list of core namespaces to NamespaceInfo
It's worth noting that at least one extension has custom namespaces with IDs under 90 (in fact, it assigns the IDs 16 and 17!); see a complete list (as far as known, at least). Though whether this matters for the use case here depends on whether the use case here cares about non-WMF wikis, since AFAICT WikiLexicalData is not installed on any WMF wiki (so I guess that depends on whether CentralAuth sees any real non-WMF use).
Based on the comments in T226657#5288518 it seems better to have an explicit list of "core" namespaces which is what I've implemented in https://gerrit.wikimedia.org/r/#/c/526293/
Change 526293 merged by jenkins-bot:
[mediawiki/core@master] Move list of core namespaces to NamespaceInfo
The change appears to be functionally equivalent to what we had before.
For what it is worth, mw-config/index.php, part of the web-based installer, uses the $wgCanonicalNamespaceNames global variable. I was able to use the web installer to setup a wiki without problem.