This has already been WONTFIX'ed at least two times and probably more, see bug 10342, bug 20798.

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?

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

I doubt that. Nobody has suggested how to handle the conflicts.

• This bug has been marked as a duplicate of bug 10342 ***

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.

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.

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.

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

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

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

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

• Bug 42028 has been marked as a duplicate of this bug. ***

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

@He7d3r considering T12342 was declined in 2007, and did not discuss multilingual wikis as far as I can tell, perhaps it makes sense to discuss this again. IIf you think this is a dupe, the consequence would be to re-open the original ticket. What do you think?