https://bugzilla.wikimedia.org/show_bug.cgi?id=41807
--- Comment #4 from Daniel Kinzler <[email protected]> 2012-11-06 09:21:44 UTC --- (In reply to comment #3) > Using mul is not a replacement for tagging the content correctly. Yes, and that's not what I'm suggesting. Ok, here's the use case. Consider a wikidata page with labels in 20 languages. Each label will be tagged in the HTML code with the correct language and directionality attributes. However: * What do we put into the HTTP Content-Language header? I think "mul" would be correct there. Similarly, when supplying DC meta data about a page (as the OAI extension does), there is only one language code that can be provided, so "mul" would be the correct choice. * More urgently, we need a code that we can use as a general fallback - Many things (especially people and places, i.e. over 50% of the content of wikipedia and thus wikidata) have "native" versions of their name that should act as a fallback for all other languages - and that name is indeed the correct one for *multiple* languages. I doubt that there are renderings for the town "Rackwitz" in languages other than German. Having to set this string redundantly for 300 languages makes no sense to me. So, setting "Rackwitz" as the value for the "mul" code, and falling back on this, makes sense. Using "en" for this purpose would be grossly misleading, especially in cases where the "native" form is not using latin characters (say, Руза). * Also, what language to we announce for the entire wiki? The API, site matrix, etc can tell you which wiki has which content language. Using "en" for multilingual wikis is annoying. I see no reason not to get rid of that lie. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
