The 100-199ish range has for years been the standard convention for
site-specific custom namespaces -- any extension hardcoding in that range
does so at its own risk, and for instance can't be deployed on existing
Wikimedia sites which already put their site-specific namespaces there.
The best thing to do though is to remove the requirement to worry about
namespace numbers at all; just as we don't need to enforce any special rules
about page and revision id numbers, they should be managed internally to the
wiki's database and not enforce any particular meaning on their own.
There was some prelim work on this a few years ago ('Namespace Manager') and
the idea gets brought up again; here's a recent bugzilla entry which should
be a good place to start hanging that:
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
-- brion
On Thu, Sep 22, 2011 at 3:18 AM, Gregor Hagedorn <g.m.hagedorn(a)gmail.com>wrote;wrote:
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
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l