Although this is all true, it does not realy help much to solve the problem. Which is: how can we present the engine options to WinBoard users in their own native language, also used by WnBoard.
The most practical solution seems to be to let WinBoard translation work on the option names. Perhaps in a limited way: allow every WinBoard language file to contain an [engine] section, which will contain the list of substitutions that should be applied to the engine option names. Or, better perhaps, WinBoard could look for translation files with the same name as the one in force for its own translation in the engine folder, and if there is one, apply it to the option names. This allows every engine to include its own translations with the engine install. But people could also distribute translations into a particular language for all options of a group of their favorite engines.
There would be no need for any non-ASCI in the option names in that case, and I guess we should simply forbid it.
That leaves the problem of filename encoding. I still see an advantage to reqire the user to supply the exact bit pattern that the OS on which the engine is running will understand as the intended file. This works trivially on every OS as long as GUI and engine run on the same OS. This seems to offer better chances for success as enforcing any particular encoding.
Suppose I want to run engine X (say Gaviota) on a Chinese Windows through WinBoard running on my English windows, and the tablebase folder on the Chinese system has some name spelled in Chinese... I could put in the WB protocol specs that filenames are transferred in UTF-8, and let WB send the Chinese filename in UTF-8. How big are the chances now that engine X would start to translate that filename to bg2312 encoding before accessing its tablebases? Close to zero seems a very good guess. Even if the engine author had been aware of the UTF-8 requirement, he would be very unlikely to make the effort to make sure the engine was able to use filenames spelled in Chinese.
OTOH, when the standard was such that the engine could use the byte string given to it as filename unmodified, virtualy every engine would naturally do it, and it could work even when the engine was running on systems using encodings the engine author had never heard of.
WinBoard translations
Moderator: Ras
-
hgm
- Posts: 28404
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
Harald
- Posts: 318
- Joined: Thu Mar 09, 2006 1:07 am
Re: WinBoard translations
Hi, Let me tell you what I think about languages in Winboard.
My background are the automotive industry and navigation databases.
There should be two modes in Winboard.
- The old and default mode is just the current state.
The only language allowed should be english.
The only encoding should be ISO-8859-1 (Latin-1).
Whenever an engine does something else it is not Winboard's problem.
Just live with it.
- The second mode is more interesting. It should be agreed upon between
Winboard and each engine with the typical startup option parameters.
You have successfully controlled every other change with this method.
If the agreement is "languages==true" or "accepted" then these rules
must be followed:
The communication between Winboard and the engine must be Unicode encoded in UTF-8.
If the chinese people can live with UTF-8 in navigation systems they can live with it in chess.
Each real word or sentence in the communication must have a language
attached to it. This can be a hidden tag or attribute in each text
or in a global state. Visible in the pipes, not for the user.
The languages must be given in ISO-639-1 alpha-3. ("ENG", "GER", ...)
If you must provide a dialogue in Winbord to the user to choose a language
then you need the names of each language at least in english or you use
this 3 letter code.
There may be some work to do in winboard to change the encoding
in the communication between Winboard, the engines and the OS.
You should also add an UTF-8 tag and language tags to the PGN output of games,
perhaps for each side if both engines include comments.
[encoding=UTF-8]
[white_language=ENG]
[black_language=GER]
The general idea is to use existing formats and rules and then
make them mandatory and enforce their usage.
Perhaps the ideas above are not well thought through every situation
and the details may be wrong, but these are just my 2 cent.
Oh boy, what a lot of work to do!
Harald
My background are the automotive industry and navigation databases.
There should be two modes in Winboard.
- The old and default mode is just the current state.
The only language allowed should be english.
The only encoding should be ISO-8859-1 (Latin-1).
Whenever an engine does something else it is not Winboard's problem.
Just live with it.
- The second mode is more interesting. It should be agreed upon between
Winboard and each engine with the typical startup option parameters.
You have successfully controlled every other change with this method.
If the agreement is "languages==true" or "accepted" then these rules
must be followed:
The communication between Winboard and the engine must be Unicode encoded in UTF-8.
If the chinese people can live with UTF-8 in navigation systems they can live with it in chess.
Each real word or sentence in the communication must have a language
attached to it. This can be a hidden tag or attribute in each text
or in a global state. Visible in the pipes, not for the user.
The languages must be given in ISO-639-1 alpha-3. ("ENG", "GER", ...)
If you must provide a dialogue in Winbord to the user to choose a language
then you need the names of each language at least in english or you use
this 3 letter code.
There may be some work to do in winboard to change the encoding
in the communication between Winboard, the engines and the OS.
You should also add an UTF-8 tag and language tags to the PGN output of games,
perhaps for each side if both engines include comments.
[encoding=UTF-8]
[white_language=ENG]
[black_language=GER]
The general idea is to use existing formats and rules and then
make them mandatory and enforce their usage.
Perhaps the ideas above are not well thought through every situation
and the details may be wrong, but these are just my 2 cent.
Oh boy, what a lot of work to do!
Harald