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.
--
~Matt Walker