This is the mail archive of the xconq7@sourceware.cygnus.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: internationalization


Stan Shebs <shebs@cygnus.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 ().
Cfr. http://wwwwbs.cs.tu-berlin.de/user/czyborra/charsets/

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
Now.

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:

; dict-it.g
(dictionary-entry "battleship"
    (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.

	Massimo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]