Vassal 4

Goals

 * Import modules created with other GameBox tools including Vassal 3, cyber-board, ZunTzu

Internationalization (I18n) and Localization (L10n) (1 Aug 17)
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.

Game Piece Definitions stored in saved games and log files (1 Aug 17)
There has been some discussion over the 'problem' in V3 that a definition of each Game Pieces is copied from the module and stored in each Save Game and Log File and how this will be fixed in V4. In V4, minimal information about the structure of a game Piece will be stored in Save and Log files, the structure of the piece will be sourced from the module.

I have no opinion on whether the V3 way or V4 way is better, however, there are significant implications of changing this that need to be appreciated and should be taken into account in the design of V4.

Implications of the V3 way
The original designer of Vassal considered it an important design goal that when a log file was played back, it would always show exactly what occurred during the original creation of the log file, even on a later version of the module where the Game Piece definitions may have been modified.

Pros

 * Playback guaranteed to reproduce original game moves.
 * Don't need to keep track of old versions of modules to play back old log files. (Except where a module has undergone major surgery and become incompatible).
 * There is consistent behavior if players are playing with two different versions of the module. A particular Game Piece will behave the same for both players.

Cons

 * Increases size of log and save files.
 * Save files require conversion to update the definitions of pieces they contain.
 * There is no way to update save files if there have been structural changes to the module (add/remove map windows, move/change Decks).

Implications of the V4 way
It is not clear exactly what information will be contained in V4 save and log files, but the general consensus seems to be that people would like to move away from the current system to one where the Game Piece definitions are not stored in save and log files.

Pros

 * Smaller log & save files
 * Log and save files will auto-update to match the version of the module they are running on.
 * (Possibly) No need to convert save files to work on a new version of the module.

Cons

 * If a log file is replayed on any version of the module except for EXACTLY the same one the log file was created with, there is no guarantee you will see what actually happened in the initial creation of the log file. It is up to players to keep track of every version of every module they have ever used if they want ensure log file replayability.
 * Inconsistent behavior if players are using different versions of the module. A single game Piece may behave differently for each player.

Issues

 * It will probably require players to be far more aware of what version of the module is being used by other players.
 * Playing rooms on servers should probably have default setting that players are not allowed to join a game unless that have the same version of the module.
 * We will probably need a different structure for the module manager where save and log files are grouped and displayed with the version of the module they where created with.