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 hard-coding it.

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 (54140 / 50512), 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
 * MediaWiki should use a reservation system for namespaces 31063
 * 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)
 * w:en:Wikipedia talk:VisualEditor/TemplateData
 * VisualEditor/TemplateData
 * w:en:Wikipedia:Village pump (technical)/Archive 115

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)
 * +1 to moving quickly away from hard-coded constants for namespaces. Sj (talk) 00:05, 2 May 2014 (UTC)


 * Proposed database schemas, as discussed on Architecture meetings/RFC review 2014-04-23 --Micru (talk) 17:26, 25 April 2014 (UTC)

Longer-term: making namespaces a multivaluable property for context?
In the long term I think we would be better to replace hard-coded namespaces with tags. The structure of 'namespaces' and 'Projects' is at heart a multivalued context, rather than an absolute combination of contexts. Examples:
 * MediaWiki already thinks about namespace and wiki selection similarly in interwiki links, using the same sort of "prefix + :" syntax to indicate wiki-context that we do to indicate namespace-context.
 * ( talk [namespace] ) is a tag that can be combined with most other namespace tags. It's always been awkward that we generate new combination-namespaces for this.  And the context of a page can change over its lifecycle.
 * A subpaged analysis/discussion of the 5 pillars (english, wikipedia, project), "Five Pillars") might get refactored and published, and identified with a canonical "Commentary on 5P" (english, wikisource, main).
 * A draft randomly created in (english, wikipedia, user, talk) might move to (english, wikipedia, main) or to (meta, english, main).
 * Some combinations of contexts should resolve to the same page, even though currently they resolve to different URLs. (see most File: pages, Help pages; see also

For a more consistent conceptual model -- parallel tag systems could be used for namespace disambiguation (context clarification) and for title disambiguation (meaning clarification). So you could have
 * Name: the simplified title to by which the topic is referred in its [articles].
 * Display Name: the current ('fully'-disambiguated) title, which does not conflict with any other Display Name.
 * (Aliases): the set of all names that redirect to Name
 * (Meaning Qualifiers): all of the qualifiers that could apply (e.g., be used in a Display Name)
 * (Context Qualifiers):  all of the qualifiers that explain the page context (e.g., "Talk", "Project", "Commons", "Wikisource", "Wikivoyage", ...)

How many of the meaning qualifiers have to be added to a Name to get the Display Name may depend on how dense namespace collisions are for this topic. So pages ["Help", Talk, Help, Commons] and ["Help", Talk, Project, Wikivoyage, English] and ["Help", Talk, Project, Wikipedia, English] would all be similar: discussions by a community of practice about their main Help page.

Namespaces are also often interchanged with subpages. For instance: we created a whole 'Help' namespace for help pages on many wikis. We could just as well have created a separate 'Help' wiki (just as we created a separate 'File' wiki for all files, and just as we probably should create a separate 'Template' wiki for all templates). Similalry we currently have "docs" as subpages of templates, and that's being considered for a namespace above.

Rather than thinking of these shifts as "spinning up a new namespace" (or in the case of files and templates, "spinning up a new wiki") we could instead move towards making these views of a global collection of data that shares namespaces. By sharing namespaces I mean: we should increase our efforts to avoid or recognize namespace collisions. Just as we check now for users, and for uploading media (and should do for creating new templates), we can help page-authors avoid name collisions, or disambiguate-on-creation where one happens. Sj (talk) 00:05, 2 May 2014 (UTC)


 * There's some GREAT ideas in there which we should definitely look into for the future -- but it's definitely outside the scope of this rfc; let's split it out and brainstorm some on it in London maybe? --brion (talk) 14:41, 10 May 2014 (UTC)

Automatically moving pages on namespace creation

 * I'm overall in favor of this RFC. As it is framed here, it looks like there wouldn't be any transition necessary since this doesn't appear to alter the way namespaces already in existence work.  But maybe I've missed something.  Other than that this would be a good time to address the problem that comes up where newly created namespaces conflict with old titles.  Say a wiki has a page titled "OurWiki:Introduction" and later decides to make a namespace "OurWiki".  Currently the page becomes inacessible. -- ☠ MarkAHershberger ☢ (talk) ☣ 18:00, 28 April 2014 (UTC)