Requests for comment/Associated namespaces

MediaWiki namespaces were introduced more than 10 years ago. In addition to the built-in namespaces, each extension adds its own namespaces. There are no hint about how namespaces relate to each other.

As the number of namespaces and their inter-relationships increases, there is the need to know how namespaces relate to each other. It is an easy task to hardcode when each namespace has only odd numbers as an associated namespace (e.g. ns0 and its talk page), but what if it is wanted that each namespace has several more namespaces associated to it? As complexity increases, so becomes more difficult to manage it just with code.

Use case 1: Associated structured data
As structured data becomes more popular, it will be helpful to have associated data namespaces. For instance, a MediaWiki installation could have an associated structured data namespace for the  namespace, where metadata could be stored – something like. Similarly, a wiki might want to have arbitrary data against NS0 pages.

Use case 2: Template documentation
In addition to their associated Talk page, templates are usually documented in another page, but there is no programmatic hint about this association anywhere. Instead, users are expected to remember that a  template or similar should be used, putting documentation on a page like   or similar.

With a properly associated "template documentation" namespace, this documentation could be used more readily, and users could be actively encouraged to put documentation about a template in the right place.

Use case 2b: Structured template documentation
The TemplateData extension, used by VisualEditor, currently inserts a JSON blob between the  parser tags, and thus a huge number of page properties; a much cleaner way for storing it would be in a Template data: namespace, set as a proper ContentHandler JSON namespace, automatically available to each Template without mixing content (documentation), coding information (TemplateData) and sub-templates (navigation structure) in one page.

This would thus give a way to indicate that NS_TEMPLATE has associated namespaces: ,  ,  , and any other further additions.

Related discussions

 * there is an unused "namespace" table 52929
 * some users would like NOT to have Talk pages associated 33298
 * should TemplateData be a special namespace combined with ContentHandler? 54140
 * How Commons should deal with TemplateData
 * Requests for comment/Custom inter-namespace tabs
 * Extension:NamespaceRelations
 * Having a "Namespace manager" in MW core, closed as WONTFIX due to lack of interest 7803
 * Namespace manager (obsolete)

Proposals
How do you think this issue should be approached? Write your proposal below.

Namespace registry and association handlers
I've not only been worried about the association of two namespaces (see e.g. TemplateData and Template, especially in my conversation on Commons about the same) but also about the nasty hard-coding of namespace ID numbers. Let's instead let MediaWiki itself govern which IDs are taken and which are not, and add functions to core for determining the status of each ID, and their canonical names. We already have those canonical names IMO - the English namespace names, that is - so this shouldn't be much of an issue.

Let's have a sane way to register namespaces in extensions and abandon the old hard-coded constant way. --MarkTraceur (talk) 23:31, 17 March 2014 (UTC)