Locales

Previous Designs

In the past, locales were designed as a collection of attributes describing the language and cultural conventions of a specific country or region. Programs were assigned a global locale, which implicitly determined the behavior of various APIs. This approach proved to be too inflexible for many programs because:

Multilingual applications require several locales to be active at the same time.
Programs handling input from various sources need multiple locales to handle multiple character encodings.
Multi-threaded programs find global state troublesome.

The traditional approach also translates poorly into an object-oriented design because it groups unrelated pieces of data into a locale rather than associating them with the classes that need them.

Java Locale

In Java, a locale is simply an identifier for a particular combination of language and region. It is not a collection of locale-specific attributes. Instead, each locale-sensitive class maintains its own locale-specific information. With this design, there is no difference in how user and system objects maintain their locale-specific resources. Both use the standard localization mechanism.

Java programs are not assigned a single global locale. All locale-sensitive operations may be explicitly given a locale as an argument. This greatly simplifies multilingual programs. While a global locale is not enforced, a system wide default locale is available for programs that do not wish to manage locales explicitly. A default locale also makes it possible to affect the behavior of the entire presentation with a single choice.

Java locales act as requests for certain behavior from another object. For example, a French Canadian locale passed to a Calendar object asks that the Calendar behave correctly for the customs of Quebec. It is up to the object accepting the locale to do the right thing. If the object has not been localized for a particular locale, it will try to find a "close" match with a locale for which it has been localized. Thus if a Calendar object was not localized for French Canada, but was localized for the French language in general, it would use the French localization instead.

Class Locale

Locale objects are generally created from a language name and a county name as follows:

// A locale for Great Britain

Locale greatBritain = new Locale("en","GB"); 



// A locale for the French language

Locale french = new Locale("fr", "");

In the second case above, an empty country string is given to the Locale constructor to signify a locale for the entire French language. Language names are two letter ISO-639 language codes and country names are two letter ISO-3166 country codes.¹ This naming scheme is not enforced by class Locale but is rather a convention used by all Java's International classes. See the section, Localized Resources, for more details.

In addition, the Locale class contains a number of handy constants for creating Locale objects for commonly used languages and countries. For example, the following specifies the Locale object for Great Britain and can be used in place of new Locale("en","GB"):

Locale.UK

A Locale may also be created with an optional variant name. This allows multiple locales to be created for a single language and country combination. As an example, this feature could be used to create an "FR_FR_HOST" locale which would match the host's behavior for France rather than Java's portable behavior for France.

Locale contains a static getter and setter method for accessing the system's default locale. At start-up time, the default locale is automatically set by the Java runtime to match the host's current locale. If this is not possible, the en_US locale is used. Note that because of security restrictions placed on applets, applets are prevented from setting the global default locale.

Locale supports a number of methods to provide user readable names for the locale and its country, language and variant fields. These names can also be localized:

Locale.setDefault( new Locale("en", "US") );

Locale japan = new Locale("ja", "JP");

String nameUS = japan.getDisplayLanguage();

String nameFR = japan.getDisplayLanguage(new Locale("fr","FR"));

In the above example, the first call to getDisplayLanguage() returns the language of the locale japan, localized for the default locale. Thus nameUS would be "Japanese." The second call to getDisplayLanguage() returns the language of the locale japan, localized for the given locale. Thus nameFR would be "japonais."

Supported Locales

Java's design means that there does not have to be a single set of supported locales, since each class maintains its own localizations. Nevertheless, there is a consistent set of localizations provided by the International classes. They are summarized in the following table.

Table 0-1 Locales Supported By JDK 1.1¹
Locale	Language	Country
da_DK	Danish	Denmark
DE_AT	German	Austria
DE_CH	German	Switzerland
DE_DE	German	Germany
el_GR	Greek	Greece
en_CA	English	Canada
en_GB	English	United Kingdom
en_IE	English	Ireland
en_US	English	United States
es_ES	Spanish	Spain
fi_FI	Finnish	Finland
fr_BE	French	Belgium
fr_CA	French	Canada
fr_CH	French	Switzerland
fr_FR	French	France
it_CH	Italian	Switzerland
it_IT	Italian	Italy
ja_JP	Japanese	Japan
ko_KR	Korean	Korea
nl_BE	Dutch	Belgium
nl_NL	Dutch	Netherlands
no_NO	Norwegian (Nynorsk)	Norway
no_NO_B	Norwegian (Bokmål)	Norway
pt_PT	Portuguese	Portugal
sv_SE	Swedish	Sweden
tr_TR	Turkish	Turkey
zh_CN	Chinese (Simplified)	China
zh_TW	Chinese (Traditional)	Taiwan

¹ New locales may be added during the alpha and beta periods.

Instantiating Locale-Sensitive Objects

The Internationalization APIs use a general pattern for instantiating locale-sensitive classes. These classes contain one or more static factory methods that create the appropriate object for a given locale. Often, the returned object will be from a subclass that is designed for the requested locale. A factory method that takes no locale will create the appropriate object for the system default locale.

Often there can be more than one object of a given type used in a locale. For example, most locales require a NumberFormat object for currency values as well for as regular numbers. The following code shows how these NumberFormat objects may be obtained:

Locale italian = new Locale("it", "IT");

NumberFormat decimalFormat = NumberFormat.getDefault(italian);

NumberFormat currencyFormat 

	= NumberFormat.getDefaultCurrency(italian);

Contents | Prev | Next

¹ ISO-639 actually specifies the language codes in lower case. However, the alpha version of the Locale class requires upper case. The beta version of JDK 1.1 will be changed to use lower case language codes and upper case language codes will be properly converted for you. ISO-3166 specifies the country codes in upper case. Thus, country codes will remain upper case in future versions of the JDK.

java-intl@java.sun.com