Page MenuHomePhabricator

Add a mechanism to determine if a namespace is a default MW namespace
Closed, ResolvedPublic

Description

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

Details

Related Gerrit Patches:

Event Timeline

dbarratt created this task.Jun 26 2019, 5:50 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 26 2019, 5:50 PM

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.

What would be the purpose of this?

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

Krinkle renamed this task from Add a mechanism to determine if a namespace is a "core" namespace. to Add a mechanism to determine if a namespace is a default MW namespace.Jun 26 2019, 9:01 PM
Krinkle updated the task description. (Show Details)
Krinkle added a subscriber: Krinkle.

I've summarised the use case, please verify that I understood it correctly.

I've summarised the use case, please verify that I understood it correctly.

I believe so!

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 / FeatureConfigured inAlways presentAlways same idHas canonical name (English)Localisation
MediaWiki core namespacesMessagesEn.phpDisabling these is unexpected and causes bugs. New ones could possibly be added, not present in older versions.YesYesMessagesXX.php
MediaWiki extension namespacesUsually extension.jsonDepend on enabled extensions and their configurationCan sometimes be overridenYesNamespaces.i18n.php + hooks
User configured namespacesLocalSettings.php (and equivalent)Only if configuredIt depends. At WMF this is not consistently doneOnly if explicitly addedDifficult – 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.

daniel added a subscriber: daniel.EditedJun 27 2019, 10:14 AM

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.

dbarratt added a comment.EditedJun 27 2019, 4:28 PM

Why 90? The convention is to start extension namespaces at 100.

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.

kchapman added a subscriber: kchapman.

Untagging TechCom as solution is straight forward and does not require RFC.

Change 526293 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Move list of core namespaces to NamespaceInfo

https://gerrit.wikimedia.org/r/526293

dbarratt updated the task description. (Show Details)
dbarratt updated the task description. (Show Details)
dbarratt updated the task description. (Show Details)
dbarratt updated the task description. (Show Details)

Why 90? The convention is to start extension namespaces at 100.

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.

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).

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/

matmarex removed a subscriber: matmarex.Jul 30 2019, 7:21 PM

Change 526293 merged by jenkins-bot:
[mediawiki/core@master] Move list of core namespaces to NamespaceInfo

https://gerrit.wikimedia.org/r/526293

dom_walden added a subscriber: dom_walden.

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.

dbarratt closed this task as Resolved.Aug 15 2019, 2:26 PM