Well, the only reason I can think of this happening is because something must have called MWNamespace::getCanonicalNamespaces before your extension initialized, thus causing the cache it has to be filled without the extension's namespaces. Maybe try calling MWNamespace::getCanonicalNamespaces( true ) to force regeneration?

*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Tue, Jan 29, 2013 at 1:31 PM, Matthew Walker mwalker@wikimedia.orgwrote:

...

Is there a reason you can't just add them to $wgExtraNamespaces? As long as the wikis are known (meta, testwiki, etc), then you can just apply the namespaces to those wikis.

This is what I'm doing. It just happens in the setup script, CentralNotice.php. Ideally I would gate the addition of the namespaces on if the user set the option to use the translate extension.

If you're suggesting that I just add them to wmf-config/CommonSettings.php as a manual step for those particular wikis in our cluster; I'd rather not -- the namespaces are something that CentralNotice + translate requires, so I feel should properly reside in the extension config, not the site config.

That being said; if there is no programmatic way to add namespaces post init, I'll do it the hacky way. I just want to make sure that this is the consensus practice on how to do this.

~Matt Walker _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Good call. This is part of the story. Part of what I had been doing in the wgExtensionFunctions hook was:

1. $wgCentralBannerDispatcher = "{$wgScript}/{$wgContLang->specialPage(

'BannerRandom' )}"; --> Eventually makes a call to Language->getNamespaces() which then caches the localized namespace names

2. Add custom namespaces.

If I reverse the order it works. However -- because I've already created the initial cache in Language -- and because this local cache does not get invalidated when getCanonicalNamespaces(true) gets called -- anything further down the initialization chain is stuffed.

To fix this I moved the (1) type calls to a ResourceLoaderGetConfigVars hook where they're actually needed. But -- I'm wondering if this is actually a bug in the Language object? Shouldn't it regenerate it's cache when getCanonicalNamespaces changes? (There is a hook that it calls, CanonicalNamespaces, that could potentially support this mechanism.)

Well this does and doesn't work. There's apparently something enabled on testwiki that presumably initializes the Language object (or something else) that prevents CentralNotice from registering namespaces [1]. Further, even registering them in CommonSettings doesn't work -- in so far as MW then knows the namespaces exist; but somehow the title object doesnt... I can't tell more without actually attaching a debugger -- but my symptom is that my Message Group does not respect me saying that stuff is in my new namespace which in the past has been indicative that something doesn't know about a namespace and is just defaulting to MediaWiki because apparently that's better than blowing up.

Arghhh!

[1] And by this I mean a $wgExtensionFunctions hook that then adds entries to $wgExtraNamespaces, $wgNamespacesWithSubpages, and $wgTranslateMessageNamespaces if a variable is set. This works on my local, but not on testwiki.

Woops, ignore what I just said. I misread variable names. That's $wgExtraNamespaceNames.

*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Tue, Jan 29, 2013 at 1:03 PM, Tyler Romeo tylerromeo@gmail.com wrote:

This is because in Setup.php, $wgExtraNamespaces is added into the list of canonical namespaces *before* the extension functions are called. If you really need to have setup occur using $wgExtensionFunctions, you need to add your extra namespaces to $wgCanonicalNamespaces as well as $wgExtraNamespaces.

*--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com

On Tue, Jan 29, 2013 at 12:58 PM, Matthew Walker mwalker@wikimedia.orgwrote:

...

Morning All,

Need some help / a duck [1].

Fundraising pushed some patches yesterday which introduced two new namespaces; CNBanner and CNBanner_talk. Ideally these would only be present on 'infrastructure' wikis that actually host banner content (so meta, test, betameta) however I've been unable to figure out how to do this.

The root cause of my difficulty is that it appears that I am unable to create new namespaces in post initialization hooks -- e.g. $wgExtensionFunctions. Am I missing something like a function call to make post init creation of namespaces work; or is it just not supported anymore [2]?

Alternatively; is there a method to 'hide' namespaces similar to how we can 'hide' special pages?

Any other random ideas?

If you're curious; we needed the new namespaces to support a 'scratch' space for translations to happen before we moved them into the highly protected MediaWiki namespace.

[1] http://en.wikipedia.org/wiki/Rubber_duck_debugging [2] I had some code in 1.20 that created a namespace via a wgExtensionFunctions hook that I recall working does not

-- ~Matt Walker _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l