INTERNATIONALIZATION 165
LESSON 12
Internationalization
More and more companies, large and small, are doing business around the world using many
different languages. Effective communication is always good business, so it follows that
adapting an application to a local language adds to profitability through better communica-
tion and increased satisfaction.
The Java 2 platform provides internationalization features that let you separate culturally
dependent data from the application (internationalization) and adapt it to as many cultures as
needed (localization).
This lesson takes the two client programs from the
Developing the Example (page 141) les-
son, internationalizes them and localizes the text for France, Germany, and the United States.
Covered in This Lesson
• Identify Culturally Dependent Data
• Create Keyword and Value Pair File
• Internationalize Application Text
• Internationalize Numbers
• Compile and Run the Application
• Exercises
• More Information
• Code for This Lesson
166 INTERNATIONALIZATION
Identify Culturally Dependent Data
To internationalize an application, the first thing you need to do is identify the culturally
dependent data in your application. Culturally-dependent data is any data that varies from
one culture or country to another. Text is the most obvious and pervasive example of cultur-
ally dependent data, but other things like number formats, sounds, times, and dates should be
considered too.
The
RMIClient1 and RMIClient2 classes have culturally-dependent data visible to the user.
This data is included in the bullet list below. Figure 35 shows the Fruit Order client, which
displays some of the culturally-dependent data mentioned in the bullet list.
Figure 35 Culturally-Dependent Data
• Titles and labels (window titles, column heads, and left column labels)
• Buttons (Purchase, Reset, View)
• Numbers (values for item and cost totals)
• Error messages
INTERNATIONALIZATION 167
Although the application has a server program, the server program is not being international-
ized and localized. The only visible culturally-dependent data in the server program is the
error message text. The server program runs in one place and the assumption is that it is not
seen by anyone other than the system administrator who understands the language in which
the error messages is hard coded. In this example, that language is United States English.
All error messages in
RMIClient1 and RMIClient2 programs are handled in try and catch
blocks. This way you have access to the error text for translation into another language.
//Access to error text
public void someMethod(){
try {
//do something
} catch (java.util.NoSuchElementException {
System.out.println(“Print some error text”);
}
}
Methods can be coded to declare the exception in their throws clause, but this way you can-
not access the error message text thrown when the method tries to access unavailable data in
the set. In this case, the system-provided text for this error message is sent to the command
line regardless of the locale in use for the application. The point here is it is always better to
use
try and catch blocks wherever possible if there is any chance the application will be
internationalized so you can access and localize the error message text.
//No access to error text
public void someMethod() throws java.util.NoSuchElementException{
//do something
}
Here is a list of the title, label, button, number, and error text visible to the user, and there-
fore, subject to internationalization and localization. This data was taken from both the
RMIClient1 and RMIClient2 classes.
• Labels: Apples, Peaches, Pears, Total Items, Total Cost, Credit Card, Customer ID
• Titles: Fruit $1.25 Each, Select Items, Specify Quantity
• Buttons: Reset, View, Purchase
• Number Values: Value for total items, Value for total cost
• Errors: Invalid Value, Cannot send data to server, Cannot look up remote server object,
No data available, No customer IDs available, Cannot access data in server
168 INTERNATIONALIZATION
Create Keyword and Value Pair Files
Because all text visible to the user will be moved out of the application and translated, your
application needs a way to access the translated text during execution. This is done with
properties files that specify a list of keyword and value pairs for each language to be used.
The application code loads the properties file for a given language and references the key-
words instead of using hard-coded text.
So for example, you could map the keyword purchase to Kaufen in the German file, Achetez
in the French file, and Purchase in the United States English file. In your application, you
load the properties file for the language you want to use and reference the keyword purchase
in your code. During execution when the purchase keyword is encountered, Achetez,
Kaufen, or Purchase is loaded depending on the language file in use.
Keyword and value pairs are stored in properties files because they contain information
about a program’s properties or characteristics. Property files are plain-text format, and you
need one file for each language you intend to use.
In this example, there are three properties files, one each for the English, French, and Ger-
man translations. Because this application currently uses hard-coded English text, the easiest
way to begin the internationalization process is to use the hard-coded text to set up the key
and value pairs for the English properties file.
The properties files follow a naming convention so the application can locate and load the
correct file at run time. The naming convention uses language and country codes which you
should make part of the file name. Both the language and country are included because the
same language can vary between countries. For example, United States English and Austra-
lian English are a little different, and Swiss German and Austrian German both differ from
each other and from the German spoken in Germany.
These are the names of the properties files for the German (
de_DE), French (fr_FR), and
American English (
en_US) translations where de, fr, and en indicate the German (Deut-
sche), French, and English languages; and
DE, FR, and US indicate Germany (Deutschland),
France, and the United States:
• MessagesBundle_de_DE.properties
• MessagesBundle_en_US.properties
• MessagesBundle_fr_FR.properties
INTERNATIONALIZATION 169
This is the English language properties file. Keywords are to the left of the equals (=) sign,
and text values are on the right.
apples = Apples:
peaches = Peaches:
pears = Pears:
items = Total Items:
cost=Total Cost:
card=Credit Card:
customer=Customer ID:
title=Fruit 1.25 Each
1col=Select Items
2col=Specify Quantity
reset=Reset
view=View
purchase = Purchase
invalid = Invalid Value
send = Cannot send data to server
nolookup = Cannot look up remote server object
nodata = No data available
noID = No customer IDs available
noserver = Cannot access data in server
You can hand this file off to your French and German translators and ask them to provide the
French and German equivalents for the text to the right of the equals (=) sign. Keep a copy
because you will need the keywords to internationalize your application text.
The properties file with German translations produces the fruit order client user interface
shown in Figure 36.
