Talk:Extension default namespaces

Previous page history was archived for backup purposes at Talk:Extension default namespaces/LQT Archive 1 on 2015-07-10.

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.

At the time of writing, this page is 44,829 bytes in size and though that may not sound like a whole lot, it has become painfully slow to edit. Maybe move the section for archived extensions to a subpage and transclude that here?

With or without VisualEditor? I do agree that it's a long page, but in regular edit mode (without VE), it loads just fine for me on a 10+ years old laptop. Some pages just end up long because of the way it simply is, and this page is a prime example of that.

I was actually editing the page without Visual Editor. Of course, there is a real possibility that it's just my browser, although I don't experience anything of the kind while writing the present post.

Personally, I think that having site-specific namespaces should be at 100-199. This allows them to show up earlier on "special:allpages" or any other places that lists namespaces by number. Then place all of the extensions.

Or maybe this ...

0-99 - MediaWiki 100-999 - Site stuff 1000+ extensions.

Extensions can reserve a group of 10 (5 namespaces). For most extensions, that should be fine. It is only big ones that have a whole group of extensions that it might make a difference and they need more.

There is Extension_default_namespaces, which manages namespaces for extensions. Custom namespaces should be above 3000. But having some "prioritization" sounds interesting. Maybe you want to file a feature request at https://phabricator.wikimedia.org/maniphest/task/edit/form/102/

While I agree with this in theory, in practice it's about two decades too late to be practical to implement; too many extensions have used (and currently use) the 100-999 namespace number range, and 100-199 in particular has historically been especially heavily trafficked.

An alternative solution to having site-specific namespaces listed before extension namespaces in various dropdowns and the like, would just be for the software to hardcode special handling for the designated range of 3000-4999. With the range's explicit reservation for site-specific namespaces that's not as unlikely of an idea as it might have been in the past, before the current best practices/recommendations were established.

Hi everybody,

I want to create my own namespace on my wiki. But today, I do not know which extension will be installed in the future. Is a range for personal namespace reserved ? A range prohibited for extensions ?

If not the case, it could be a good idea to reserve one.

Thanks for your answer.

There's no way to stop extensions from just using whatever they want. And extensions have already used ranges all over the place. This page is just a registry of defaults already in use. It's simply here so extensions can use defaults that in theory don't already conflict with another extension.

Extensions should come with a way to configure the namespaces used. So just go ahead and define your namespaces wherever you want. Most sites use 100-199 for their site namespaces. Or you could use 3000+ if you felt like it. If you do install an extension that happens to use a default namespace that conflicts with one you already have just then just use the extension's configuration to explicitly tell it another namespace number to use instead.

Ideally in the future there will be no need for any sort of ranges at all. We'll just have MediaWiki automatically assign namespace numbers. Extensions will register namespaces using a named key like 'ext.gadgets.gadget'. And you'll be able to define your site namespaces using a special page.

Let's keep them, marked as archived.

Does anyone have thoughts on guidelines for when archived extensions should be removed from this page? I suppose an obvious one would be to remove extensions that have no noted uses on WikiApiary.

There are also a significant number of extensions that were listed on this page in the past but have been removed over the years, no doubt mostly because of archival, but potentially in select cases because custom namespaces were simply removed from them (I'm not aware of any such cases myself, but it's at least a possibility). I never reviewed any of these extensions any of the times I've been working on this page, so it's possible there are some that should be readded here, if anyone cares to do a little digging (though personally I'm fine with just ignoring all of them at this point).

...On the other hand, it might be useful to anyone using dumps of old, closed wikis if all archived extensions which added custom namespaces are documented here, in which case it'd be best to have a separate section for them and keep the actual main section for active extensions.

I personally would keep them and mark them as archived.

I agree with Kghbln here.

Please provide at least one place where to report problems with the localized name of the name space.

May you elaborate? Which kind of problems?

First, please provide a section that any reader can read what to do if has found a translation problem. At least inform the reader that can "talk" here...

I found a problem in Greek translation of TimedText namespace. (Ok, I am not sure if the problem is with the namespace translation but probably is). The following:

https://commons.wikimedia.org/wiki/TimedText:%C2%BFQu%C3%A9_es_Wikipedia%3F.ogv.el.srt

prints: Ελληνικά υπότιτλοι για το βίντεο: File:¿Qué es Wikipedia?.ogv

the right should be one of:

• Ελληνικά: υπότιτλοι για το βίντεο: File:¿Qué es Wikipedia?.ogv
• Ελληνικοί υπότιτλοι για το βίντεο: File:¿Qué es Wikipedia?.ogv
• Υπότιτλοι στα ελληνικά για το βίντεο: File:¿Qué es Wikipedia?.ogv

Thanks.

I am not sure if we should still tell users that every namespace has a matching talk namespace that may be used to address issue etc.

Since your issue relates to the Extension:TimedMediaHandler it will be best to create a task on Phabricator to make sure the developers see it early on.

First many hanks for the quick answer. But there is no way (even in phabricator, which was my second many-hours-serch) to find where to announce such a problem (till now I was used to use MediaWiki namespace to change -as a sysop- or its talk page to announce and maybe this was my problem at first).

With "At least inform the reader that can "talk" here..." was referring to this exact talk page(Talk:Extension default namespaces). Some users do not comprehend all.

We must have in: Extension default namespaces some explanation on how the localisation works on them. Even new sysops do not know everything. And many simple users willing to make corrections do not know where to search.

This page has nothing to do with the localization of default namespaces I'm afraid. This page tells programmers which namespaces are taken.

In case you would like to learn how namespaces are localized and translated you will want to have a peep here. I will add a note.

A site administrator need free and secure namespace ranges to use for your site... There are a big contradiction with "The namespaces in 100-199 are reserved for site-specific namespaces, and should not be used by extensions".

Please, if it is a serious standardization, express an ensured range or set of ranges, that not will change tomorrow. EXAMPLE: "dear admistrator, sorry, you can ensure after 2015 with {130-159, 150-159 , 180-199}"

Please say to extension programmers to move out from the reserved range.

This information is at the very end of this page. I added a note at the top to get the message across more visibly. Guess this is ok. Cheers

The manual refers to starting at 200:

// Define constants for my additional namespaces.
define("NS_FOO", 200); // This MUST be even.
define("NS_FOO_TALK", 201); // This MUST be the following odd integer.

It seems natural to put namespaces that are not used for extensions in this area because it's not between 1-199 and conflicting with namespaces for well known extensions beginning at 300.

However, Extension_default_namespaces#Extension_default_namespaces.23ID_3000.2B states that custom namespaces should be above 3000.

What's the best range for systems administrators to place custom namespaces?

I'm going to try starting at 3000 now to resolve the Invalid or Virtual Namespace -1 errors when I try to create forms with Semantic and Semantic-Forms. After changing namespaces I won't forget to run maintenance/update.php and then run rebuild and update via Special:SMWAdmin.

hrm, first time using visual editor [[Evar]!] ... tried to cut and past code from main page and it wouldn't work:

Note Note: Namespaces using numbers from 3000 and higher are meant to be used by system adminiatrators to define their custom namespaces. Thus extension developers should not use this range.

It is confusing.

| using numbers from 3000 and higher.

> I'm going to try starting at 3000 now to resolve the Invalid or Virtual Namespace -1 errors when I try to create forms with Semantic and Semantic-Forms.

I'm not sure what issue you have with SMW's default namespace but SMW NS range has been used fairly early before the whole NS number n....... came up therefore if you leave the NS as deployed you should not face any issue.

In case you want to use a different NS then you advise to read:

• https://semantic-mediawiki.org/wiki/Help:$smwgNamespaceIndex
• https://semantic-mediawiki.org/wiki/Help:$smwgNamespacesWithSemanticLinks
• https://semantic-mediawiki.org/wiki/Help:Custom_namespaces

I have revised the manual. I do not see a connection with SMW either, however the tips MWJames provided should help you out of your misery.

Thank you. There is so much to look into.

That "Invalid or virtual namespace" error message has nothing to do with custom namespace numbers - it's an error brought about by a combination of certain versions of ConfirmEdit (maybe the ones that come with MW 124 and MW 1.25) and Semantic Forms. I'm hoping to be able to find a patch to fix it; though I think with the very latest version of ConfirmEdit, it's no longer a problem.

I just want to confirm that this is a 'SF' - 'ConfirmEdit' conflict that started to occur for me with MW version 1.25.1 (that includes ConfirmEdit 1.3). Removing confirmedit (although not something I wanted to do) solved this issue. I'm using SF 3.2-alpha (f6c8e0b) and SMW 2.2.1

See also this post. Both extensions should play now for MW 1.25 with their latest versions.

Thanks Kghbln. The manual is much clearer.

I'm not qualified to chime in on the namespace issue; the namespace issues magically disappeared.  :)

I hope everyone knows there's nothing binding about this page. It's just a page for extension authors to list their custom namespaces in order to avoid conflicting. Declaring 500-599 will only be used for custom site namespaces and any extension using them is wrong is just silly. Like Jack points out, SocialProfile has been using its 500-range namespaces for quite some time, and there's nothing wrong with this. He should be allowed to add his namespaces to the list like every other extension. Looking at the discussion above, I hardly call that a consensus. It's barely even a discussion, coupled with the fact that this is a very very low traffic talkpage. I don't see any developers involved in the discussion, and I don't remember the discussion being advertised on wikitech-l or mediawiki-l as I would expect.

This post was posted by Peachey88 (Flood), but signed as ^demon.

Agreed, this page has always only been a guide, never a rule. It's intended so that extensions adding new namespaces can try to collaborate and avoid forcing people to override default namespaces all the time because of extensions always overlapping. Every extension that defines a custom namespace should always have some method of configuring the extension to use different namespace numbers. And sites can define whatever manual namespace numbers they want and force extensions they install to use numbers that fit around that. The idea that 500-599 should be site specific is ridiculous even at a logical level... 1000+ would make more sense, 2000+ if we have to. Personally I have a site namespace of my own sitting at 112-113. Btw here Manual = 100, Extension = 102, API = 104. Frankly the 100-199 range has always made much more sense to me for site-specific namespaces. SMW is just an oddity which can have a config option set or we can just use the free ones around it.

Personally the thought that we should do away with this whole hardcoded namespace thing has been lingering in the back of my head for awhile. We really need some way for an extension to request a namespace on a first-come first-served basis such that after a number is reserved another extension will always get a different number even if the previous extension was uninstalled.

This post was posted by Peachey88 (Flood), but signed as Dantman.

Wow... waitasecond, I even commented on just that right on this talkback 3 years ago. Btw, defining a range for Wikia to use without asking or even telling them feels like being the kid that draws a line in the sand taking 3/4 of the sandbox to himself then throws a temper tantrum when the neighbour's kid walks over it and tries to have fun with his other friends.

This post was posted by Peachey88 (Flood), but signed as Dantman.

Apparently my edit was reverted because of some conflicts. Like I wrote in my edit summary, the namespaces conflict with some other extensions' namespaces and site-specific namespaces, but I'd prefer if the other extensions would change their numbers because social tools have been using these namespace numbers since 2007 or so.

Having a site-specific range (500-599) is just silly IMO, sites can and should use whatever NSes aren't registered; who says that custom namespaces indexes can't start from 1000+? I'd like to change TimedMediaHandler's custom NS from 700 to 710 or something; that should be a relatively simple and uncontroversial change, I hope.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

I did the revert. I read your subsequent response on my talk page. Thanks for agreeing to discuss the issue. Please note that the reservation of range 500-599 was open to discussion for 11 months (see preceding section). There were no objections, so we decided to act. The range is now reserved. Manual:Using custom namespaces was altered accordingly. Without a general, prior agreement to withdraw the reservation, I feel it should remain in force. Otherwise, what is the purpose of a registration system?

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

I understand the point about the discussion regarding site-specific namespaces being open for almost a year, but the point is that I didn't read it as I don't actively monitor it, and I'm quite sure that many other developers didn't read the discussion either.

Kghbln suggested that the discussion about site-specific namespaces should be raised on the appropriate mailing lists, which in this case would've been wikitech-l, the development mailing list (yes, mailing lists are so Web 1.0 but they're also how we do things). Many developers, whether they're core, extension or third-party, are subscribed to that mailing list, so by posting there your message will reach the intended audience and you can claim consensus on your changes.

As for the question regarding the purpose of this page, it really depends. To be exact, while many developers might use this page, it still doesn't change what's in SVN — for the time being, BlogPage is using namespaces 500 and 501, no matter what this page says.

Ignoring everything and anything related to site-specific namespaces and namespaces indexes 500-599, what about the other namespaces? While Wikia certainly has a lot of custom extensions and some of them do define their own namespaces, I feel that registration should happen on a per-extension basis instead of reserving a range to Wikia; are their developers even aware of the fact that they had such a reserved range registered on this page?

Extension:NagiosConfig, which has reserved namespaces 600-609, is marked unstable and the latest edit to the extension page has been done on 27 May 2011 and its source code isn't available; Extension:FanBoxes is older, it is marked as stable and it certainly works with MediaWiki 1.16.0, so I feel it should get the namespaces 600 and 601, as it already uses them in the code.

Considering that Extension:TimedMediaHandler hasn't been deployed yet on Wikimedia wikis, I don't think bumping its namespaces from 700 and 701 to something like 710 and 711 or something will be very controversial.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

I wish I could answer your questions, or point to someone who's responsible for the design of the registration process. I think that most of us are simply following the instructions at the top of the page: 'To prevent conflicts in new namespaces added by extensions, please "register" your extension's namespace here.'

If we take care to do that, then things should work out okay.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

I've changed TimedMediaHandler's namespace ID in r97550. Assuming it doesn't get reverted or FIXME'd within the next 5 days or so, I'll be changing it here and readding my changes back.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

Please do not alter the reserved range 500-599. It was duly registered by prior agreement and the changes you point to would alter it. You cannot act alone in this matter and disrupt the work of others. I recommend you speak to someone in authority. This is a clear conflict, and it arose because you failed to observe the rules in the first place.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

The "prior agreement" was based on the assumption that no extensions used that range, which as it turns out was incorrect. 500 was already in use by the extension before that "agreement" between three people occurred. I've checked Wikia's repository and it was indeed using namespace 500, before your attempt to "reserve" the range. This is not a "future" extension, it's a preexisting extension that has been cleaned up and added to the official Wikimedia repo.

This post was posted by Peachey88 (Flood), but signed as Reach Out to the Truth.

The de-facto "prior agreement" was 0-99 reserved for MediaWiki internal namespaces (of which 0-15 are currently in use) and site-specific namespaces on 100+ since at least 2004 (MW 1.04 was limited to one-byte namespace numbers). In the half-dozen years which followed, many wikis were deployed with site-specific namespaces just above the internal ones or starting at 100+ like the instructions told the site admins to do.

Unless every wiki which deployed "by the book" using 100+ as site-specific is now expected to renumber all of its custom namespaces to some other range (something which we do not have automated tools to do, short of raw SQL UPDATE commands, as a proper namespace editor never did make it into MW 1.7+ core code) there should be no "reservations" of namespaces in this range to extensions. Quite simply, the designation of 100+ as the site-specific range pre-dates the changes to extensions like DPLforum to hard-code them to namespaces (there was nothing special about 110 or any other namespace number in the original 2005-06 implementation of DPLforum, this is a recent addition breaking existing sites).

If you want to "reserve" some block, use one which hasn't been assigned to site-specific namespaces since at least 2004, please.

If those people want to install an extension that uses namespace numberss that conflict with their wiki's existing namespaces, they can configure or modify the extension locally so it uses different namespace numbers on their wiki. But changing it upstream would adversely affect way more users.

The only namespace numbers that can really be considered "reserved" are those that are already in use on a given wiki.

The issue with DPLforum is that it was *not* hard-coded to any one specific namespace before July 2011; furthermore, once a hard-coded namespace was added, the one chosen was right in the middle of the most-used section for site-specific namespaces (by 2003 convention, 16-99 are for core MediaWiki expansion, 100-254 are free for site-specific use).

Some of us have had DPLforum deployed on high-traffic sites since 2006 (it was developed by user:Algorithm for Uncyclopedia in late 2005) and are now seeing configurations break because this hard-coded 110: is not the Forum: space on the wiki (prior DPLforum versions were manually configurable to any site-specific namespace) and in a few cases is already, predictably, being used for something else because that's where we've been told since 2003 to put site-specific namespaces, 100+

Upgrade DPLforum, watch wiki break in some manner because something was hardcoded after the fact (July 2011) into a space which should never have been used in this manner (the 100+ range allocated in documentation as site-specific, a convention which was in place about eight years prior).

If anything, extensions should not be hard-coding namespace numbers on the blind presumption that they aren't already in local use. At a minimum, there should be some means to override the namespace selection, either to point to a vacant namespace or to match a namespace already configured by the site for use with a prior version of the same extension.

The 2003 allocation of 100+ to be site-specific namespaces predates the after-the-fact 2011 hard-coding of 110: as DPLforum.

Using the extension default namespaces as a space where anyone can edit, claim any existing site-specific namespace as suddenly now belonging to one extension, then complain that it's somehow the fault of the system administrators of existing sites already using that namespace when things break is not the answer. Extension writers have to realise that their code has to be installable on sites where any given namespace, especially the 100+ site-specific area, is likely already in use and stop hard-coding namespace numbers in a non user-configurable manner.

Even the painfully-obvious "well known port" allocations in the TCP/IP world are presumed potentially in use (that's why you can put "Listen 8080" in Apache's httpd.conf if :80's already in use by another web server on your machine...) so why encourage the less flexible approach of hard-coding namespaces with no easy reconfiguration mechanism here?

Oh. Well, no one was discussing DPLforum in this thread until you did. I make no judgments regarding the namespaces declared by that extension, nor do I wish to.

There is a note: "Site-specific custom namespaces are generally assigned in the 100 to 199 range. I would recommend staying out of this range for anything to be defined by an extension."

These numbers are however used by Semantic MediaWiki and Semantic MediaWiki Extensions. It would indeed be very useful to have numbers reserved for site-specific namespaces. According to http://www.mediawiki.org/wiki/Extension_namespace_registration numbers from 500-599 are still free. Would'nt it be a good idea to really reserve this range for site-specific custom namespaces?

This post was posted by Peachey88 (Flood), but signed as Kappa.

Why not. This would help providing wiki administrators with a reliable range not to be used by extension. However my attempt to at least keep them of the range 100-110 failed recently on Manual:Using custom namespaces. Cheers

This post was posted by Peachey88 (Flood), but signed as Kghbln.

is someone responsible for this process and can enter this reservation on this page (Extension_namespace_registration)?

This post was posted by Peachey88 (Flood), but signed as Kappa.

Well, I do not know. :-( Perhaps it is an option to bring this forward on one of the mailing lists. Cheers

This post was posted by Peachey88 (Flood), but signed as Kghbln.

It has been almost a year and nobody voiced an objection. I need a safe range for my own use, so I added this section: Extension_namespace_registration#Site-specific.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

Well done. Some wikis I know already use this range.

This post was posted by Peachey88 (Flood), but signed as Nemo bis.

The discussion continues in #Social tools' namespaces.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.