Subject: Re: how should we localize locale names?
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Sat Mar 10 2001 - 03:04:43 CST
Hi Paul,
> ... then we should at least make translators lives saner by using more
> meaningful names -- eg, LANG_EN_US instead of LANG_3.
The translators do not translate based on the ID, they translate
based on the English value; it makes absolutely no difference
whether the language is called LANG_3 or LANG_EN_US, but
equally this is easy to change.
> We're already at 25 locales and growing, which suggests that we'd need
> N-squared localizations of these locale names. For example, with just three
> locales, you'd need 9 user-visible strings:
>
No you don't; you only need three visible strings, it the language
with which the whole interface is localised. (Of course you will need
9 for the 3 languages combined, but that is the nature of
localisation of the interface). I should underline that THESE ARE
NOT loacale names, they are langauge names. This has been
somewhat obscured by the format which we use for the property. It
makes only sense to distinguish between them when the rules of
the language are different and will require different dictionary for
spellchecking.
> ... then one alternative I've repeatedly suggested is to just report the
> localized name for that language *in* that language. Thus, you'd have:
consider this a *VERY* bad idea; if I have an application with a Czech interface
I expect to get the names of the languages in Czech; for lot of
languages most people could not even figure out what they are
(Russian vs. bulgarian, Hebrew, Arabic, not to mention Chinese or
Japanese).
> Plus which, it makes it far more likely that translations will be
> up-to-date. I doubt that Sioux or Catalan even *have* names for each
> other's languages, and defaulting both to en-US seems unpleasant.
I would be suprised if they did not - the Sioux and the Catalan
speakers live in the same world you do; it is probable that they
borrow the names of these languages from somewhere such as
Gaelic speakers use lot of English words.
> bottom line
> -----------
> I'd like to propose that we add a special case to the existing strings file
> format to include the *name* of that locale *in* that language. Then, when
> initializing the XAP_Language class, we can scan those strings files and
> just pluck out this one description.
> My hope is that there shouldn't be much of a charset issue here, since the
Of course there is goint to be a charset issue; the drawing front
end uses 8-bit char sets. You will get half of the list filled with the
nice circless ... And even if someone implements font set support,
you cannot expet people to install fonts for all the different
languages we want to support just to be able to read the langauge
list.
I really consider going down this way to be a very bad idea, not
only because it is going to cause technical difficulties, but
ultimately because it is going to produce a poor interface.
Tomas
This archive was generated by hypermail 2b25 : Sat Mar 10 2001 - 03:04:41 CST