Jump to content

Requests for comment/Associated namespaces

From mediawiki.org
Tracked in Phabricator
Task T487
Request for comment (RFC)
Associated namespaces
Component General
Creation date
Author(s) Micru ⇌
Document status in discussion
See Phabricator.

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 cases

[edit]

Use case 1: Associated structured data

[edit]

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 File: namespace, where metadata could be stored – something like File metadata:. Similarly, a wiki might want to have arbitrary data against NS0 pages.

Use case 2: Template documentation

[edit]

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 {{/doc}} template or similar should be used, putting documentation on a page like Template:Foo/doc 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

[edit]

The TemplateData extension, used by VisualEditor, currently inserts a JSON blob between the <templatedata> parser tags, and thus a huge number of page properties; a much cleaner way for storing it would be in a Template data: namespace (bugzilla:54140 / bugzilla: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 (Template:) has associated namespaces: Template talk:, Template documentation:, Template data:, and any other further additions.

[edit]

Proposals

[edit]

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

Namespace registry and association handlers

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


Longer-term: making namespaces a multivaluable property for context?

[edit]

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)[reply]

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)[reply]

Automatically moving pages on namespace creation

[edit]
  • 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)[reply]
  • I think this is beyond the scope of the RFC, but ... a page titled "OurWiki:Introduction" is a pseudo-namespace and, as you no doubt know, people create pages like this all the time without realising that a 'real' namespace needs to be registered somewhere. It would be great if there was some warning alerting the contributor that they are using a page title which includes an unregistered namespace, either during the save with an option to confirm and save it, but a better option would be to auto-categorise pages with a pseudo-namespace in the title into a 'maintenance category' as that would help everyone become aware of which prefixes are problematic.
One option to future-proof against collisions is to add ':' to the forbidden Title characters in more circumstances. The character ':' by itself is already an invalid Title, including repeats such as '::' and '::::', and it is invalid if it is at the end of the namespace name, such as 'File:', and it is silently gobbled up if it is at the beginning such as ':File'. It would would be interesting to see how many pages across all (Wikimedia?) wikis have a ':' in the Title ..
  1. after a single character, the first character being case insensitive on most wikis (i.e. potential conflicts with new single character interwiki map entries)
  2. in the first four characters, where all characters are lowercase except the first (i.e. potential conflicts with new language entries)
  3. following a sequence of characters that are valid interwiki prefixes (lowercase, numerals and '-'?) (i.e. potential conflicts with new special:interwiki entries, however new interwikis can pick their own name so they can avoid conflicts)
A new config entry to prevent new pages with problematic use of ':' would be good. e.g. ':' must not appear in the first 10 characters of a page Title would be a sane default, but some wikis may need to reduce that number down to 4 in order to prevent only really bad titles.
We may be able to migrate all potentially problematic current use of ':' to the unicode '：' or similar, like was done with w:C：Real in order to establish the 'c:' interwiki prefix entry.
John Vandenberg (talk) 22:21, 27 May 2014 (UTC)[reply]

Conservative approach

[edit]

I feel that probably the most conservative approach possible would be not to abandon namespace ID numbers, but to migrate from one to two. The first would be the type (eg Template could remain at 10), but there would be a second ID number for the subtype (eg 10:0 would be straight Template; 10:1 could be Template talk; 10:2 could be Template documentation, and so on, and so forth).

While it might then become possible to have a first namespace ID which is odd, it would at least become something to be very careful about for a very long time. I also suppose that this could be used as a stepping stone to any more extravagant proposals to be had. I don't know how hard any of this would be to implement, so take this with a grain of salt. Thisismyrofl (talk) 00:55, 10 November 2015 (UTC)[reply]

Retrieved from "https://www.mediawiki.org/w/index.php?title=Requests_for_comment/Associated_namespaces&oldid=6277688"