Winboard Forum

Sorry, I could not resist!

I just stumbled upon this little bug. When running WB localized in italian and with the -debug option, I see this in the debug file:

Code: Select all

recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
WinBoard 4.5.1 + gaviota
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
TC string = ':40/1800'
mps=40 tc=1800000 inc=0
TC string = ':40/1800'
mps=40 tc=1800000 inc=0
StartChildProcess (dir="..\gaviota") gaviota.exe
nice engine proc to 10
969 >primo : xboard
protover 2
1047 <primo : Gaviota v0.75.7
1047 <primo : Copyright (c) 2000-2010 Miguel A. Ballicora
1047 <primo : There is NO WARRANTY of any kind
1047 <primo : # mode = winboard/xboard
1047 <primo : # Type 'screen' for a better output in console mode
1047 <primo : # Type 'help' for a list of useful commands
1047 <primo :
2860 <primo : feature done=0
2860 >primo : accepted done
...

As you can see the word "first" gets translated as "primo" (that is the italian word for "first", specified in the italian language file). This seems wrong to me, as it would break many utilities that parse the content of the debug file.

Cheers,

Giorgio

Arghhh!

This is an unintended side effect of translation. Apparently WinBoard uses the same strings for indicating the engine in many messages in the debug file, as well as in many message that are shown to the user in popups (cps->which). I guess I will have to divorce those two groups, leaving the original string untouched, and applying translation on it everywhere it is used for printing to a popup...

This sounds as a great deal of work...

Well, it was not too bad; I did it everywhere in the source file backend.c, which contains by far the most code. Fortunately it is always very obvous in the code if something is intended for the debug file. Problem is to also search all the smaller files for "cps->which". My favorite search command "grep" that can search all files simultaneous does not seem to work for strings with ">" in them...

Anyway, the worst that can happen in my fixed version is that in messages shown to the user the words "first" and "second" show up untranslated. I guess we can live with that.