Multi-Language Support

This section covers the overall concept of internationalization (i18n) in Servoy, including the setup, usage, and management of i18n messages.

Overview

Support for multiple languages, also known as i18n ('i' + 18 letters in 'nternationalizatio' + 'n'), is a Servoy feature that enables developing solutions that: + Do not require additional forms or elements to display more than one default language. + Can display multiple languages based on locale references. This feature includes language keys for every Servoy menu item as well as all Servoy system information, warning, and error dialogs. Additionally, it provides a complete set of locale message texts for Servoy i18n system language keys in German, Dutch (Netherlands), and Italian.

Default i18n table

Servoy provides i18n functions as part of the built-in Servoy Library, allowing developers to set and get i18n message keys and values programmatically within Servoy methods (scripts). This chapter gives a detailed view of the Servoy i18n feature and how to use it programmatically. See also the i18n section in Developer API for details.

Solutions Using Multiple Languages

To enable a solution to support more than one language, the following actions need to be performed:

• Assign or create an i18n table to store multiple language keys.

• Create the i18n language keys that will be used or edit any of the language keys included in Servoy.

Note that only the i18n table set on the main solution is taken into account. All i18n messages of the solution, including its modules, will be stored in that table. It is not possible to use a different i18n table in a module than the one used in the main solution.

The ideal time to start with i18n is at the beginning of building a solution, so the developer can enter the i18n keys when building forms and methods. It is also possible to enter i18n after finishing the solution by using the Externalize Strings feature.

Definition

Inside Servoy Developer, the message files are stored as property files in the workspace under resources > messages. At runtime, they are stored in the database. Thus, at some point before deploying to the server, the data in the workspace needs to be transferred to the database table. This can be done either at solution export, by checking the Export i18n data checkbox in the Export Wizard, or during design by right-clicking the I18N files node under Resources in Solution Explorer, and choosing Write to DB option from the context menu.

On the server, the messages are loaded into the i18n table specified in the solution settings. The table needs to have the following columns:

• message_id: (primary key, integer)

• message_key: (i18n key, string)

• message_language (i18n language, string)

• message_value: (i18n value, string)

Usage

On Servoy elements, it is possible to use a text reference, which is a key linked to a messages file. This key is replaced at runtime with the localized text from the messages file.

Labels, Buttons, Tabpanels, FieldTitles

In design, i18n can be set for such items in their text or textTitle property. On the text property, select the browse button. This will open a dialog:

Using i18n keys

Select the i18n:<messagekey>, move it to the right. In the Text panel you may write manually the key or select one of the existing keys in the i18n panel. As an example of an element text reference is: i18n:servoy.button.close, which is looked up in the messages file, produces the text in a locale like Close in English or Chiudi in Italian.

Dialogs, Calculations, Methods

To use i18n in scripting, use the function:

i18n.getMessage("i18n-key");

The i18n key has to be provided as a string.

Example:

var message = i18n.getMessage("servoy.general.clickOk");

The method will return the value of the language selected in the client. If the selected language has no entry, it will return the default value/reference text: 'Click OK to continue'.

It is also possible to use dynamic values. There can be an array provided with the values that have to be replaced. To use dynamic values, the i18n value should contain tags like {0}, {1}, ..., {n}. The tags will be replaced by the values provided in the same order.

var company_name = "Servoy";
var amount = 15;
var type = "developers";
var message = i18n.getMessage("servoy.license.registered", [company_name, amount, type]);

For example, if the key servoy.license.registered has the value 'Registered to {0} with {1} {2}', the outcome will be 'Registered to Servoy with 15 developers'.

When using i18n in a dialog, depending on the language of the user, the 'Yes' button can be 'Si', 'Ja', 'Oui', 'Hai', etc. To solve this, get the translation in a variable and use that to check which button is clicked.

Example:

function question() {
	var yes = i18n.getI18NMessage("servoy.lbl.yes");
	var no = i18n.getI18NMessage("servoy.lbl.no");
	var cancel = i18n.getI18NMessage("servoy.lbl.cancel");
	var answer = plugins.dialogs.showQuestionDialog("i18n:servoy.lbl.title", "i18n:servoy.lbl.message", yes, no, cancel);
	if(answer == yes) {
		application.output("yes is pressed");
		//execute code.
	}
}

Note that in dialogs it is not necessary to use the function i18n.getI18NMessage() but only i18n:key is enough.

I18N Key Names

The developer is free to create and use their own i18n key names. Nevertheless, it is a good idea to have a naming convention for this.

In general, there are two types of i18n keys:

• Short texts - which one could call labels.

• Long texts - like in dialogs, for example.

Example: This is an example of how to use naming convention

Sample naming convention:

• Labels: lbl.ok

• Dialogs: dlg.ok

Or using the company name as a prefix:

• Labels: servoy.lbl.ok

• Dialogs: servoy.dlg.ok

Date Format

In case of a date format, one can use for example: dd-MM-yyyy. This would be a nice formatted date in the Netherlands, but it might not in other countries. That's why it is a good idea to use i18n instead of a hard coded format. Instead of setting the string in the format, do set an i18n key in the format. For example: i18n:intl.lbl.date. In that i18n value, one can set for Dutch dd-MM-yyyy and for English (US) MM/dd/yyyy.

Overwriting i18n

An i18n message can be overwritten with the function i18n.setI18NMessage().

Example: When using i18n keys for date formats, let the users enter in the system how they prefer their date separator. Then when the user starts the system, use i18n.setI18NMessage() to replace the default separator with the user-defined separator. For example, in the i18n message the separator used is '/', but the user wants a '-' to separate the date. In the onOpen method the following code can be entered:

i18n.setI18NMessage('servoy.lbl.date', utils.stringReplace(i18n.getI18NMessage('servoy.lbl.date'),'/','-'))

Separators

Formatting defaults need to be specified. In the English (US) format, the dot ('.') is the decimal separator (and the comma is the 1000 separator). Decimal values within code need to be specified in the English format as well. This will automatically be translated to the end user's format when they run the code.

Example: In Dutch, the separator for decimals is a ','. In the format property of a field, the English format will be entered for a number (for example '#.00'). When a user with the locale Nederlands (Nederland) uses the solution and enters 23 into the field, it will display 23,00.

I18N Configuration

Problem Markers

Servoy provides support in Developer to enable problem markers on non-externalized strings found in scripting. By default, these type of problems is ignored, but this can be changed from Preferences page.

To enable the Externalized strings problem markers, go to Window > Preferences > JavaScript > Errors/Warnings > Externalized strings and set the problem severity level to warning, error, or info.

These problem markers can be suppressed at function level by using the @SuppressWarnings JavaDoc annotation with nls type, or at individual line level by using the //$NON-NLS-<n>$ comment at the end of the line that needs to have warnings suppressed.

Servoy provides a Quick Fix option for the Externalized strings problem markers, with the options of adding the @SuppressWarnings annotation at function level, inserting the //$NON-NLS-<n>$ tag at the end of the individual code line, or opening the Externalize strings wizard.

Save Action

Servoy offers a clean up option for automatically removing unnecessary Non-nls comments from code on saving a JavaScript file.

To enable this option, go to: Window > Preferences > JavaScript > Editor > Externalize Strings and check the Remove unused $NON-NLS$ tags on save option.

Localized Formatting

Servoy supports locale formats on numbers, integers, and dates.

There are four levels of setting the locale format:

1. Java Virtual Machine (JVM) level - setting the locale language, country and (optional) variant Java arguments. This will determine the formats used by the Servoy Clients. Since multiple countries may speak the same language, but the number/date formats are different from one country to another, the country argument is needed to ensure precision to the formats used by the application. Example: This is an example of setting the locales for Germany, with specific for Macintosh platforms.

-Duser.language=de -Duser.country=DE -Duser.variant=MAC

A number format used by Servoy will therefore be: 123.456,789 See more information on Oracle's page Internationalization: Understanding Locale in the Java Platform.

2. Servoy Application Server level - setting the Locale Settings on the Servoy Server Home page; the formats set will be applied to all fields that do not have a format set at table or field level.

3. table level - setting the Default format under Details tab on a column, in the Table Editor; the format set will be applied to all fields having the column as data provider, that do not have a format set on field level.

4. field level - setting the format property of a field in Properties view.

Timezones

In JavaScript (and Java), dates are always timestamps with the number of milliseconds which have passed since January 1st 1970 in UTC. Only when a date is displayed or converted to a string, the conversion to a certain timezone is done.

Example: If one calls application.getTimeStamp() at 8pm in Colombo, Sri Lanka and at 8pm in LA, California USA, two different timestamp values will be received. On the other hand, if two developers, one located in LA and one in Colombo would execute the code at exactly the same time, they would get exactly the same timestamp value, regardless of the timezone they are in.

The Servoy Application Server can be forced to run in a certain timezone, by including the following JVM argument in command line:

-Duser.timezone=US/Eastern

A complete table with the supported values of the timezone property can be found on Java SE 8 Documentation - TimeZone page.