Good call. This is part of the story. Part of what I had been doing in the wgExtensionFunctions hook was:
- $wgCentralBannerDispatcher = "{$wgScript}/{$wgContLang->specialPage(
'BannerRandom' )}"; --> Eventually makes a call to Language->getNamespaces() which then caches the localized namespace names
- 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.