https://bugzilla.wikimedia.org/show_bug.cgi?id=16672
Roan Kattouw <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #6 from Roan Kattouw <[email protected]> 2008-12-18 15:13:02 UTC --- (In reply to comment #5) > thanks for fixing this, but the way it is now seems grossly inconsistent. > Specifically, the following points seem odd: > > a) canonical names use underscores while the rest uses space That's a bug, which I fixed in r44769. > 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. > c) having canonical names in attributes vs. aliases in a separate section. That makes sense because a namespace can have multiple aliases, but has only one canonical name. > Why and how canonical names are different from aliases is something users (and > even users of the api) should not need to care about. It's an artifical, > technical distinction which might go away at some point. > I disagree. One major distinction is that canonical names are guaranteed to work on every wiki regardless of language or configuration (except of course when they change, like with Image -> File; ideally, though, canonical names don't change), while aliases and localized names only work if the configuration is right. > I suggest to unify the output format: > > <namespaces> > <ns id="-2" preferred="yes">Média</ns> > <ns id="-2" canonical="yes">Media</ns> > <ns id="-1" preferred="yes">Speciální</ns> > <ns id="-1" canonical="yes">Special</ns> > <ns id="0" canonical="yes" preferred="yes"/> > <ns id="1" preferred="yes">Diskuse</ns> > <ns id="1" canonical="yes">Talk</ns> > <ns id="4" preferred="yes">WP</ns> > <ns id="4" canonical="yes">Project</ns> > <ns id="6" preferred="yes">Soubor</ns> > <ns id="6" canonical="yes">File</ns> > <ns id="6" >Image</ns> > <ns id="7" preferred="yes">Soubor diskuse</ns> > <ns id="7" canonical="yes">File talk</ns> > <ns id="7" >Image talk</ns> > </namespaces> > > That is, for each entry, just say if it's preferred (i.e. what the system > itself generates) and if it's canonical. But that info can easily be ignored, > and I can build a list of all namespaces and a map namespace ids without > having > to think about canonical, alias, etc. > I don't like this scheme, especially because the number of tags with <ns id="-2" ... is variable. Also, in JSON and other formats, the ns ID is also used as array key, which would be broken by this scheme. > If this info is split up into separate sections or not, i don't really care. > > Info about subpages would have to be delivered separately i guess. That makes no sense. We might as well add the subpages attribute to the <ns> tags. The fact that that duplicates is just another indicator that the aforementioned scheme is poorly designed. > Or we could > use a more complex scheme: > <namespaces> > <ns id="6" subpages=""> > <nsname canonical="yes">File</nsname> > <nsname deprecated="yes">Image</nsname> Note that deprecatedness isn't defined anywhere, so this particular bit of information (deprecated="yes") is not available. > <nsname preferred="yes">Soubor</nsname> > <nsname >Obraz</nsname> > </ns> > </namespaces> > > that should cover everything. but would be quite incompatible to what we have > now. > This scheme makes finding the canonical or preferred name for a namespace more difficult, because a client would have to iterate over all <nsname> elements and find the right one. The current scheme doesn't have that problem. The fact that namespaces and namespacealiases are separate siprops may be weird, but other than that the current scheme is not bad at all. All the other schemes you've suggested makes it harder for a client to extract one particular piece of information, especially if it uses a non-XML format (because of array indices). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
