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

Internationalization - I18N


Top of the Generated Screen - in Spanish
user_top_es.png


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 userRb.properties 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
ID=ID
Last\ Name=Last Name
First\ Name=First Name
Start\ Date=Start Date.

The Spanish version might say
Screen_Title=Español Pantalla Del Usuario
ID=ID
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

UsersRb.properties - base properties file
UsersRb_en.properties - base English properties file
UsersRb_en_US.properties - English - USA version
UsersRb_en_GB.properties - English - Great Britain version
UsersRb_es.properties - base Spanish version
UsersRb_es_MX.properties - Spanish - Mexican version
UsersRb_es_ES.properties - 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 UsersRb_en_US.properties file. If that file doesn't exist or does not contain the key, your application looks in UsersRb_en.properties. Again if the file doesn't exist or the key doesn't exist, the system automatically looks in UsersRb.properties. 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 UsersRb_ex_MX.properties, then UsersRb_es.properties and finally in UsersRb.properties.

You can use this hierarchy to only supply translations in the language_locale.properties file that differ from the basic language.properties 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 UserRb_en_GB.properties 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 UsersRb_en.properties 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.

data_dictionary_i18n.png