Internationalization - I18N
[Previous] [Main] [Next]

Internationalization - I18N

Top of the Generated Screen - in Spanish

Writing Internationalized (often called I18N since there are 18 letters between the I and the N) code involves at least three different levels of attention.

·Translating and displaying the visible text.  
· Using area appropriate forms for dates, times, currency, numbers telephone numbers, and icons  
· Collecting appropriate data  

Translating and displaying the visible text

Java is very aware of I18N issues and comes with several systems built in to make I18N easier. If you set up your code right, you can display screens in several languages simply by including a text file that contains the translations. These are called resource bundles. JGuiGen automatically generates an English resource bundle with each class that it creates. All of the components on the screen look up any text that they display from these resource bundles. For example if the class being generated is Users.class, JGuiGen will creates file. This contains key=value pairs for each item that displays text on the screen. The file might start like this:

Screen_Title=Users Screen
Last\ Name=Last Name
First\ Name=First Name
Start\ Date=Start Date.

The Spanish version might say
Screen_Title=Español Pantalla Del Usuario
Start\ Date= Comience Fecha
Last\ Name= Nombre Pasado
First\ Name=Nom. Gado/Pasado

The I18N system uses a system of languages/ locales and variants to figure out which of the properties to use. When your Java Virtual Machine (JVM) starts up it decides upon a default language and locale based upon your system defaults. My machines start with English and USA as the language and Locale. Someone in Mexico City might have Spanish and Mexico for their defaults. These are represented by two lower case letters for the language and two upper case letter for the Locale. I'm going to ignore the variant section right now. You can change these defaults programmatically and allow your application to display a different language than your default.

Java takes these letter pairs and uses them as extensions to the properties file names. For example - base properties file - base English properties file - English - USA version - English - Great Britain version - base Spanish version - Spanish - Mexican version - Spanish - version for Spain

These files are loading into your JVM and search automatically. If you have a key called Screen_Title and your are using English in the USA, your application will automatically look first for a "Screen_Title=??" in the file. If that file doesn't exist or does not contain the key, your application looks in Again if the file doesn't exist or the key doesn't exist, the system automatically looks in If the key is missing there, your application throws and exception.

In a similar manner, when the defaults are Spanish, Mexico, the system looks in, then and finally in

You can use this hierarchy to only supply translations in the file that differ from the basic file. For example if the only difference between the basic English version of your properties file and the Great Britain version is the word "Color" in your English file should be "Colour" for Great Britain, the file would only need to contain one key=value pair, the one that has "Colour" as the value. The rest of the keys will be resolved in the file.

There are several tutorials on-line that cover this in much more detail.
<Add Links here>

Another part of displaying the text is to use an appropriate font and apply this font to the various components that display text. <add links here>

SPECIAL NOTE: Many of the prompts in JGuiGen (such as the menu items) are share across application. This means that as soon as you generate an application a good bit of it is already translated into several other languages. See the popup screen for examples I18n Examples.

Using area appropriate forms

If you look closely, you might notice that the Icon that has been used to replace the coffee cup is different in this version than it was in the Top of Screen shot for the English version. The SetIcon class automatically looks for the gif file you tell it to use in an images/language_locale folder (e.g. images/es_MX) and then in an images/language (e.g. images/es) and finally in the images folder. Placing icons and other gifs used by your application in these folders will allow you to have different gifs for different languages and locale.

The JVM automatically creates default formats for dates, numbers, currency, etc. There are a number of examples in the code.

Some of the format (such as the format for a telephone number) are placed in the resource bundle files. You can fill in the appropriate format when you translate this file. There are a number of web sites that contain information about the defaults used in various parts of the world.

<Add Links here>

Collecting appropriate data

At the third level, you need to know what to collect. For example in the screen shot above I am not collecting either a middle name or a title. These are critical in certain parts of the world. The order of the "Given Name" (what we often call the "first name") and the "Family Name" (what we often call the "Last Name") differs in different parts of the world as well. Obviously trying to collect the Social Security Number of a Mexican citizen doesn't make any sense and using a "State" or "Zip code" in Canada doesn't make any sense either. There is an excellent set of standards that can help here at the following web site

<add links here>

JGuiGen's Solution

All keys and values are stored in a table an access with the Internationalization menu option under the Data Dictionary Menu option in JGuiGen. You can edit the English and/or up to 10 different languages. JGuiGen automatically writes out the properites bundles.

Here is an example JGuiGen I18n Screen. Note the translations (Bablefish on the web) for Spansih, German, French and Italian. The appropriate property files will be automatically written for each language that has any translations.