On Sun, Mar 18, 2012 at 4:24 PM, Wouter Verhelst
<wouter@debian.org> wrote:
Yes, it is. What you're describing is a bug waiting to happen.
For comparison: there is no translator who translates to the 'nl_BE'
locale; all dutch translators translate to 'nl'. Yet there is no user
who uses an 'nl' locale; all users use 'nl_NL', 'nl_BE', 'nl_AR', or
whatnot. The locales system understands that Dutch is Dutch, no matter
where it's spoken, and will take the 'nl' translation when 'nl_BE' is
asked.
In the case of Dutch, that's perfectly reasonable, because there's only
one authority on the Dutch language (the Dutch Language Union). This
isn't just limited to Dutch, however; in simple programs, it could be
that the only needed strings aren't of the variant where there's a
difference between en_US and en_GB, in which case you'll end up with
just an 'en' translation.
This assumption that "'xx_YY' is just a specialized form of 'xx'" means
that it's okay to move files around if you find that there are
translations for this one specialized variant of ug but not for that
other, and your users are asking for a translation. When that happens,
with your scheme, suddenly you get a translation that jumps from one
script to the other all the time; this is even worse than having a
partially-translated program.
Also, the fact that one translation has such a bug shouldn't mean that
the other should, too.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Thank you so much for your explanation. It is crystal clear to me now.
ug_CN is a well established locale for Uyghur (Uighur) language in China, which uses modified Arabic-Persian. Then, what is the best way to name the Latin based Uyghur locale used globally? Should a locale be always tied up to a specific country?
Which one of the following names are best and acceptable? Could you please explain the pros and cons of each one?
ug@latin
ug_CN@latin
ug_US@latin
Thank you very much again.