Internationalization

Digg This!

Page 2 of 5   « previous page   next page »

There was another twist to the requirements. There were different flavors of the booking engine, commonly referred to as booking engine sites. For example, there is a core booking site and a discounted booking site. Different sites will have different business rules. The business rules for a particular site can also vary across different POS countries. For example, the fare rules for a core booking site can be different on the US POS than are those on the UK POS. There were also special requirements in terms of the content displayed. It was expected that words with similar meanings for the same label in a particular language could be used across different sites. For example, Table 3 shows how the label for discounted fares was expected to be displayed on Core and Discount booking sites for the same US POS.

Another interesting requirement was to respect the colloquiality of the language based on the POS country. For example, if the user is in the Canadian POS and if the content is displayed in French, the colloquiality of French as spoken in Canada should be respected. However, if the user is in the French POS and if the content is displayed in French, then the colloquiality of the French as spoken in France should be preserved.

The final and the most critical requirement is that all the content that is localized will be managed through a content management application (CMA).

The aforementioned requirements clearly indicate that the content displayed on the Web application varies based on the POS country, user selected language, and the booking site. Based on this understanding, the following fallback rules to look up content from CMA were defined:

• Consider "core" as default site, "English" (en) as default language, and "US" as default country
• Find the content with exact match by using user selected site, language, and country
• If the previous step fails, find the content by using user-selected site and language, but ignoring the country
• If the previous step fails, find the content by using default site, user-selected language, and country
• If the previous step fails, find the content by using default site and user-selected language, but ignoring the country
• If the previous step fails, find the content by using user-selected site, default language, and default country
• If the previous step fails, find the content by using default site, default language, and default country
• If all of the above steps fail, then the content should be considered to be unavailable

The application that is presented in this article is a prototypical version of the actual application. The prototype helped us to focus on the subject and to provide clear explanations in this article.

The Foremost Thing to Do
The foremost thing to do in terms of internationalization is to identify the locale. The knowledge of a user's locale is the key to application internationalization. Java provides the Locale class in the java.util package to represent a user's locale. The Locale object uses ISO constants for countries and languages to determine a user's geographical, political, and cultural preferences. The Locale object also provides a placeholder for specifying a variant. Essentially, a variant helps in creating a custom locale by specifying additional information that can influence user preferences.

Typically, in the case of Web applications, a browser transmits a header "Accept-Language" in the HTTP request. This header contains more than one user-selected locale, and each locale is a combination of ISO language code and country code. Users normally have options on the browser to select a list of preferred language and country combinations. However, while selecting a locale to be used in the application, it is not reliable to depend totally on the value of this HTTP header because a user may or may not specify the right locale supported by the application. One way is to provide the user with the ability to select language and country preferences dynamically while interacting with the application.

In the application described in this article, it was not too difficult to determine what constitutes a user locale. As mentioned earlier, the content to be displayed is based on the user's choice of language, POS country, and booking site. Obviously POS country and user's choice of language can be easily represented in terms of ISO codes. The question was about the booking site. To address this, a meaningful but constant name was assigned to each booking site such as "core," "discount," etc., and this site name was considered as a variant in a Locale object.

Handling Localized Content
The important step in internationalization is the isolation of data elements that are candidates for localization. The following are some of the displayable data elements that can either be translated or formatted based on user's locale:

1.  Elements that can be translated:

• Application messages
• Labels and headers on the form fields
• Online help content
• Images and icons
• Personal titles and greetings

2.  Elements that can be formatted:

• Date and time
• Numbers
• Measurements (miles vs. km, etc.)
• Currencies
• Phone numbers
• Mailing address

Java provides the ResourceBundle class in the java.util package to handle translatable data elements. A resource bundle in its simplest form is a collection of key-value pairs (a key is an index to a value that can be localized or translated). Property files are typically used to specify resource bundles. Custom resource bundles can also be created as Java classes by extending from the ResourceBundle class. In either case, the naming of the properties file or the custom class matters most. Resource bundle names have two parts: a base name and a suffix. The base name is an identifier for the resource bundle. The suffix is an identifier for the locale. For example, a properties resource bundle "AppResources" for the default locale will have a name "AppResources.properties." However, if the property values are translated to Chinese and French locales, then the new files will have names "AppResources_zh_CN.properties" and "AppResources_fr_FR.properties," respectively. If the application uses a custom locale with some variant such as the one used in the example application "fr_US_core," then the locale suffix should also contain the variant name, for example, "AppResources_fr_US_core.properties." One note of caution: when properties' resource bundles are being created, the right character set encoding should be used.

Resource bundles are loaded within the application by calling the "getBundle" static method on the java.util.ResourceBundle class and passing the base name of the bundle and the current locale. The loading of a resource bundle uses a locale fallback approach as shown in the flow diagram in Figure 5.

Creating property files with translated content is an approach typically used when the application is of medium size and the number of locales supported is small. However, in cases of large applications that need internationalization in many different locales, this approach may end up being a maintenance nightmare. For example, in the current application there are as many as 1200 possible custom locales (24 countries x 10 languages x 5 booking sites = 1200 custom locales), and there are thousands of data elements that need to be translated. Of course, most of the translated content in a particular language will be reused, but the idea of creating 1200 different property files with thousands of content entries is mind-boggling. However, the requirement to use CMA for localized content management and retrieval essentially eliminated any possibility of internationalization design based on locale-specific property files. It was inevitable to devise a strategy to pull the content without losing the internationalization features offered by Java and the Web frameworks such as Struts and JSTL.

Obviously, Locale and ResourceBundle are at the core of the internationalization features offered by Struts and JSTL. It was clear that a custom ResourceBundle instance should be created that can interact with the underlying CMA database to pull locale-specific content. The next question was whether there was a need to create a separate custom Resource bundle for each possible locale, particularly because of the way Resource bundles are looked up. If we took this approach, it meant that we had to create as many as 1200 unique Resource bundle implementations, one for each possible locale. This solution would not be any better than having hundreds of property files, so the conclusion was to create only one custom implementation and somehow incorporate it in the application.

Page 2 of 5   « previous page   next page »