Topic on Talk:Extension default namespaces

Implemented years ago; discussion on refining or changing the system should take place in new threads.

When looking through this page, I've noticed a tendancy for many extensions to add their namespaces starting at a multiple of ten, where no other extensions already had any namespaces in that block of ten numbers, thus effectively "claiming" the block. This seems like good practice to me; should we codify it as a general recommendation on this page?

If so, it can be retroactively applied to the extensions already documented here that don't align themselves witha multiple-of-ten namespace number; the only documented problem areas are the 48x and 80x/81x numbers (plus the 10x/11x, but that's to be expected given how low the numbers are). This could be done simply y reformatting the page to designate according to groups of ten numbers, instead of by extension, while more-or-less leaving the problem ranges alone.

(Note that this would be a really good time to point out extension-added namespaces that aren't documented here yet, regardless of whether they'd create more problem ranges or serve to reinforce the observed pattern. =) )

https://codesearch.wmflabs.org/search/?q=(constant%22%3A%20%22%7Cdefine%5C(%20%27NS)&i=nope&files=&repos= should be a relatively complete list of known extension used namespaces.

Thanks for the link; I've added all of the results of that which weren't already listed, as well as updating and adding notes as appropriate to what was already on the page. Interestingly, several extensions aren't in that result that I would expect to be, e.g. Proofread Page.

I think this idea has some value, as it allow more flexibility for these extensions in the future and makes this site more overseeable.

However, we have to put into consideration that this comes at a cost: We're exhausting our low numbers much faster. (While I just wanted to point 48x as an example, where this happened, I just saw what JsonConfig and Graph did and would like to lower the severity of this point.)

It's probably a good idea to provide a mechanism to formally get extension namespace numbers approved in the range between 20x and 99x (Criteria: Not reserved for other things, not unnecessarily confusing) to avoid unnecessary conflicts and confusing fraction like with the JsonConfig extension.

For design, we could use something like

Not counting the 3xx range, I get:

• 25 taken
• 2 conflicts
• 52 free

Considering how much is free, I would consider 3xx as reserved by Wikia, with conflicts at 30x and 35x.

If the history of this page, and the link provided by Legoktm above, are any indication, extensions which define new namespaces are only rarely created, so the overall rate of namespace ID use should be very low, and in the long run may be balanced (or even entirely overshadowed) by archival of old/unmaintained/etc. extensions, so I'm not sure exhaustion of numbers is really much of a concern. Furthermore, while namespaces starting at 3000 are currently recommended to be reserved for sites instead of extensions, I find it pretty unlikely that any site following the guidance presented on this and related pages is going to use more than a thousand custom namespaces, and there are a handful of extensions already using namespaces starting at 5000/10000, so if we ever do manage to completely fill the <3000 numbers, we can always jump up and start on the 5000+ ones.

While Wikia have historically stuck with namespace numbers in the 300s, more recently they haven't been shy about using other numbers, including up into the thousands. More generally, they're obstinately sticking to an ancient version of MediaWiki (1.19), and as a result have to modify any extensions they want to use anyways, where they aren't just writing their own in-house extension (since modern extensions won't generally support such an old MW version), and they aren't afraid to change custom namespace numbers defined by these extensions for their own purposes. And looking more broadly, there have been rumblings that Wikia plans to move away from MediaWiki altogether at some point. So all in all, I don't think we should really worry about what Wikia does or does not do these days.

My main question is how many extensions have more than two namespaces (subject and accompanying talk)? And how common is it for an extension to add extra namespaces after already having two?

I have no objections to this proposal, reducing the potential for namespace conflicts seems like a good idea.

Per your above comment, the page should currently list just about all custom namespaces added by WMF-known extensions. The list could probably be made much more complete if namespace data was collected and made available on WikiApiary, though.

I've gone ahead and added appropriate ranges to section headers where reasonable. The problematic ranges became their own sections, with conflicting or otherwise affected extensions as subsections of them. I skipped over archived extensions entirely (at some point we should work out some solid guidance on when we should remove extensions from the page). Note that the ranges I've added aren't meant to be absolute; in particular, any extension authors should adjust the range on their extension(s) as needed to fit their purposes, as long as the adjusted ranges don't encroach on any other ranges or conflict with any of the general guidelines.