After some recent articles about Web page language translation, it's time to get back to the main focus of this series, which is the creation of international applications and Web sites. Internationalization is the process of designing software so that it can be adapted (localized) to various languages and regions easily, cost-effectively, and without having to re-engineer the software. Localization is performed by simply adding locale-specific components, such as translated text, data describing locale-specific behavior, fonts, and input methods.
In the Java SE platform, internationalization support
is fully integrated into the classes and packages that provide language- or culture-dependent functionality. This article describes how to internationalize a locale-specific
application using Java.
At the highest level, transforming a locale-specific app into a locale-agnostic (i.e., internationalized) one requires decoupling culturally dependent values from the code and replacing such instances with locale-aware methods. This is much easier than duplicating the same application for each locale!
The following examples of data may vary with region or language:
- Labels on GUI components
- Online help
- Phone numbers
- Honorifics and personal titles
- Postal addresses
- Page layouts
An internationalized program has the following characteristics:
- With the addition of localized data, the same executable can run worldwide.
- Textual elements, such as status messages and the GUI component labels, are not hardcoded in the program. Instead, they are stored outside the source code and retrieved dynamically.
- Support for new languages does not require recompilation.
- Culturally-dependent data, such as dates and currencies, appear in formats that conform to the end user's region and language.
- It can be localized quickly.
To expand on that last point, localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text. Localization involves not only changing the language interaction, but also other relevant changes such as display of numbers, dates, currency, and so on. Other types of data, such as sounds and images, may require localization if they are culturally sensitive. The better internationalized an application is, the easier it is to localize it for a particular language and character-encoding scheme.
What follows are the main steps in transforming a locale-specific application into an internationalized one.
Isolate Translatable Text in Resource Bundles
In Java, text that is meant to be read by the end user is stored in
objects. Examples include status messages, error messages, log file entries,
and GUI component labels. This text is hardcoded into programs that haven't
been internationalized. You need to locate all occurrences of hardcoded text
that is displayed to end users. The following example selects the
ResourceBundle for the locale that matches the French language, the country
of Canada, on the UNIX platform:
Minimize the Use of Compound Messages
Compound messages are those that are made up of multiple parts. For example,
in the validation message "The
Last Name field cannot contain special characters.",
the Last Name is tied to a specific field in the GUI. This message would
be difficult to translate, because the position of the validated field in the
sentence won't necessarily be the same in all languages. Compound messages are
typically generated using string concatenation, which essentially hard-codes
the position of the variable portion of the message in the string:
For the reasons described above, you should avoid constructing compound messages.
However, if you must use them, there are specific techniques that you can employ
that allow for internationalization. I'll look at some of these in a
Present Dates, Times, Numbers, and Currencies in a Locale-sensitive Format
Dates and times are an especially prevalent source of confusion among international Web app users because their formats can differ significantly. In addition to different regions having their own formats, local formats can vary widely as well. All too often, a developer who is not thinking about internationalization will code something like this:
Passing date objects to methods of the
DateFormat class will ensure that your
application displays dates and times correctly around the world:
DateFormat is locale-sensitive, so it takes care of the formatting details
for each locale. Here is some sample output generated by the above code:
- French (France): 10 avril 2010
- German (Dutch): 10.04.2010
- English (US): Apr 10, 2010