You can now comfortably localize (translate) your game.

Two approaches are possible:

1. Use our own localization class from the CastleLocalization unit. It can read from a number of translation formats (XML, JSON, CSV, GetText MO). It can translate user-interface controls, like TCastleLabel. The demo is inside examples/localization/custom/.

   For advanced users, the system allows to aid in localizing your custom classes too (see OnUpdateLocalization) and to add your own translation formats (see FileLoader).

   Thousand thanks go to Benedikt Magnus for developing this!

2. Use the standard GetText unit from FPC. You use GetText formats for translating (PO, MO), utilizing tools like PoEdit. The resourcestrings are translated automatically. The demo is inside examples/localization/gettext/.

   The engine uses resourcestrings for some internally-generated messages (and it will use them more), so these can be translated too.

In both cases, you can use a cross-platform CastleSystemLanguage unit that tells you the preferred user language.

Note that, while both approaches (GetText, our own) provide some infrastructure to aid you in translating (resourcestrings, special handling for UI controls), you can also translate things “explicitly” in both cases. Using the TMOFile.Translate(‘my_id’) in GetText, or Localization.Items[‘my_id’] in CastleLocalization.

So both systems are really flexible, and should fill all your needs 🙂

A related feature is also new TInputPressRelease.KeyString. This expresses key press as a string with UTF-8 encoding, and allows us to accept input of international characters across Castle Game Engine (for example in TCastleEdit). Many thanks go to Eugene Loza for this!