Aspects of Internationalization in Java

By: Grenfel Printer Friendly Format    

Internationalization involves many aspects of application development. Practically speaking, the primary goal behind all of these facets of development is to engineer a user interface -and its supporting infrastructure - that presents all UI information in a comprehensible way to local users. At a minimum, this effort involves supporting the following aspects of an application's execution:
  • Messaging— presentation of all visible text (message text, error text, UI component titles,
    prompts, and so forth) in the language of the appropriate runtime locale context.
  • Formatting policy— use of the correct locale-specific formats for all date, time, and
    numeric quantities.
  • Calendar and time zone policy— use of the correct calendar for the application's runtime
  • String collation policy— use of an appropriate policy for string collation based on the
    locale's language.
  • General UI features, locale-sensitive images, icons, and colors— using images and colors
    that represent meaningful mnemonics to local users.

To support the foregoing features, an internationalized application must perform some dynamic configuration and information retrieval. Typically, an application will determine its locale context dynamically upon startup. Then, it will configure all the necessary runtime components—such as calendar objects, string collators, format objects and messaging components—that it needs to conform to the locale context requirements.

Messaging: Messaging is the presentation of all text data to the user in a language appropriate for the application's runtime locale context. It's the most visible area of i18n. Messaging involves the execution of the following steps at runtime:

• determination of the device locale environment
• loading of the application's localized resources
• dynamic lookup and retrieval of localized resources for UI display
• display of localized resources

Messaging is the area that best highlights the close relationship between i18n and l10n. To make an i18n implementation usable, an application must be localized. For each locale supported, the l10n process must produce a set of translated message strings that the application can access at runtime.

String Collation: String collation, also known as lexicographic sorting, is different from messaging. Nevertheless, the two areas are related in the sense that collation functions manipulate message text—text that the user sees.

Different languages define different rules for collation. A string collation facility must use a mechanism that understands the collation rules for the strings' language context. Practically, this includes an understanding of the details of the underlying character encoding set. Applications do string collation with no knowledge of the source of the string text. That is, a collation function doesn't retrieve collated strings from some repository of localized text. Instead, the program collates strings that have already been retrieved from a localized repository. Collation functions don't need to know the original location of the string. They only need a language context and a properly encoded string.

Date, Time, Numeric, and Monetary Value Formatting: Different locales use different formats for writing dates, times, and numbers. For instance, in Europe, people write dates, times and numbers differently from people in the United States. A French user writes date, time, and numeric quantities using the following forms.

25 décembre 2002
20.000,45 (twenty thousand, and forty-five hundredths)

In the United States, however, these same quantities would normally be written as follows.

December 25, 2002
8:30 am
2:45 pm
20,000.45 (twenty thousand, and forty-five hundredths)

An internationalized program needs to format and display dates, times, and numbers appropriately for the runtime locale. Programs don't fetch these formatted quantities from some database; they calculate them dynamically in the same way that strings are collated dynamically.

Calendar and Time Zone Support: Calendars, although related to dates and times, define different characteristics and functionality. The difference is that calendars perform calculations that involve dates and times, whereas date and time objects support the formatting and display of those quantities.

Most Viewed Articles (in Java )

Latest Articles (in Java)

Comment on this tutorial