Topic on Talk:Extension default namespaces

Peachey88 (Flood) (talkcontribs)

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.

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

Peachey88 (Flood) (talkcontribs)

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.

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

Peachey88 (Flood) (talkcontribs)

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.

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

Carlb (talkcontribs)

The idea of extensions reserving any namespaces in the low-100's was an ill-advised move which should be abandoned as site admins have been told since the earliest MediaWiki versions (such as 1.4 and earlier, which had one-byte namespace numbering) that this was the range to use on the off-chance that MW's internal namespaces might expand into the 16+ range (they never have, the internal namespaces we had then we have now).

Extensions like DPLforum (which used to be installable on any manually-created namespace) are now going to $wgExtraNamespaces and registering some arbitrary number (110) themselves by automated means (as if they owned it outright) - even on sites where it is already in use. I just finished renumbering about a dozen wikis which had 'Forum:' elsewhere in the low-100's or on some number just above the MW built-in messages. A few had 110 already in use for something else, dropping visitors into the wrong namespace when they attempted to use the forums.

DPLforum was working perfectly well on all of these wikis since 1996 on some other namespace (various, MW 1.06 through 1.17, upgraded over the years) but the version currently in trunk (with MW 1.20) inserts 110=>Forum and if the original site had it somewhere else, things break.

The administrator installing these packages needs to have the ability to choose a namespace number (or at least not have one default to a number in the original site-specific range, with no check that those are already in use). Arbitrarily predefining one, especially one in the low-100's right in the middle of the range which had always been intended for site-specific namespaces, is asking for trouble.

DPLforum worked fine for years without forcing a selection of 110 as NS_FORUM. It should have been left that way.

Reply to "Notes"