Last modified: 2009-03-19 23:41:45 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18672, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16672 - meta=siteinfo&siprop=namespaces|namespacealiases should return canonical names as well
meta=siteinfo&siprop=namespaces|namespacealiases should return canonical name...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.14.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-16 13:45 UTC by Danny B.
Modified: 2009-03-19 23:41 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Danny B. 2008-12-16 13:45:24 UTC
meta=siteinfo&siprop=namespaces|namespacealiases should return canonical names as well

Current output (excerpt of cswiki):

<query>
    <namespaces>
      <ns id="-2">Média</ns>
      <ns id="-1">Speciální</ns>
      <ns id="0" subpages="" />
      <ns id="1" subpages="">Diskuse</ns>
...
      <ns id="6">Soubor</ns>
      <ns id="7" subpages="">Soubor diskuse</ns>
...
    </namespaces>
    <namespacealiases>
      <ns id="4">WP</ns>
      <ns id="6">Image</ns>
      <ns id="7">Image talk</ns>
    </namespacealiases>
</query>

Suggested output:

<query>
    <namespaces>
      <ns id="-2" canonical="Media">Média</ns>
      <ns id="-1" canonical="Special">Speciální</ns>
      <ns id="0" canoncial="" subpages="" />
      <ns id="1" canonical="Talk" subpages="">Diskuse</ns>
...
      <ns id="6" canonical="File">Soubor</ns>
      <ns id="7" canonical="File talk" subpages="">Soubor diskuse</ns>
...
    </namespaces>
    <namespacealiases>
      <ns id="4" canonical="Project">WP</ns>
      <ns id="6" canonical="File">Image</ns>
      <ns id="7" canonical="File talk">Image talk</ns>
    </namespacealiases>
</query>

or create siprop=canonicalnamespaces

Any solution to deliver canonical namespaces via API is welcome.
Comment 1 X! 2008-12-16 15:24:38 UTC
Assigning to me, won't be too difficult to fix. 
Comment 2 Chad H. 2008-12-16 15:28:01 UTC
Not sure about putting them in the aliases too, perhaps just in the normal namespaces. Aliases don't have canonical names, they redirect to the localized name.
Comment 3 P.Copp 2008-12-16 15:41:48 UTC
Please also consider adding the aliases, that are defined at $wgContLang->namespaceAliases (i.e. in MessagesXX.php). AFAICT they are missing in the current output.
Comment 4 X! 2008-12-16 17:19:36 UTC
Fixed in r44676
Comment 5 Daniel Kinzler 2008-12-18 10:11:40 UTC
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
b) custom namespaces shouldn't have a canonical name
c) having canonical names in attributes vs. aliases in a separate section.

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 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.

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. Or we could use a more complex scheme:
<namespaces>
  <ns id="6" subpages="">
    <nsname canonical="yes">File</nsname>
    <nsname deprecated="yes">Image</nsname>
    <nsname preferred="yes">Soubor</nsname>
    <nsname >Obraz</nsname>
  </ns>
</namespaces>

that should cover everything. but would be quite incompatible to what we have now.
Comment 6 Roan Kattouw 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).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links