I made some progress with i18n for windows, by implementing two work arounds:
1) we can't use the 'extended' fprintf functionality (format string with
positions, see section 15.3.1 "C Format Strings" of
on windows. For whatever reasons the fprintf replacement crashes when
printing to stderr. I used an ugly "#undef fprintf" so that calls to
fprintf are not replaced with the gettext version. I don't think that
this will be important for use, since (imho) we should only translate
messages which are shown on the screen in graphics mode (not stdout/stderr).
2) While gettext defines its own LC_MESSAGES category if it's not defined, this
feature doesn't work with Visual Studio's setlocale(), since setlocale
tests for a valid category (and LC_MESSAGES isn't). As an even uglier
work around I used LC_CTYPE instead, and strangely enough: it works.
*sigh* Don't ask me.
End result: I have translations working now (tested with the German translation)
on windows (and linux as well, without any problems).
One issue still exists: the menu font (AvantGarde-Demi.txf) does not support
full Latin-1 encoding, only ASCII characters. I have a ttf of this font with
all important characters, and could try to create a new txf font - but I thought
we should first agree if we want to keep on using two different fonts in STK
(menu font, GUI font). Any preferences?
And 2nd question: while I have mentioned above that only messages displayed
on the screen should be translated, currently some warnings/error
messages are translated as well. I'd say that we remove the _() around all these
messages, to make the task for translators easier (and for us as well, since it
should be less work to maintain the message catalogues). Again: comments?
Get latest updates about Open Source Projects, Conferences and News.