h.g. muller <h.g.muller <at> hccnet.nl>
2010-08-24 11:02:58 GMT
There are some static translations of WinBoard around (i.e. requiring
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
I did extract the translations from the Chinese and Spanish versions, by
matching the translated winboard.rc with the one it was translated from.
version had all substitutions in the C source files clearly marked, after
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
So this game me Chinese and Spanish translations in the form of a set of
and the corresponding translated string, of earlier WB versions. Basically,
are available as an editor script, or something that can be automatically
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
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
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
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
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
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
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
this only seems to work if it is actually compiled on a Chinese PC, but it
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
making a list of all dialog items used in each dialog (as defined in the
I had to define some 50 new item numbers, for the cases that were not
But after that, there now is a list (as 2D array) that tells WB which
which items. I then made a small routine to loop through this list for a
read out the current (=English) text associated with that item, look up a
and set the item to that translated string. That makes the translation a
(= run-time) event. As I don't kow how to use gettext, I provideded my own
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
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...)