Talk:Extension default namespaces
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| What's the big deal? | 2 | 08:56, 21 September 2011 |
| Social tools' namespaces | 6 | 08:54, 21 September 2011 |
| Reservation of numbers for site-specific namespaces 500 - 599 | 6 | 08:50, 21 September 2011 |
| Sites using different numbers for the same extension | 1 | 08:47, 21 September 2011 |
| 102 | 1 | 08:46, 21 September 2011 |
| Notes | 2 | 08:46, 21 September 2011 |
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.
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.
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.
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.
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?
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.
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.' [1]
If we take care to do that, then things should work out okay.
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.
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.
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?
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
is someone responsible for this process and can enter this reservation on this page (Extension_namespace_registration)?
Well, I do not know. :-( Perhaps it is an option to bring this forward on one of the mailing lists. Cheers
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.
The discussion continues in #Social tools' namespaces.
Do Wikia sites using 302 etc, in place of standard SMW's 102 etc, have any likely consequent problems?
Theoretically it should not happen, since extension developers now know that Wikia, which represents quiet a large "wiki universe". Choosing the early 300+ does not make sense.
This wiki uses ns 102 for "Extension:". Any likely conflict with standard SMW's "Property:"?
No, since SMW is not installed on this wiki and a version prior 1.0 will not be installed in the future. Cheers
I'd be very hesitant using "non-absurd" numbers in extensions. Someone could easily be using the number 140 in their wiki configuration for an extra namespace. Using negative numbers or absurdly large numbers would be a better solution. Also, if namespace 140 = Deletion discussion:, does that mean 141 = Deletion discussion talk:? And if not, what is 141? Will it be reserved? The negative namespaces are negative because they don't have a talk counterpart, which is also something to consider when having extensions reserve numbers.
Negative numbers are reserved for special case pseudo-namespaces (special and media), DO NOT USE THEM UNDER ANY CIRCUMSTANCES for actual namespaces -- things will break.
All non-pseudo namespaces in the current system come in [subject, talk] pairs such that subject mod 2 = 0 and subject + 1 = talk. If you violate these constraints, things will break.
Namespace numbers between 0 and 99 are implicitly reserved for MediaWiki's internal use, and no custom or extension namespaces should be assigned there to avoid conflicting with future additions in MediaWiki.
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.
The 200 to 299 range is probably a good place to register extension namespaces.
I would recommend against "absurdly large" numbers as those would be annoying. ;) However something more like, say 2000 might be just fine.
Why don't we create some sort of real installation, or at least store namespaces somewhere else? Then instead of attempting to reserve namespace ids which may already be taken by a custom content namespace, or conflict with an extension that didn't know about this page, or was hosted somewhere other than here and thus not listed, we could instead just have extensions grab a free ns id and reserve it internally. It doesn't have to be real complex installation, just some sort of install.php maintenance script, with a Special page counterpart for those without SSH. Just for small things like reserving ns id's.
