How do you create a program for use in the United States and in Germany—and maybe Korea and Norway too? Well, if you’re using Java as your development language, you’ll be happy to know that internationalization and localization have been planned for. Armed with the right tools, creating such an app might be less daunting than you think.

The term internationalization (a.k.a. globalization) can be defined as building or modifying an application to prepare it for use in other countries or cultures. You also may have come across the term I18N, which refers to the number of letters (18) between the I and the N in the word internationalization. Similarly, localization (which you may see referred to as L10N) refers to the process of making an application suitable for a particular geographic location, country, or culture.

It helps to think of the terms in this manner: If internationalization is the process of making an application generic, localization is the process of making it specific.

The character set

Java code is represented in Unicode, an international character set standard that uses 16-bit encoding and assigns a unique number for every character, including all major scripts and symbols. The platform uses codes defined by the International Standards Organization: code ISO-369 for the local language, with a lowercase two-letter code, and ISO-3166 for the country code, with an uppercase two-letter code.

How do you do it?
There are many factors to consider when building a culturally and geographically neutral application. For example, how do you effectively display numbers, currencies, dates, times, text, and sort orders of strings, along with the entire user interface? One of the most important aspects of creating a global application is to avoid hard-coding any locale-specific data or text.

The process of internationalizing/localizing an application includes these steps:

  1. Identifying and separating culture- and geographic-specific code, content, and design
  2. Developing a set of classes describing specific information (such as fields) for each locale (Extend the class ResourceBundle when feasible to simplify the translation process.)
  3. Developing your ResourceBundle files as you build the application
  4. Loading the bundles into an object array
  5. Generating a single translation file using the object array
  6. Translating the file into the proper language (see note below)
  7. Conducting QA on translation effort
  8. Saving the file in the resource directory for the locale

A note on translation

Often, text translation is the most time-intensive and costly part of localizing a project. It requires significant effort to simply translate all text and text strings. Not only must you find a reliable translator who is proficient in a language, he or she should have a technical background and be familiar with technical style guides for the locale that are equivalent to the quality your own. Furthermore, the translator must have a good background in locale-specific user interface requirements.

Even if you consider using content translation tools such as GlobalNET or ETranslate, you still must check for context correctness. (Think of it as using spell-checker: It might help you spell an entirely incorrect word properly, but the word you chose would still be incorrect, and your document could go out into the world saying something humiliating, offensive, or just plain ridiculous.)

According to Sun, “All locale-sensitive classes must be able to access resources customized for the locales they support. To aid in the process of localization, it helps to have these resources grouped together by locale and separated from the locale-neutral parts of the program.”

In Java, the process of localizing is made simpler with the use of the locale class. A locale is an identifier for a combined language and geographic area. Locales serve as requests for certain deliverables from another object. A UK locale passed to a Measurement object requests that the measurement is delivered in metrics; the US locale would return U.S. customary symbols.

The Java Development Kit 1.1 predefines a number of locale objects:

JDK has also defined language locales that specify language without location:

Resources for your I18N and L10N efforts

Here are some resources you may find valuable if you’re deploying an application globally:

For Information on Unicode

Presentation layer
Factors to consider on the GUI front include size of buttons and fields, colors, text, and context. Additionally, if your application front end is presented via a browser, you will need to ensure that country-specific browsers display information correctly and that fonts are properly dealt with.

Now you are ready
When planning to develop a Java application, at your disposal is a great set of resources and tools to build your application for the global market. Done correctly, you stand to save time and frustration and are more likely to see cost savings with each added localization effort over the lifetime of the application.