Last modified: 2014-05-03 14:41:53 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 T43845, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41845 - Make a multilingual wiki aware of localised names of its namespaces
Make a multilingual wiki aware of localised names of its namespaces
Status: UNCONFIRMED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Lowest enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 42028 (view as bug list)
Depends on:
Blocks: 9040 10342 20798
  Show dependency treegraph
 
Reported: 2012-11-07 11:54 UTC by Aude
Modified: 2014-05-03 14:41 UTC (History)
15 users (show)

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


Attachments

Description Aude 2012-11-07 11:54:46 UTC
For multilingual wikis, such as Wikimedia Commons or Wikidata, it would be nice if all language translations of a namespace name could be entered in the url and be resolved.

For example, http://wikidata.org/wiki/Benutzer:Aude as a URL should resolve as an alias for http://wikidata.org/wiki/User:Aude

It could be a global setting that a wiki could enable.

Perhaps all the language translations could be treated as aliases, in most simple way to do this.

More complex cases are where we have language specific subpages, like if I had http://wikidata.org/wiki/User:Aude/de then it might be nice for http://wikidata.org/wiki/Benutzer:Aude to resolve to there.  This is beyond scope of this bug but just some extra consideration.
Comment 1 Nemo 2012-11-07 12:32:24 UTC
This has already been WONTFIX'ed at least two times and probably more, see bug 10342, bug 20798.
Comment 2 Aude 2012-11-07 14:29:57 UTC
Not surprised this has been requested in previous bugs. I don't know if it's more feasible now and worth it for such use cases as Wikidata?
Comment 3 Nemo 2012-11-07 14:39:18 UTC
(In reply to comment #2)
> Not surprised this has been requested in previous bugs. I don't know if it's
> more feasible now and worth it for such use cases as Wikidata?

Wikidata is not the first multilingual wiki we have and at a first glance the previously mentioned reasons not to fix this are still there, but I suppose devs could as well change mind (adding to cc Aryeh, Chad and Roan who closed the previous bugs).
Comment 4 Niklas Laxström 2012-11-09 12:50:29 UTC
I doubt that. Nobody has suggested how to handle the conflicts.
Comment 5 Siebrand Mazeland 2012-11-09 13:26:44 UTC

*** This bug has been marked as a duplicate of bug 10342 ***
Comment 6 Aude 2012-11-09 15:18:16 UTC
Maybe if we have http://gl.wikidata.org/wiki/Usuario:Aude and http://es.wikidata.org/wiki/Usuario:Aude  

It's still the wiki but magically, based on the language code it sets the interface and content language correctly, and overriding $wgLanguageCode global?

This is not the normal use for the language code subdomains, which in the case of wikipedias are actual separate databases.  In case of wikidata, it's still one single wiki with one database.

For item content, it's not a problem because items are in the main namespace on Wikidata.  When we have stuff in the Property and Query namespace, it could be more of a concern, along with the standard mediawiki namespaces that would be nice to have more localised.

It makes sense that http://wikidata.org/wiki/Usuario:Aude would not work and this might not work for commons unless we had language codes in the url somewhere/somehow.
Comment 7 Nemo 2012-11-09 16:29:18 UTC
Yes, there are several wiki families out there which actually are a single multilingual wiki using language code based fake subdomains or subdirectories.
I've yet to see one that doesn't make your mind explode, though.
Comment 8 Daniel Kinzler 2012-11-12 09:23:44 UTC
Not a duplicate, bug 10342 calls for the namespace aliases to be based on the user language (which can't really work). This calls for all aliases to work on a multilingual wiki. This seems doable:

I think bug 41807 might provide a clean way to solve this. If the content language was "mul", we could simply copy all aliases for all languages into the "mul" pseudo-language.
Comment 9 Nemo 2012-11-12 09:32:45 UTC
(In reply to comment #8)
> Not a duplicate, bug 10342 calls for the namespace aliases to be based on the
> user language (which can't really work). This calls for all aliases to work on
> a multilingual wiki. This seems doable:
> 
> I think bug 41807 might provide a clean way to solve this. If the content
> language was "mul", we could simply copy all aliases for all languages into the
> "mul" pseudo-language.

You've not read comment 4, have you? The same name can be an alias for different namespaces in different languages.
This might not be a duplicate of bug 10342  and bug 20798, but the problems are the same.
Comment 10 Daniel Friesen 2012-11-12 09:38:23 UTC
You still haven't explained what we're going to do about Stampa: and Datoteka:.

Relevant wikitech-l thread:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56767

Platonides' note is also notable:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56767/focus=56784
Comment 11 Daniel Kinzler 2012-11-12 11:14:32 UTC
(In reply to comment #9)
> You've not read comment 4, have you? The same name can be an alias for
> different namespaces in different languages.

Yes. But since the aliases for "mul" can be defined manually, like the aliases fro other languages, it would be no problem to find alternatives for these languages. If not all namespaces for all languages will be the same as on wikipedia, I can live with it. 90% would be a great help.

(In reply to comment #10)
> You still haven't explained what we're going to do about Stampa: and Datoteka:

Just pick one and live with it. Making life easier for 90% of users is more important than an inconsistency in the long tail.
Comment 12 Yair Rand 2013-10-31 21:50:21 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > You still haven't explained what we're going to do about Stampa: and Datoteka:
> 
> Just pick one and live with it. Making life easier for 90% of users is more
> important than an inconsistency in the long tail.
I recommend prioritizing the languages with the most speakers, in this case Albanian and Serbo-Croatian. So "Stampa" = NS_TEMPLATE and "Datoteka" = NS_FILE.
Comment 13 Lydia Pintscher 2014-05-03 06:27:29 UTC
*** Bug 42028 has been marked as a duplicate of this bug. ***
Comment 14 Nemo 2014-05-03 14:14:00 UTC
Making the bug summary more general to clarify what's the actual bottleneck that prevents magic words, aliases and anything from mapping namespace in different languages.

(In reply to Niklas Laxström from comment #4)
> I doubt that. Nobody has suggested how to handle the conflicts.

> > You still haven't explained what we're going to do about Stampa: and Datoteka:
> 
> Just pick one and live with it. Making life easier for 90% of users is more
> important than an inconsistency in the long tail.

Sounds like a nightmare in the very likely case there is no universal agreement on what language should prevail (cf. comment 12) or, even worse, the prevailing language changes later (cf. http://www.w3.org/Provider/Style/URI.html ).

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


Navigation
Links