Locale-sensitive Operations and Services in International Java Applications | WebReference

Locale-sensitive Operations and Services in International Java Applications

By Rob Gravelle


[next]

An international application is one that tailors information to the user's specific geographical, political, or cultural preference. In the Java SE Platform, internationalization support is integrated into the java.util.Locale class as well as several other objects that provide language- or culture-dependent functionality. Java permits the assignment of a different locale to every locale-sensitive object in your program. This flexibility allows you to develop multilingual applications.

This article is a continuation of "Using the Java Locale Object to Internationalize Your Application". In that article, I explained how to use the Locale class and its important features. In this article, I focus on the classes that work with locales and also demonstrate how to create your own.

Setting the Default Locale for Your Application

In some instances, applications utilize only a single locale throughout their lives. Other times, applications refer to a global locale that can be changed. In those environments you can programmatically change the global locale preference, which remains in effect until you explicitly change it. As you will see shortly, the Java environment is unique in that it enables you to use a variety of locales throughout your application in any way you see fit.

When the locale is set at a global level, all locale-sensitive objects rely on the default locale. Set by the Java Virtual Machine (JVM) when it starts up, the default locale corresponds to the locale of the host platform. To determine the default locale of your JVM, invoke the Locale.getDefault() method:

There are two ways to set the default locale globally for your application. The first is to set it on the command line:

The second way to change the default locale is to call Locale.setDefault(). The following line sets the default locale to one of the pre-constructed locales that you saw previously:

Locale Considerations on the Server

Doing business around the globe can have significant ramifications for data storage and management. Moreover, both the end users and application developers may speak different languages and have very different expectations for how the software should behave. For instance, it is not uncommon to have a Swedish reports developer working with records in French for an English analyst. In those situations, you will need a clear plan for how you will manage data formats and then tailor your locale-sensitive objects accordingly.

This type of distributed application also presents similar issues with respect to the server. The locale for each client can be different, so what should be the locale of the data server? While there are no hard-and-fast rules governing server locales, there are some guidelines that can steer you clear of potential gotchas. The design of the server should be simplified as much as possible by delegating the responsibility for displaying the locale-sensitive data to the client tier. If possible, the data passed between the server and the clients should be locale-independent. However, this approach won't work if the server must store the data in a locale-specific form. For example, the server might store Spanish, English, and French versions of the same data in different database columns. In this case, the server may have to query the client for its locale using the Locale.getDefault() method described above, because the locale may have changed since the last request.

Speaking from experience with multilingual systems, I have seen two approaches work equally well. One is to store data in the format of the server's locale (which would be "English Canada" (EN_CA) in my case). The other is to convert all locale-dependent inputs to a locale-agnostic format before storing them. The "yyyy-mm-dd" date format is an example of a locale-agnostic/universal format.

Locale-sensitive Operations and Services

The primary function of the Locale object is merely to store and manage global locale-related information. To perform an operation that requires a locale, you need to pass it to an object's getXXXInstance(locale) method. Classes that implement this method include:

  • Collator
  • DateFormat
  • DateFormatSymbol
  • NumberFormat
  • DecimalFormatSymbols

To illustrate, let's take a look at the Collator class. Collation rules define the sort sequence of strings. These rules vary with locale, because various natural languages sort words differently. You can use the predefined collation rules provided by the Collator class to sort strings in a locale-independent manner.

To instantiate the Collator class, call its getInstance() method. Usually, you create a Collator for the default locale, as in the following example:

You can also specify a particular locale when you create a Collator, as follows:


[next]