Hello to all,
I'm posting to request help with a conflict in namespace registration: http://www.mediawiki.org/wiki/Extension_default_namespaces?oldid=430890 Wiki admins are looking for a safe range of namespaces to use for custom, site-specific purposes. A little over a year ago, we floated the range 500-599 on the registration talk page. There were no objections, so, a couple of months ago we reserved the range and amended the manual. You can see the discussion in section 4: http://www.mediawiki.org/wiki/Talk:Extension_namespace_registration?oldid=43...
It turns out that an extension had already been using that range. Apparently the developer forgot to register it (see section 5, above). I guess he spoke to someone else, because just yesterday:
* The namespace registration system was replaced with a "default" system and the page was moved: http://www.mediawiki.org/wiki/Extension_default_namespaces
* The range 500-599 is no longer marked as reserved in the same manner as the extensions are marked.
* A Liquid Threads extension was enabled on the talk page. (I mention this because it fails on my Firefox 3.6, so I can't use the talk page anymore.)
I guess the issue isn't open for discussion there, anyway. Please someone else take a thought for the needs of the admins, and:
1. Pick a range to reserve for site-specific use. A whole block of 100 would be ideal, if that's possible.
2. Clearly mark the range as reserved, in the same manner as the extension ranges are marked. For example: http://www.mediawiki.org/wiki/Extension_default_namespaces?oldid=430890#Site...
3. Update the manual to reflect these changes: http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces
The extension developer (the one who forgot to register his namespace) says this is a "silly" request, but I think it's quite reasonable.
PS - Could someone also add a link to this thread from the talk page? I am no longer able to post there. http://www.mediawiki.org/wiki/Talk:Extension_default_namespaces
On 11-09-22 01:13 AM, Michael Allan wrote:
Hello to all,
I'm posting to request help with a conflict in namespace registration: http://www.mediawiki.org/wiki/Extension_default_namespaces?oldid=430890 Wiki admins are looking for a safe range of namespaces to use for custom, site-specific purposes. A little over a year ago, we floated the range 500-599 on the registration talk page. There were no objections, so, a couple of months ago we reserved the range and amended the manual. You can see the discussion in section 4: http://www.mediawiki.org/wiki/Talk:Extension_namespace_registration?oldid=43...
It turns out that an extension had already been using that range. Apparently the developer forgot to register it (see section 5, above). I guess he spoke to someone else, because just yesterday:
The namespace registration system was replaced with a "default" system and the page was moved: http://www.mediawiki.org/wiki/Extension_default_namespaces
The range 500-599 is no longer marked as reserved in the same manner as the extensions are marked.
A Liquid Threads extension was enabled on the talk page. (I mention this because it fails on my Firefox 3.6, so I can't use the talk page anymore.)
I guess the issue isn't open for discussion there, anyway. Please someone else take a thought for the needs of the admins, and:
Pick a range to reserve for site-specific use. A whole block of 100 would be ideal, if that's possible.
Clearly mark the range as reserved, in the same manner as the extension ranges are marked. For example: http://www.mediawiki.org/wiki/Extension_default_namespaces?oldid=430890#Site...
Update the manual to reflect these changes: http://www.mediawiki.org/wiki/Manual:Using_custom_namespaces
The extension developer (the one who forgot to register his namespace) says this is a "silly" request, but I think it's quite reasonable.
PS - Could someone also add a link to this thread from the talk page? I am no longer able to post there. http://www.mediawiki.org/wiki/Talk:Extension_default_namespaces
Please include wikitech-l in this discussion. Not every developer watches mediawiki-l because it's more of a help list, wikitech-l is our mailing list for development discussion.
Jack is not the author of the BlogPage extension. BlogPage is an extension developed for ArmchairGM, Jack has kindly been porting ArmchairGM and Wikia built extensions to be installable in normal MediaWiki. Naturally as he recently ported the BlogPage code that was in an external code repo and put it in our code repo for everyone to use, he went and responsibly added the namespaces that the extension has been using since it was developed (presumably sometime back in 2007) to that page so people would know. There were no 'objections' because practically no-one even knew that discussion existed. That's like walking into a forest, shouting out "I am now king of North America", then walking back into a city and asserting that because no-one objected you're now king.
ArmchairGM was founded in 2005, bought by Wikia in 2006, and their code was released in early-mid 2008. That page on MW.org however never existed before mid-2008. So not only is the concept of forcing 3rd party companies to abide by and add information to a wiki page we have on MW.org ridiculous, that page never even existed when BlogPage was developed.
The sentiment that the site-specific reservation added is "silly" seams to be shared by Jack, ^demon, and me at the least. For the record, all three of us are core developers.
That page does NOT list "reservations" or "registrations". It is nothing but a helpful informational page that lists default namespaces currently used by existing extensions and other known practices. The only purpose being so that developers of new extensions who want to try and avoid conflicting with namespaces other people may already be using can do so by avoiding any area of namespace numbers that people are already using. The page itself even lists two extensions using 600-601.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
I agree with Daniel on the mechanics of failed communication, and think any blaming of either side is wrong as well as counterproductive.
However, I think the basic request to NOW communicate widely which namespace range should be reserved for site-specific purposes is very reasonable.
Of course their will be not contract, but the present situation is unsatisfactorily. On http://www.mediawiki.org/wiki/Extension_default_namespaces their is no recommendation where to set up your site-specific namespaces. The page says that 100-199 is often used, and extensions should avoid it, but actually some of the most important extensions happily invent their namespaces there.
I don't believe it has to be a 100-block, but a clear commication to all devs: in the future, at all cost, avoid x-y would be welcome.
Gregor
Daniel Friesen wrote:
The sentiment that the site-specific reservation added is "silly" seams to be shared by Jack, ^demon, and me at the least. For the record, all three of us are core developers.
Core developers, no less! Well, you have a right to be proud.... MediaWiki is fine software. I guess I'm a core administrator, one of the appreciative folks you've been developing it for.
Gregor Hagedorn wrote:
However, I think the basic request to NOW communicate widely which namespace range should be reserved for site-specific purposes is very reasonable.
Of course their will be not contract, but the present situation is unsatisfactorily. On http://www.mediawiki.org/wiki/Extension_default_namespaces their is no recommendation where to set up your site-specific namespaces. The page says that 100-199 is often used, and extensions should avoid it, but actually some of the most important extensions happily invent their namespaces there.
I don't believe it has to be a 100-block, but a clear commication to all devs: in the future, at all cost, avoid x-y would be welcome.
Maybe it's more difficult for the extension developer (Jack) to move his namespaces, than it would be for us to move ours? In that case, it looks like 900-999 is still free territory: http://www.mediawiki.org/wiki/Extension_default_namespaces
If it were clearly marked as a sanctuary - avoid at all costs, as Gregor says - then we'd never have to spend time on this again.
A further suggestion: either we 1) pick a large block in the high numbers and mark as *definitely* safe for custom, site-specific use; or 2) do the opposite, and mark the whole high area as off limits, "talk to us first". The worst thing is to leave it as it stands now, because it invites future conflicts of the sort that happened in the 100-199 range. It currently says:
For now it would be best to avoid using this range to give sites room to define their custom namespaces without fear of conflict.
And later after those namespaces are defined, the rules may change?
On 11-09-23 08:56 AM, Michael Allan wrote:
Gregor Hagedorn wrote:
However, I think the basic request to NOW communicate widely which namespace range should be reserved for site-specific purposes is very reasonable.
Of course their will be not contract, but the present situation is unsatisfactorily. On http://www.mediawiki.org/wiki/Extension_default_namespaces their is no recommendation where to set up your site-specific namespaces. The page says that 100-199 is often used, and extensions should avoid it, but actually some of the most important extensions happily invent their namespaces there.
I don't believe it has to be a 100-block, but a clear commication to all devs: in the future, at all cost, avoid x-y would be welcome.
Maybe it's more difficult for the extension developer (Jack) to move his namespaces, than it would be for us to move ours? In that case, it looks like 900-999 is still free territory: http://www.mediawiki.org/wiki/Extension_default_namespaces
Changing the default namespace inside of an extension means breaking the extension on nearly every single wiki it is installed in. So yes, it's easier for a site administrator to move namespaces around than it is to change the default for an extension. Also, I'd recommend that any extension that defines custom namespaces to provide a way for site administrators to offset what namespaces are used.
If it were clearly marked as a sanctuary - avoid at all costs, as Gregor says - then we'd never have to spend time on this again.
A further suggestion: either we 1) pick a large block in the high numbers and mark as *definitely* safe for custom, site-specific use; or 2) do the opposite, and mark the whole high area as off limits, "talk to us first". The worst thing is to leave it as it stands now, because it invites future conflicts of the sort that happened in the 100-199 range. It currently says:
For now it would be best to avoid using this range to give sites room to define their custom namespaces without fear of conflict.
And later after those namespaces are defined, the rules may change?
Brion has already marked 100-199 for site administrators.
And I'd like to point out that every one of the extensions currently listed inside that area provides config to use different namespace numbers. So you should have no conflict worries.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Daniel Friesen wrote:
And I'd like to point out that every one of the extensions currently listed inside that area provides config to use different namespace numbers. So you should have no conflict worries.
Maybe we should provide a way to generate namespaces for extensions. The simplest way, using a global which is updated by each extension reserving a namespace is too fragile, but maybe we could produce something similar to ftok(3) to derive a free namespace number.
On 11-09-23 02:52 PM, Platonides wrote:
Daniel Friesen wrote:
And I'd like to point out that every one of the extensions currently listed inside that area provides config to use different namespace numbers. So you should have no conflict worries.
Maybe we should provide a way to generate namespaces for extensions. The simplest way, using a global which is updated by each extension reserving a namespace is too fragile, but maybe we could produce something similar to ftok(3) to derive a free namespace number.
^_^ I said that 3 years ago, and I say it again now.
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
mediawiki-l@lists.wikimedia.org