happy.melon.wiki wrote:

Davidgothberg identified (http://en.wikipedia.org/w/index.php?diff=283357047) the source of the issue: the per-wiki overrides in InitialiseSettings don't have the complete namespace array, yet by defining a whole array it means the default settings are completely lost. So the line for enwiki reads:

'enwiki' => array(-1=>0, 0=>0, 1=>1, 2=>1, 3=>1, 4=>1, 5=>1, 6=>0, 7=>1, 8=>0, 9=>1, 10=>1, 11=>1, 100=>1, 101=>1),

This does not include namespaces 12-15, but the defaults defined in 'default' above are overridden; thus in ns 13 & 15, where we would expect subpages, we don't get any. The line needs to be changed to:

'enwiki' => array(-1=>0, 0=>0, 1=>1, 2=>1, 3=>1, 4=>1, 5=>1, 6=>0, 7=>1, 8=>0, 9=>1, 10=>1, 11=>1, 12=>0, 13=>1, 14=>0, 15=>1, 100=>1, 101=>1),

The other wikis where customisation has been made should be fixed too.

'wgNamespacesWithSubpages' => array(
...

'enwiki'        => array(-1=>0, 0=>0, 1=>1, 2=>1, 3=>1, 4=>1, 5=>1, 6=>0, 7=>1, 8=>0, 9=>1, 10=>1, 11=>1, 100=>1, 101=>1),

It's *not* explicitly enabled in InitialiseSettings.php. If you want subpages in these namespaces, you're going to have to check that nobody minds, and then post a site request.

happy.melon.wiki wrote:

Only if you assume that the arrays are 'correct' and not an honest mistake by someone who thought the defaults above would 'shine through'. The same could be said of any bug: the only difference between a bug and a feature is that a bug wasn't expected behavior :D If the arrays are *supposed* to be like that why do they *all* contain the namespaces 1-11, even when they're set to the same as the WM and/or MW default, but only some contain the higher namespaces? Equally likely that they were initialised before we added the Help and Category namespaces and someone forgot to update the config when they were brought in. Given that there hasn't AFAIK been *any* discussion on the topic, at least on enwiki, what would have prompted them to be *explicitly* set away from the MW default (which is for subpages in all talkspaces)?? The situation makes no sense unless you consider the arrays to be incomplete, in which case they should be expanded with the MW default in the absence of community consensus to the contrary; right now they're been explicitly overridden *away* from the MW defaults for no reason. We're looking on VPT at enabling subpages in Help:, you're quite right that that's a change from the default which will need consensus and a site request. But I don't believe it's logically defensible to claim that the situation as it stands is the intended behavior, hence bug, not feature. I disagree with your close.

I closed the bug as INVALID because the bug as filed was invalid.

I don't think anybody expects a full-blown vote on such a trivial matter, just a general note somewhere prominent that the behaviour will be changing, and a check to see if anybody objects, as with most configuration changes.

happy.melon.wiki wrote:

The issue described is that the actual behaviour doesn't match with what was clearly intended, my first assessment was that the config settings weren't being correctly parsed; then DG pointed out that it was actually that they weren't correctly set in the first place. If the bug summary doesn't accurately describe the issue, then rewrite the summary. Closing as INVALID is saying that you don't consider the *underlying issue* to be a bug and that the current software behavior is correctly expressing the *intention* of the developer who initialised the system. As I said above, I can't agree with that assertion, it makes no logical sense.

davidg wrote:

Andrew: I think you are misunderstanding. The default for all Wikimedia sites is supposed to be that all talk spaces allow subpages. And the defaults for MediaWiki is that "Help talk" and "Category talk" allow subpages.

But due to a fairly obvious mistake the two talk spaces "Help talk" and "Category talk" currently do not allow subpages on enwiki and some other projects, and that is a bug. And that bug simply needs fixing.

(The person that wrote the override array probably didn't realise that leaving some items empty would override the default, or perhaps that override array might not have been updated since the help and category namespaces were added.)

What I think Andrew is saying is that since we do not know if it was an oversight, mistake, or intentional is impossible to say at this juncture. Thus he is stating that there should be some notification of the change to the users, giving them a chance to either voice support or against the change.

By putting it forth in some kind of public manner, you eliminate the question of if it was a mistake or intentional.

I am more inclined to think that yes, it is indeed a mistake that someone made. However, it is IMPOSSIBLE to even really make an educated guess in either direction. As such, I have added the + before the enwiki array. This should append the enwiki subpages to the defaults, only overriding the defaults when it is explicitly included, rather than overriding the defaults when its not included.

I am guessing that if this is incorrect, a public outcry will result, making both myself and Happy-melon look rather silly ;]

happy.melon.wiki wrote:

Thanks Rob! I don't think you need to worry; bug18459 is a site request for exactly the same change; there's a link to a poll we had which showed significant support. No one's going to do anything other than break out the champagne.