Talk:Requests for comment/Associated namespaces

Bug 31063

I actually included some plans for this while playing around with implementing bug 31063 [MediaWiki should use a reservation system for namespaces]. Instead of hardcoding any pattern with namespace ids there was a database table for relations between namespaces and a textual key like 'talk' was used instead of hardcoding just talkpage relations. When registering namespaces the intent was to have some behaviours that attempted to keep the odd/even pattern for compatibility while deprecating any code that relied on it so we could slowly eliminate that and change to real relations. Daniel Friesen (Dantman) (talk) 22:33, 17 March 2014 (UTC)

Re-opened bug 7803

I have re-opened bug 7803 as it seems to cover this RfC, so isn't necessarily a WONTFIX. Jdforrester (WMF) (talk) 02:11, 18 March 2014 (UTC)

Discussion this week

We'll be discussing this RfC this week in IRC so please leave comments here onwiki in advance if you can't make the meeting. Thanks! Sharihareswara (WMF) (talk) 17:52, 21 April 2014 (UTC)

About Scribunto, since I was asked

There are two aspects of how this would affect Scribunto:

1. Just like everything else, Scribunto would need to be updated as necessary to use whatever the new system is rather than hardcoding NS_MODULE == 828 and NS_MODULE_TALK == 829.
2. The code in Scribunto's mw.title and mw.site modules would need changing to give access to these new namespace relations.
   • The objects in mw.site.namespaces would probably grow a table for the associations. Too bad "associated" is already taken for the subject=>talk and talk=>subject mapping.
   • mw.title objects would probably grow an associatedPageTitle( type ) method that would return the associated page of the appropriate type.

I don't see anything offhand where Scribunto would block this RFC. You'll have to add methods in PHP to query these various associations anyway, then just make an interface to the same data in Lua (and new parser functions too, and add the data to the right places in the API, etc). Anomie (talk) 21:49, 28 April 2014 (UTC)

About ProofreadPage

I strongly support the associated namespace idea. I think it is also very important to make namespace id internal in order to avoid namespace id conflicts and I believe that this RFC is maybe a good opportunity to begin the transition. It would be nice to have a draft of the API that would allows extensions to register new namespaces and to take back the namespace id (maybe in a nice object-oriented way in order to avoid the current global variable mess). ProofreadPage is already mostly namespace id independent (because of retrocompatibility issues) so it should be pretty easy to move it to a new namespace management system. Tpt (talk) 07:14, 29 April 2014 (UTC)

To add some context for anyone unaware, a proofread page like s:Page:The Holy Bible, containing the Old & New Testament & the Apocrypha.djvu/46 is tightly related to an index page such as s:Index:The Holy Bible, containing the Old & New Testament & the Apocrypha.djvu, and mainspace pages such as s:The Holy Bible, containing the Old & New Testament & the Apocrypha/Volume 1/Genesis. p.s. thanks Tpt for maintaining and radically improving the software to make this all possible. John Vandenberg (talk) 11:25, 20 February 2015 (UTC)

Getting rid of hardcoded namespace constants

I am totally in favor of this whole idea. For one, hardcoded namespace constants gave me hard times before when migrating content from one wiki to another, up to the case where the articles had to be manually recovered in the database. I don't see a real reason why we keep this in code and not have a database table and some code to manage those numbers. Second, I can totally see the need for more than one associated namespaces. More than once I had to fake those by adding the tabs to the frontend manually.

As for the purpose of a namespace, I'd like you to consider that besides "tagging" a page, namespaces are also used to add functionality (e.g. the addtopic button), select a set of pages to be searched, and add certain rights to a set of pages (re.g. Lockdown). We need to make sure these functions are either not broken or clearly transferrable to the new system. --Mglaser (talk) 19:11, 11 May 2014 (UTC)

Add topic isn't a namespace, it's an action tab which calls up the edit page with an extra option telling it to append a new section. Daniel Friesen (Dantman) (talk) 19:50, 11 May 2014 (UTC)

Now under discussion on Phabricator

The Architecture Committee has decided to experiment a bit with the RFC process, and move the workflow to Phabricator, instead of relying on the wiki and IRC. This RFC is now under discussion at phabricator:T487. I'll try to move it forward over the next days and weeks. If you are interested, please join the discussion there. -- Daniel Kinzler (WMDE) (talk) 18:32, 18 February 2015 (UTC)

Media namespace

The Media: namespace is another example of a namespace associated with another namespace (File:). John Vandenberg (talk) 11:26, 20 February 2015 (UTC)

That's an alias, not a distinct namespace. Jdforrester (WMF) (talk) 18:48, 20 February 2015 (UTC)

Eh? It is special namespace -2. https://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces . You might be thinking of 'Image:' , which is an alias. https://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&siprop=namespacealiases John Vandenberg (talk) 03:46, 21 February 2015 (UTC)

Fine, it's not an "alias-without-any-other-merit" alias, it's an "alias-with-different-function" alias. It's another way of accessing the one actual namespace (NS6). None of this has anything to do with the RfC, which is talking about actual namespaces. Jdforrester (WMF) (talk) 20:47, 21 February 2015 (UTC)

One part of this RfC is about registering namespaces, and 6 and -2 are the closest of associated namespaces, to the degree they are almost an alias. I hope -2 is registered in the new system that is designed, and its "namespace-with-no-new-content-but-different-function" is also captured in the requirements gathering and design processes. Which is why I raise it here for discussion. It is a namespace, and not considering oddballs in design usually results in missed opportunities, or needing to do several major rewrites unnecessarily.

File: is an oddball more broadly, as it has two sets of actions for its two components: the page and the file. (e.g. separate histories for each), and file operations on shared files are performed on filepages which are 'missing' locally. In a new system where File: could have other associated namespaces, we might make the file operations available via a shared file repo aware Media: namespace. John Vandenberg (talk) 21:32, 21 February 2015 (UTC)

Global user talk pages

This was also mentioned in the context of global user talk pages: phab:T88416#1039444. Helder 20:08, 22 February 2015 (UTC)