Subject: how should we localize locale names?
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 07 2001 - 19:55:21 CST
In scanning the recent code mods for the new lang property, I noticed that
we're using the stringset mechanism for user-visible locale names.
Three comments:
1. If this is desirable, ...
-------------------------
... then we should at least make translators lives saner by using more
meaningful names -- eg, LANG_EN_US instead of LANG_3.
2. Is this in fact desirable?
------------------------------
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:
English -- United States (en-US)
French -- France (fr-FR)
German -- Germany (du-DE)
Allemand -- Allemagne (du-DE)
Anglais -- Etats-Unis (en-US)
Français -- France (fr-FR)
Englisch -- Vereinigter Staaten (en-US)
Französisch -- Frankreichs (fr-FR)
Deutsch -- Deutschland (du-DE)
While it's fun to play games with Babelfish, this certainly seems like it
could get out of hand pretty rapidly.
3. If this isn't desirable, ...
----------------------------
... then one alternative I've repeatedly suggested is to just report the
localized name for that language *in* that language. Thus, you'd have:
English -- United States (en-US)
Français -- France (fr-FR)
Deutsch -- Deutschland (du-DE)
The theory is that it's OK to have localized text here, because if you don't
recognize the name of the language *in* that language, you're unlikely to be
using it in your documents.
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.
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
strings import mechanisms (via expat at least) are already encoding-savvy.
However, we may need to do some platform-specific trickery to get the
resulting UCS2 strings to sort and display properly on the resulting menus
and/or dialogs.
How does that sound?
Paul,
wild-eyed dreamer
This archive was generated by hypermail 2b25 : Thu Mar 08 2001 - 00:09:40 CST