This is the mail archive of the
mailing list for the Xconq project.
- To: Stan Shebs <firstname.lastname@example.org>
- Subject: Re: internationalization
- From: Massimo Campostrini <email@example.com>
- Date: 28 Apr 1998 15:58:58 +0200
- Cc: firstname.lastname@example.org
- References: <199804280232.TAA03681@leda.cygnus.com.>
Stan Shebs <email@example.com> writes:
> Character sets I'm not too experienced with - what does the code have
> to do differently? Presumably any a-z tests are bogus, what else?
I don't know the Mac's approach to non-ASCII characters. In X, you
can pick a font containing all the characters your language needs
(including characters with diacritics, ligatures etc.). The
ISO-8859-1 standard (256 characters, the first 128 coinciding with
ASCII) contains everything needed for the most popular western
European languages; Jan Javorsek would use a ISO-8859-2 font, which
supports several Slavic languages written in the Latin alphabet. For
example, if I select a ISO-8859-1 font and I print character 203 I get
an uppercase `E' with umlaut (Ë).
A minimalist approach in an X-only Xconq would be to select a charset
(per language?), then code all the strings (in relevant .c and .g
files) in the given charset. This would mean that we can't mix
languages at will. And I guess it's not portable.
To really tackle the problem, we must
0) choose a character set large enough to display all the desired languages;
1) choose an internal representation for the character set;
2) implement character display on every front-end.
An ultimate solution would be adopting Unicode (ISO-10646). The
internal representation could be UTF-8, which is compatible with
ASCII. Unicode support is getting widespread; we can hope that
Unicode software and fonts will be available on most systems Real Soon
Any Unicode expert out there? Are there good free X unicode fonts? Mac?
> You should try a first pass with the current code, see what the results
> look like. I don't have a good sense for the current flexibility; while
> I know some German and a bit of French, I also know that only native
> speakers should attempt to generate the actual phrases!
I got bogged down immediately by the lack of grammar support. I would
produce Italian unfit for a second grade homework. English is the
only language I know of that is so blissfully simple that grammar
support is not required. :-)
Jan Javorsek informed me (did he cc to the list?) that Slovenian has
declensions and the dual case, like classical Greek; once Slovenian is
supported, I think that all Indo-European languages can be generated.
> Incidentally, Ulrich Drepper (Herr GNU gettext) is here at Cygnus now,
> and has been helping with the gettextization of GNU tools. That is a
> somewhat different approach that we could take, in which wired-in English
> strings get translated at runtime.
Can you point me to an example? I don't see how this can be possible
for non-trivial text.
> In theory, this could be extended
> to a per-player per-GDL regime - it occurs to me that it could clutter
> up GDL files to have every reference to "battleship" have to have French,
> Italian, Dutch, etc translations glued in...
Or we could have dictionaries, such that no duplication of
translations is needed:
(italian "corazzata" (plural "corazzate") (gender female)))
(this assumes that English is the "master language" :-)).
On second thought, this is not flexible enough: different games could
need different translations of the same word etc; so it must be
complemented by a way of choosing between alternate translations.