Internationalization

[m-f-h]

Hello.
When I was trying to "import" data/games from a French web site, I noticed that it might be useful if the chess package could provide a "language" option, mainly for SAN/LAN notation in- and output.
Namely (as you can certainly also tell from discussions on forums, in vote chess games, etc. on chess.com, for example), an important proportion of players tend to have a strong preference for using the abbreviations in their native language, i.e.,
instead of the English "KQRBNP", they'd use the French "RDTFCP" (roi - dame - tour - fou - cavalier - pion) or German "KDTLSB" (König - Dame - Turm - Läufer - Springer - Bauer) or Spanish or other equivalents,
in particular in SAN/LAN notation.
Now of course it is not a big deal to implement that translation on one's own (esp. for SAN/LAN where you can almost blindly translate any uppercase letter to its equivalent), but I think it could be nice (and not lengthy) to provide a language option that could be set, e.g., to language codes ("en" (default & fallback), "fr", "de", ...) which could simply be used as index to corresponding tables in the corresponding places: for the 1-letter symbols used in SAN/LAN notation, and the pieces names (whereever these are really used...(are they, actually?))

Actually, one could argue that implementing / using these constants (chess.PIECE_NAMES) is already a manifest of using human language rather than chess programming, so it would be only fair to provide other languages than English.

I'd gladly propose corresponding changes in a pull request, but I think it could be efficient to first discuss the preferred way of implementing this here. My suggestions would be as follows:

provide an attribute Board.language (or Board.lang?) , or rather property, with a setter function that would

• substitute the default / fallback en in case the language isn't implemented (and/or handle a table of correspondences which might provide other fallbacks depending on language/country codes, e.g., "de" also for other German-speaking countries (at = Austria, ch = Switzerland, ...), "es" resp. "pt" in partuclar for South American countries using Spanish / Portugese, "fr" for French speaking countries as many African countries and parts of Canada, Switzerland, Belgium etcc (ca_FR, ch_FR...?), and so on)

• overwrite the corresponding "constants" (piece names and symbols, also COLOR_NAMES (which seems to be used nowhere so far)), unless it is judged better to change the code where these are used and use PIECE_NAMES[Board.language] instead (it is conceivable to leave entries 0..6 as is, in order to ensure backward compatibility and include the internationalized names as "sub-directories" indexed by the language/country code

• similarly for piece symbols. We should discuss whether the Board.language should only be used for input/output of SAN/LAN (and maybe PGN etc). Because there are instances where the English symbols are used where logically the constants (like chess.QUEEN and chess.WHITE should be used -- as for the indices in the UNICODE_PIECE_SYMBOLS ...) [As a side note, I think 0,1 would be preferrable to False,True for COLORS, given that there are variants with more than 2 colors.] So I fear that programmers might ("incorrectly" but frequently) use the English symbols also elsewhere instead of the appropriate constants.
  But use of localized SAN is really extremely popular.

(A related request was made in discussion #898 which I just discoverd, but that request was w.r.t. the FEN input/output. However, although legimitate, I think this less of an issue -- AFAIK, use of localized SAN is much much much more frequent and popular than "localized FEN" -- which I doubt even exists.)

Thanks in advance for any feedback on this idea.

[niklasf]

Sorry. Even for SAN I think it's best not to include and maintain i18n in this library. Applications will already have a localization system, and can then use it in the same way as #898 (reply in thread). Unfortunately that means translations will not be collected in this shared repository.

COLOR_NAMES and PIECE_NAMES are intended as machine-readable names, for example used identifiers in chess.svg.

The motivation for Color = bool is that it comes with a natural and very fast operator for getting the opposite color (not). An entirely new type would be cleanest, but might cost some performance.