Platonides schreef:
(it's
helpfully provided in the API result . . . actually, what
does it mean that "Portal" and "Portal talk" are canonical?
shouldn't
there be no canonical attribute if the namespace is custom?).
Agree. Portal and Portal talk could still be acceptable, since the
namespace ids 100-101 are more or less reserved for portals across the
wikis.
What is scaryier is seeing <ns id="102" canonical="Cookbook">
on
enwikibooks whereas the same ns 102 mean Wikiproject on some pedias.
Since the API provides namespacealiases linked to the id, not to the
"informal canonical name" I see no reason to keep the canonical
parameter on the extra ns.
This was brought up before in bug 16672 comment #5. My reply was:
b) custom namespaces shouldn't have a canonical
name
Maybe, maybe not; I see arguments for and against. But since
$wgCanonicalNames contains canonical names for custom namespaces too and
since removing the canonical attribute for some namespaces but not
others would violate expectations and be a breaking change, I'll just
keep stuff the way it is. Regardless of whether custom namespaces should
or shouldn't have a canonical name, removing it from the API output
isn't worth the trouble.
Roan Kattouw (Catrope)