[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: h.g. muller
Subject: Re: [Bug-XBoard] [bug #34972] Several issues regarding lokalization
Date: Sat, 03 Dec 2011 12:02:53 +0100

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]