Re: [Bug-XBoard] [bug #34972] Several issues regarding lokalization

[h.g. muller]

Some quick remarks:

At 23:09 2-12-2011 +0000, Byrial Jensen wrote:
> 1) My testing shows several untranslatable strings:
>
> Unrecognized argument
> shuffle (in File > New Shuffle Game)
> randomize (in File > New Shuffle Game)
> pick fixed (in File > New Shuffle Game)

I think in 4.6 this dialog is now done by the generic popup, so this 
probably means
we forgot to put the N_() macro around the strings in the defiing table 
(shuffleOptions ?)

> Browse (title for File > Load/Save Game/Position)
> Filter on extensions: (in File > Load/Save Game/Position)
> OK (in File > Load/Save Game/Position)
> Cancel (in File > Load/Save Game/Position)

The above are all in the Ghostview file browser, which might not have been 
gettextized yet

> save changes (in Edit Tags + Comment)
> clear (in Edit Comment)
> Polyglot book not valid
> Engine (in Engine Output)
> Game-list options (window title)
> Hidden tags (in Game-list options)

The latter is one of the entries in the listbox. In general these must not 
be translated,
because they are names of tags in the PGN standard. But this one could be 
an exception.
we must make sure that it would still be recognized as the separator on 
reading it back
from the listbox to create the tag-order string, though.

> Stalemate (one of multiple game results)
> Black mates (one more of multiple game results)
> Xboard adjudication: Something (multiple strings)

Some of these strings might come from the engine or a PGN file.
The 'XBoard' adjudication' strings are tricky. They are used both for printing
in the messge field above the board, as well as for writing into the PGN file.
I discussed this on TalkChess, and the conclusion was that it is undesirable
to have the messages translated in PGN, as this is supposed to be a format
for interchanging files, and the one who cretes it will not always use the same
laguage as the one who reads it.

There is no harm in translating the strings just before they are printed in 
the message
field. (This is whatWinBoard currently does.) But when the original 
result-details string
comes from a PGN file made by an appliation other than XBoard, or directly from
the engine, there is no limit to the variation such messages can take.

> Everything in Engine #1/#2 Settings (Seems unfinished with dummy examples)

The options shown in the Engine Settigs dialogs are defined by the engine
To get them translated you would have to use a translated version of the 
engine.
Nothing XBoard can do about that; there are may hundreds of engines,
and new ones emerge every day, and there is no way to predict what option
names they wil try to display in the settings dialogs.

> Tourney participants (in Match Options)
> Everything in About Xboard window

I figured that for legal reasons copyright notices should better not be 
translated

> Direct command
> Send to chess program:
> P (pause button in board window)
> %s vs. %s (board title when playing)
> Game list not loaded or empty
> first (engineNames value)
> second (engineNames value)
>
> There may be more untranslatable strings. The strings above is just what I
> found in a test run.
>
> 2) The browse buttons in all windows are not resized to be able hold the
> translated text for the word "browse".

They are all generated by the generic popup, which gives them a pre-defined 
width.
I subtract that width from the preceeding text widget to get good alignment 
at the right margin.
Xaw does not seem to support automatic sizing of the widget to align both 
margins;
the only way I could get a non-ragged right margin is specify the size of 
every element.
This makes it difficult to adapt the size of the browse buttons to the text 
they contain.
It seems to need a two-step process, where we first realize the widget with 
a ragged right
margin, but auto-sized browse buttons, and then adjust the width of the 
preceeding text
widgets accordingly. This might ot be too difficult, though, as I seem to 
recall I do a second
pass anyway for adjusting the width of the preceeding text labels to that 
of the longest.
Presumably I could read otthe width of an auto-sized browse button before 
that, and
then also adjustthe width of the text widgets acordingly in that second pass.


> 3) Move notation is not translatable. The letter used for pieces in algebraic
> notation depends on the language.

It would require major changes in XBoard to do anything about that. Moves 
are not
only used for display, but also saved on PGN, communicated with engines, 
and with ICS.
I think using other move notation in PGN is acceptable, but require an 
extra tag redefining
the notation, which is currently not implemented. But engines and ICS would 
not accept
foreign notation (for promotion piece or FEN).
  XBoard already has a -pieceToCharTable option which can be used to set 
other piece IDs,
which could be used to read foreign PGN in game viewer mode, but these IDs 
are then used
globally throughout XBoard, which would break it for using engines or ICS. 
To avoid that,
XBoard would have to be re-written to have multiple pieceToCharTables, one 
for commuication
with each entity (user, input PGN file, output PGN file, first engine, 
second engine, ICS),
and parsing and generating moves would have to use the table applicable to 
source of
future destination (which currently is not always know; e.g. it generated 
one SAN move
for internal storage with the position, and then uses it later for multiple 
purposes).
  I admit that this is an issue that also annoys me quite often, so one 
day I might actually fix it.
Especially that different variants use different names for the same piece 
(Archbishop, Warlord,
Cardinal, Centaur, Hawk, Princess are all different names for the B+N 
compound!) is very
undesirable for storage of PGN in databases, or forimplementationof these 
variants on ICS.
It wouldalso be good to be able to read Xiangqi games with Chinese piece 
IDs, without also
having to write those then. (Although the -pieceNickNames option can help 
here.)


> 4) You use spaces in menus between menu item and the corresponding shortcut
> key to properly align the shortcut keys. This is next to impossible for the
> translators to do nicely.

Unfortunately the X-tool menus do render tabs as a small square, so the 
only alternative
seem to me not having any alignment at all. Which is exactly what you would 
get when
the translators would simply use single spaces, and thus would as only 
effect have that
the English version would also look crappy...


> 5) It is not a good idea to split a sentence in 2 translation units as in
> these 2:
>  "Sync after round    (for concurrent playing of a single"
>  "Sync after cycle      tourney with multiple XBoards)"

Agreed. But I did not see a better solution here. I am not sure such 
explanatory messages
belong in the dialogs at all. But because this was a new feature based on a 
entirely novel
concept for GUI tournaments, I decided to make an exception here.

H.G.