[XBoard-devel] Internationalization

[h.g. muller]

There are some static translations of WinBoard around (i.e. requiring 
recompilation,
and a separate executable for each language.) Mostly they are translations of
WB 4.27 or 4.2.6. I looked around a bit, and found Spanish, Chinese and Russian
translations.

I did extract the translations from the Chinese and Spanish versions, by 
semi-automatically
matching the translated winboard.rc with the one it was translated from. 
The Chinese
version had all substitutions in the C source files clearly marked, after 
commenting out
the English original, so I could easily extract that. The Spanish version 
made use of
a language.h file with sections of English and Spanish strings in string 
variables, and I
could easily correlate these by sorting on the variable name. I have not 
looked at the
Russian translation yet, because I seem to vaguely remember there exists a more
recent one.

So this game me Chinese and  Spanish translations in the form of a set of 
English strings
and the corresponding translated string, of earlier WB versions. Basically, 
the translations
are available as an editor script, or something that can be automatically 
converted into
an editor script.

Now some strings have been changed (by altering tabbing characters
and accelerator keystrokes listed in the menu items, for instance),
and there are many new strings as well. I extracted these from the sources
of the master branch. For backend.c this was easy, as they were already 
marked with
the gettext macro _(). The WB front-end files had no such markings yet, but 
the only file
with really many strings is winboard.c, and it was reasonably easy to 
discriminate against
strings intended for the debug file (which we do not translate) by first 
deleting all lines
containing the word debugFP. Some front-end files, like wgamelist.c or 
wsettings.c,
contained only 2 or 3 strings, which could easily be extracted by hand ith 
a text editor.
This finally resulted in a collection of all (?) strings in the current 
version we would like
to be translated.

It was quite easy to then use the existing translations as edit script to 
conver the list
of current strings into a translation script, which already specifies 
translations for those
strings that still exist unmodified in the current version. Slightly 
altered strings, for
which the translation was still valid could be copied into it by hand 
(which, admittedly,
was a bit of a pain). The new strings of course require a new translator; 
for the Chinese
version someone volunteered for this, so that is now complete. The Spanish 
translation
for current WB is still only partial.

It was also trival to use the list of translatable strings as an edit 
script to mark all strings
in the WB front-end files (other than winboard.rc) with the GNU gettext 
macro _().

I applied the (complete) Chinese translation edit script to backend.c and 
all WB front-end
files, (which was a pain), to generate a Chinese version. (Due to 
character-set differences
this only seems to work if it is actually compiled on a Chinese PC, but it 
does work.)
But of course we do not want to have separate executables for every language.
So I consider this Chinese translation a one-time effort, although the 
result is quite nice.

To avoid this cumbersome process in the future, I went through the one-time 
pain of
making a list of all dialog items used in each dialog (as defined in the 
winboard.rc file).
I had to define some 50 new item numbers, for the cases that were not 
unique before.
But after that, there now is a list (as 2D array) that tells WB which 
dialog contains
which items. I then made a small routine to loop through this list for a 
given dialog,
read out the current (=English) text associated with that item, look up a 
translation,
and set the item to that translated string. That makes the translation a 
fully dynamic
(= run-time) event. As I don't kow how to use gettext, I provideded my own 
routine
to be called wherever the _() macro is sitting, to translate the string. 
This was all very
straightforward (using stupid, but simple algorthms like linear search...).

So I have a WB version now that can read a translation script from a file
(controlled by the /language=FILENAME option), and then makes all substitutions
specified by the translation script in menus, dialogs,window titles and 
printed strings.
So the problem is now reduced to providng the translation scripts.
This still only works for lnguages that use the Roman character sets, as I 
do not mess
with fonts yet during run time. (I would not really know how to do that...)