Re: Adding New Script Variants on Debian Installer
On Sun, Mar 18, 2012 at 07:13:43AM -0500, Eagle Burkut wrote:
> Before we came to that naming convention, we did a quite bit of research. There
> are couple of obstacles to adopt the other idea. First of all, the FontConfig
> library does not support with language/script variant with @ such as ug_CN, and
> ug_CN@latin. There is no way to develop a orthography rule file for ug_CN@latin
> and have it included in FontConfig. Secondly, the online translation platform
> Launchpad does not support another language/script variant of the same language
> in same country. These are originally design issues and in the near foreseeable
> future, there is no clear indication that there will be a fix. And lastly,
> while doing a research on this issue, the Kurdish language in Turkey, Iraq and
> Iran draw our attention. There are just language and country code, no @
> variants. Our case is exactly same as of Kurdish, nothing more or nothing less.
> The @ variant has to be used for the same language in same country, such as
> uz_UZ@latin and uz_UZ@cyrillic. For same the language in different countries,
> there is no need to add the @ variant, such as in the case of Kurdish. And in
> our case, for the same language, different writing systems are used in
> different countries, not in the same one country, thus we think the @ variant
> is not necessary.
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
Reply to: