[XBoard-devel] WinBoard internationalization

[h.g. muller]

One of our JAWS customers wanted to have an Italian version of WinBoard JAWS.
Of course I told him that this is impossible, because all the strings are 
in the resource.
Then he said it might be posible to make a JAWS script to do the translation;
apparently JAWS can be programmed to make string substitutions in the 
output stream
on a per-application basis. I did not like this idea much, as although it 
would work perfectly
for the JAWS version, it would not benifit the standard version or users 
that rely partly
on the written texts. Translating is a significant effort, and if someone 
undertakes it,
it would be a waste if this was not generally useful.

So I explained him about the resource file, and he was willing to translate 
that.
Now it seemed a bad idea to have a dozen or so different winboard.rc files,
which would have to be all updated for any change we make in the resource.

So I extracted all strings from the resource files with a few edit commands,
and converted them to a format

"original message"==="translated message"

where the translated message of course is currently empty. I removed all 
duplicates
and things that obviously should not be translated (compiler commands like 
"Button"
or "RICHEDIT"), and sent him the file. I explained the use of & in the strings.

So let's see what he produces; in this format the file with substitutions 
should be
easily processible in an automatic way to create a modified winboard.rc.
My current plan is to convert it to an edit script for ed. (I guess sed 
would be an
alternative, but I have no experience with that.) I would convert the lines to

1,$g/"original message"/s//"translated message"/g

which in itself would require only three ed commands, add

w tmp.rc
q

at the end and then run

ed winboard.rc < script.it

This should give me the translated resource, and it could also be used to 
translate
any future modified resource. New or modified strings would of course remain
untranslated, unless someone updates the script, but this seems not such a 
big deal.

I am not sure if there are smarter ways to do this. Of course it is a pain 
that each
language would ned its own executable, rather than being configurable through a
small file with strings. I thought about having him chane all the IDC_STATIC
labels in the resource file to unique numbers (say in the 5000 range), so that
WinBoard could adapt them at run time with SetDialogItemText(). But I think
you can only do that when the dialog actually is up. That would require some
code that is called in the INIT part of every dialog window proc, which should
know what items belonged to that dialog.