Talk:Requests for comment/Associated namespaces

Bug 31063
I actually included some plans for this while playing around with implementing. 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 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: 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)
 * 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.
 * 3) * 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.
 * 4) * mw.title objects would probably grow an associatedPageTitle( type ) method that would return the associated page of the appropriate type.

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)

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)