L10n:Locale Codes
We might want to support/allow generic 2/3-letter language names without an ISO 3166 region identifier.
For example, someone's working on Esperanto, which has no region. Or our current German builds are actually a generic German L10n, usable for all countries which use German, not just Germany (de-DE, aviary) or Austria (de-AT, SeaMonkey). I'm sure there are other examples. Does anything speak against allowing language names like "de", "eo" et al.?
Some comments from different people about that idea and eventual problems:
<dveditz> KaiRo: it's not something I'm going to spend much time on, but if you can identify what needs to change and what stands in the way I'll help work out any roadblocks
I talked to gandalf if there are issues with the build system, and he tested it for FF trunk:
<gandalf> KaiRo: --enable-locale-ui=pl works ok.
bsmedberg noted there are some problems in other areas though:
<bsmedberg> The tinderbox build system will choke, however.
<bsmedberg> Because it uses regex like [a-z]{2,3}-[A-Z]{2,3} to ship files and such.
Chase could clear up the problems with tools a bit more:
<KaiRo> Chase: the exact specification for what it could be is \w{2-3}(-\w{2}(-\w+)?)? - but we don't expect to get any with a thrid part (dialects) soon, so it's best to use \w{2-3}(-\w{2})?
<KaiRo> Chase: so what tools are relying on the region right now (guessing out of your head)?
<Chase> My automation scripts, download.m.o redirect tool, mirror management. Additionally we need to know about it to properly prepare for the correct way to update clients.
<Chase> My concerns specifically concern dmo and the update client code.
<Chase> We need to think that out thoroughly and prepare for what life may be like for us in a year (since we'll still have 1.0/1.0.1/1.1 clients out there at that time that should be able to handle changes).
As a side note, the mozilla-world.org domain (operated by Mozilla Europe) now shortens locale names in that way by default (after I had some talk with peterv about that matter), see their language navigation at the bottom.
After recent discussions, someone wanting to register for venetian, which has no ISO 639.2 code, and some of our people even reading the "language tag" RFC 3066, it seems we want to support the third (dialect) part of locale codes as well. That's extremely useful for languages that have no ISO 639.2 code defined, as we can use a generic code (like e.g. roa) and add the SIL code as the "dialect" identifier. This way, we stay inside standardized values and can nicely support those languages we had problems with in the old scheme.