Internationalisation programmation

Why

The common method using resource strings is a little tedious to implement. It requires development environment and programming skills to make translations available.

That's why I have used another system, with some success on a large application.

Translation are read by the software from mere inifiles and applied when forms are loaded. This is quick enough.

This way, it is possible to define or modify translations directly when running the application, without developing tools and skills.

How it works ?

Language file

One inifile by language must be provided.

Currently it is stored in the languages subdirectory of the directory containg the main executable : The name of the file is made from the Posix code of the language (en_US for English American, fr_FR for french...)

The Parameter file must (at least) contains a parameter in the General Section for the name of the language (in it's language).

[General]

LanguageName=English

Each parameter files named language/%%_%%.ini, and having this valid parameter, will make a language available in the application.

Thus, there is no need to recompile anything to add a new language.

Simple controls

For Edit, Label, Buttons, MainMenu, PopupMenu (or Gedit, GLabel, GButton, GMainMenu, GPopupMenu in gestinux 1.0)

The sections is the Form name. The parameter name is the component name, followed by a dot and the property name. The parameter value is the translation

E.g :

[FormConnection]

LabelUsername.Caption=Username

EditUsername.Hint=Enter your username

BtnOk.caption=Connect

BtnOk.Hint=Click here to connect

MenuItemQuit.Caption=Exit

In gestinux 0.5, to load the translations, we call TranslateForm(Self) in the OnCreate Form event. If the file or the parameter is not found, the design properties are used. This procedure can be called also when the language is changed, to have a dynamic translation.

In gestinux 1.0, we should use specific visual components and forms and there is nothing to do. The translation is automatic.

CustomStringGrids, dBGrids

Or for GGrid and GDbGrid in gestinux 1.0

For each column, indexed by its position, we can define the title

E.g :

Grid.Employees.0.Title=Name

Grid.Employees.1.Title=Address

Grid.Employees.2.Title=City

The Columns property must be defined to allow translations (and other features).

---

Messages

Messages are identified by keywords not used for control's translations.

In gestinux 0.5 Messages are stored in a special section [Messages]. In gestinux 1.0 they are stored in the form section, along with other control's translations.

Parameters are allowed. Example :

UsernameConnectError=%1:s in not a valid username, retry.

MessageDlg and ShowMessage procedures must not be used, since they don't use the same translation system. To display a translated message, we use special procedures :

ErrorMessage ( 'UsernameConnectError', [EditUsername.Text] );

ConfirmationMessage ( 'UsernameConnectError', [EditUsername.Text] );

InformationMessage ( 'UsernameConnectError', [EditUsername.Text] );

Other strings

Other parameters can be present in the ini file, for special usages. Their translations can be queried at any time by :

TranslateText( Section, Key, Default );

Other controls

It is necessary to be able to set the appropriate properties, depending on the type.

Some types of controls are not translated today in the translation module, because I do not need a text currently. For example, TSpeedButton.Hint is not translated, but it should be easy to do this, by adding a few lines in UnitTranslation.pas.

We should always refer to the highest possible ancestor, so there is no problem with descendants.

Translation tools

There is a translation utility, available for Linux and for Windows, which can read a reference language file, and fill another language file, detecting missing translations.

Let us know, using the forum, if you want to translate in your mother language.

Potential evolution

In gestinux 1.0 we use a package with descendants of all types of visual controls. They are translated after they are loaded, without a line of code in application programs.

Later, we plan to open a form when right-clicking over the component, to enter the translation, and store it in the language inifile.