Vassal 4:Design Blog 2

1-Aug-17 Internationalization (I18n) and Localization (L10n) requirements for Vassal 4

Internationalization is the process of designing and building an application to facilitate Localization. Localization, in turn, is the cultural and linguistic adaption of an internationalized application for multiple culturally-distinct markets.

I18n prepares your application for L10n and is done by the developers. L10n is done by a translator to translate the individual messages in an application into the target language.

In Vassal 3 (V3), L18n was retro-fitted quite late in the development cycle and there was no support for it at all in the initial design. The 3 program components of V3, the Module Manager, Player and Editor where relatively easy to Internationalize, using the I18n tools supplied with Java. Applying I18n to V3 modules was, however, technically difficult and achieved with only moderate success.

Issues with Vassal 3 I18n

It is not possible to include any comments to translators with guidelines on how to translate a particular string. This is especially a problem in module L10n.
It is not possible to display a different version of an image based on the selected language.
The V3 implementation is a bit quirky. It can be difficult to select the language you want if it is different from the language recorded on your computer, or if the base language of the module is not English.
The text generated by translated modules is hard-coded into the chat window and log file. So if you have an English player playing the English translation and a French player playing the French translation of the module, the English played sees all game messages generated by the French player in French and the French player sees all of the messages generated by the English player in English. If a third player joins the game as observer using the German translation of the module, they will see no German at all, just English and French.

Requirements for Vassal 4 I18n

Use an industry standard tool for I18n. GNU gettext?
I18n support needs to be built-in from day 1 in the server, the client and into the modules themselves.
Where necessary, Programmers should include comments to translators in the Vassal program source that will be extracted by a utility such as xgettext.
All translatable Strings in a Vassal module need to be recorded in a data structure that includes an Id unique within the module and also allows for the inclusion of comments for translators. Translator comments are especially important for modules where Strings are often single words or partial sentences. In general use, a module developer would not see these, but there should be a widget to click to pop-up the 'Translator Comments' window on any text input field. We can also provide tools similar to the existing V3 module translation tools to add Translator comments in bulk.
Should module translation be done externally using gettext tools, or do we build our own tool into V4?
All images within Vassal 4 should have in-built support for alternate images based on the selected language. Display of the correct image is handled locally by the client. Image translation is not needed for many modules, but is lack is painful when it is needed.
Log files (and 'commands' sent between clients) should include references to the unique message Id's, not the text of the messages. Translation should be performed by the client using the message Id's to source the text from the module translation being used by that client. This would allow players to participate in a game using different module translations and would see the game generated text from other clients in their own language. Obviously, player initiated chat cannot be translated. A third played viewing the log file in a third language would see the game generated text in their language, even though that language was never used when the log file was generated.