[Ubuntu] Re: new language team
aras.noori at gmail.com
Tue Feb 13 00:20:33 GMT 2007
I am still prefering KU_IQ and KU_IR
and to differentiate between Arabic alphabet an Latin, we will write:
I hope this sugguestion solve this matter.
On 1/26/07, Carlos Perelló Marín <carlos.perello at canonical.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Danilo Segan escribió:
> > Hi Bardaqani,
> > Данас у 16:25, bardaqani bardaqani написа:
> >> English (Australia) en_au
> >> English (Canada) en_ca
> >> English (United Kingdom) en_uk
> > AU, CA, UK are ISO 3166 codes for these countries.
> >> en chinese
> >> Chinese (China)
> >> Chinese (Hong Kong)
> >> Chinese (Taiwan)
> > CH, HK, TW are ISO 3166 codes for these countries/territories.
> > This is no accident, it's a rule imposed by GNU libc locale naming
> > policy. And since we are providing translations for, among other
> > things, Ubuntu, which is GNU libc-based system, we have to follow such
> > naming scheme. Another reason to follow it is that you won't be able
> > to push your translation to different projects with non-standard names
> > (such as GNOME, KDE, GNU).
> > As for "political" issues, all Chinese Traditional translations used
> > to use zh_TW, even if it wasn't correct. It was just a work-around,
> > and it caused no problems.
> >> Language (Geographical Location/country)
> >> In case of Kurdish; Kurdish(Turkey/Iran/Iraq/Syria). However such a
> >> geographical indication is emotionally and politically loaded so we can
> >> avoid it by using the locally used terms:
> >> Kurdish (North) ku_no
> >> Kurdish (West) ku_we
> >> Kurdish (South) ku_so
> >> Kurdish (East) ku_ea
> > As explained above, this would not work. For example, "ku_NO" would
> > mean "Kurdish in Norway".
> >> so:
> >> ku at no
> >> ku at we
> >> ku at so
> >> ku at ea
> > Again, if you try to push this into GNU libc proper, you'll have to
> > make those modifiers full English words, so you'd end up with
> > 'ku at north', 'ku at west'...
> > However, this is problematic for Launchpad, since we don't yet support
> > variants, and you'd be unable to carry on your translation if we used
> > these identifiers.
> Well, in this case, I would prefer to not block it just because we don't
> support it atm in Rosetta. If that's the code decided to use, we should
> give more priority to that feature implementation and get it solved in
> Rosetta, I'm sure that there are other teams that will be quite happy
> having that implemented.
> So, until ISO 639-3 gets official, I'd rather
> > recommend using 'ku_CC' where CC is ISO 3166 country code for wherever
> > is this variant spoken the most.
> > Just like Chinese Traditional is commonly using 'politically loaded'
> > 'zh_TW'.
> >> I think the solution is found somewhere in the above mentioned urgument.
> >> From my point of view the three-letter iso639-3 code represents nothing in
> >> case of Kurdish. Please be aware of the fact that there is no language
> >> or sub-language called Central Kurdish.
> > Just for the reason that everybody's personal opinion is going to
> > differ, I strongly believe we should trust such decision making to
> > international standards organisation such as ISO, Unicode, IETF, etc.
> > (IETF is managing language-tags scheme; does anyone know what they
> > recommend for this variant in their RFC?)
> > Cheers,
> > Danilo
> - --
> Carlos Perelló Marín
> Ubuntu => http://www.ubuntu.com
> mailto:carlos.perello at canonical.com
> Alicante - Spain
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
More information about the rosetta-users