Language và geographic environment are two important influences on our culture. They create the system in which we interpret other people and events in our life. They also affect, even define, proper khung for presenting ourselves và our thoughts lớn others. To communicate effectively with another person, we must consider và use that person"s culture, language, & environment.

Bạn đang xem: Internationalization là gì

Similarly, a software system should respect its users" language and geographic region to lớn be effective. Language and region form a locale, which represents the target setting và context for localized software. The Java platsize uses java.util.Locale objects to lớn represent locales. This article describes the Locale object và its implications for programs written for the Java platform.

This article is divided inkhổng lồ the following sections:


Locales identify a specific language & geographic region. Locale-sensitive objects use java.util.Locale objects to customize how they present và format data lớn the user. Locales affect user interface language, case mapping, collation (sorting), date & time formats, & number and currency formats. Locales are critical lớn many culturally & linguistically sensitive data operations.

A java.util.Locale is a lightweight object that contains only a few important members:

A language code An optional country or region code An optional variant code

When writing or talking about locales, you can use a text abbreviation for a convenient representation. This notation separates each component of a locale with an underscore character:


These three elements provide enough information lớn other locale-sensitive sầu objects so that they can modify their behavior for a specific linguistic or cultural purpose. For example, a java.text.NumberFormat object created for a German-speaking Swiss locale will format numbers differently than it would for a German-speaking Austrian locale. See Table 1.

Table 1. Formatted đầu ra Varies by Locale

LocaleFormatted Numbers
German (Germany) 123.456,789
German (Switzerland) 123"456.789
English (United States) 123,456.789

Because Locale objects are just identifiers, locale-sensitive sầu classes lượt thích java.text.NumberFormat or java.text.DateFormat do all the work lớn provide localized number or date formats. The java.text.DateFormat class, for example, uses a Locale object during its instantiation to decide how to lớn format dates correctly.

The following sections describe each component of a locale.

Language Codes

Language codes are defined by ISO 639, an international standard that assigns two- and three-letter codes to most languages of the world. Locale uses the two-letter codes to identify the target language. Table 2 lists several of these language codes.

Table 2. Language Code Examples in the ISO 639 Standard

Arabic ar
German de
English en
Spanish es
Japanese ja
Hebrew he

Language is an important component of a locale because it describes the language that a particular group of customers uses. Your applications will use this information khổng lồ provide a user interface that conforms khổng lồ your customer"s language.

Of course, language doesn"t paint the entire picture of a locale. For example, even though you may use de as the locale language code, de alone doesn"t tell you anything about where German is spoken. Several countries use German as an official first or even second language. One of the differences in German from one country to lớn another is sorting order. For this reason & others, language is not always sufficient khổng lồ precisely define a locale.

Country (Region) Codes

Country codes are defined by ISO 3166, another international standard. It defines two- và three-letter abbreviations for each country or major region in the world. In contrast to lớn the language codes, country codes are set uppercase. Table 3 shows a few of the defined codes. Locale uses the two-letter codes instead of the three-letter codes that this standard also defines.

Table 3. Some Country Codes Defined in the ISO 3166 Standard

United States US
Canada CA
France FR
Japan JP
Germany DE

Country codes are an important locale component because java.text.Format objects for dates, time, numbers, and currency are particularly sensitive sầu to this element. Country codes add precision to lớn the language component of a locale. For example, French is used in both France & Canadomain authority. However, precise usage và idiomatic expressions vary in the two countries. These differences can be captured with different locale designators in which only the country code is different. For example, the code fr_CA (French-speaking Canada) is different from fr_FR (French-speaking France).

Variant Code

Operating system (OS), browser, và other software vendors can use the code to provide additional functionality or customization that isn"t possible with just a language & country designation. For example, a software company may need lớn indicate a locale for a specific operating system, so its developers may create an es_ES_MAC or an es_ES_WIN locale for the Macintosh or Windows platforms for customers in Spain.

One historical example from the Java platform itself is the use of the EURO variant for European locales that use the euro currency. During the transition period for those countries, the Java 2 Platkhung, Standard Edition (J2SE) version 1.3 used this variant. For example, although a de_DE (German-speaking Germany) locale existed, a de_DE_EURO (German-speaking German locale with a euro variant) was added to lớn the Java environment. Because the lỗi currency is now the standard for the affected countries, those variants were removed in J2SE 1.4. Most application designs will probably not require variant codes.


The Locale class has several constructors:

Locale(String language) Locale(String language, String country) Locale(String language, String country, String variant)

The following shows how each constructor can be used:

// Create a generic English-speaking locale. Locale locale1 = new Locale("en"); // Create an English-speaking, Canadian locale. Locale locale2 = new Locale("en", "CA"); // Create a very specific English-speaking, U.S. locale // for Silinhỏ Valley. Locale locale3 = new Locale("en", "US", "SiliconValley");
Using the ISO 639 two-letter code, the en represents English. The ISO 3166 codes CA và US represent Canadomain authority và the United States, respectively: The last code line above shows how to lớn create a locale with an optional variant: an en_US_SiliconValley locale. This locale is more specific than the first instance. Not only is the locale a U.S. English-speaking one, but it is also associated with an additional variant, SiliconValley. Because one of its purposes is to lớn provide developers the ability to define custom locales, the variant can be anything you need.

Although the compiler và runtime environment won"t complain if you make up your own language and country or region identifiers, you should use only the codes that the ISO standards define. By constraining yourself khổng lồ the ISO definitions, you"ll ensure compatibility with other applications và coding standards. More importantly, locale-sensitive sầu class libraries use only the ISO codes. For example, the java.text.NumberFormat class will underst& how to behave for the de_DE (German language, Germany) locale, but it won"t underst& what lớn do with a fictitous foo_biz locale. If you use non-ISO identifiers, you will have sầu to write the locale-sensitive sầu code khổng lồ support them.

Preconstructed Locales

The Locale class has many static fields that represent instantiated Locale objects. For example, Locale.FRANCE is a premade static Locale object that represents French-speaking France. You can use Locale.FRANCE anywhere you might use new Locale("fr", "FR"). Table 4 shows some of the preconstructed Locale objects that are available.

Table 4. Some of the Preconstructed Locale Objects

Locale NameLocale
Locale.CHINA zh_CN
Locale.CHINESE zh
Locale.PRC zh_CN
Locale.TAIWAN zh_TW
Locale.ENGLISH en
Locale.UK en_GB
Locale.US en_US
Locale.FRANCE fr_FR
Locale.FRENCH fr

Preconstructed locales exist for convenience. However, the menu of static class constants is small và incomplete. Not every important locale is represented. Locale-sensitive sầu class support is not determined by whether the locale exists as a Locale class constant. For example, no South American Locale class constants exist, yet they have complete tư vấn by several locale-sensitive classes including DateFormatand NumberFormat.

Because so few premade locales exist, you should probably just avoid these static objects altogether. I have sầu described them here because they exist và because you may see them in someone else"s code. Although these shortcut identifiers are convenient, your code will be more consistent without them.

Identifying Supported Locales

What locales does the Java platsize support? You can create any locale that you"d like. However, your runtime environment may not fully tư vấn the Locale object you create.

If you want to know what Locale objects you can create, the answer is simple: You can create any locale you"d lượt thích. The constructors won"t complain about non-ISO arguments. However, a more helpful restatement of the question is this: For which locales vày the class libraries provide more extensive sầu information? For which locales can the libraries provide collation, time, date, number, và currency information? Also, you might ask what scripts or writing systems your runtime environment supports.

The following sections describe how lớn determine supported locales in the runtime libraries. Additionally, they describe the supported scripts that can be displayed by the text components. Finally, they enumerate the localizations that are available for the runtime libraries và the software development kit (SDK) itself.

Enabled Locales in java.util and java.text Packages

The runtime environment has no requirement that all locales be supported equally by every locale-sensitive sầu class. Every locale-sensitive sầu class implements its own support for a set of locales, & that set can be different from class lớn class. For example, a number-format class can tư vấn a different set of locales than can a date-format class.

Additionally, there is no requirement that all runtime implementations tư vấn the same phối of locales. But all implementations must support a minimal list of them. This list is quite short: English (U.S.). Fortunately, the runtime environment that Sun provides is much more extensive. Although it is not formally required, Sun"s runtime implementation supports the same set of locales in each of its locale-sensitive sầu data format classes. This provides a consistent set of tư vấn across classes. The J2SE 5.0 platform"s Supported Locales guide provides a full danh sách of all supported locales. Table 5 shows a few of the supported locales.

LanguageCountryLocale ID
Arabic Saudia Arabia ar_SA
Chinese (simplified) China zh_CN
Chinese (traditional) Taiwan zh_TW
Dutch Netherlands nl_NL
English Australia en_AU
English Canada en_CA
English United Kingdom en_GB
English United States en_US
French Canada fr_CA
French France fr_FR
German Germany de_DE
Hebrew Israel he_IL
Hindi India hi_IN
Italian Italy it_IT
Japanese Japan ja_JP
Korean South Korea ko_KR
Portuguese Brazil pt_BR
Spanish Spain es_ES
Swedish Sweden sv_SE
Thai (Western digits) Thailand th_TH
Tnhì (Tnhị digits) Thailand th_TH_TH

To find out what locales your Java Runtime Environment (JRE) supports, you have lớn ask each locale-sensitive class. Each class that supports multiple locales will implement the method getAvailableLocales(). For example,

Locale<> localeList = NumberFormat.getAvailableLocales();

The getAvailableLocales() method is implemented in many of the classes in the java.text và java.util packages. For example, NumberFormat, DateFormat, Calendar, and BreakIterator provide it.

The Locale class itself is localized for several locales. In the example below, a German locale instance provides information about itself in English (the default on the author"s host), German, and French:

Enabled Script Support

Text components don"t usually support single locales. Instead, text widgets support a phối of scripts that often cross locale boundaries. Although it is impossible lớn get a listing of supported scripts from the various text components themselves, the danh mục is published as part of the J2SE 5.0 platform"s Supported Locales guide.

In general, peered AWT components can render scripts that the underlying host supports. If your host system is localized to Arabic, the AWT text components will display Arabic. On an Arabic system, you would also be able to enter Arabic text into components like TextField or TextArea. However, you cannot expect those same AWT components to display text that isn"t in the same script as the localized host. An English host would not typically be able to display Arabic in a TextField, for example. Java Foundation Classes/Swing (JFC/Swing) components, however, can often tư vấn multiple scripts because of their independence from the host platkhung and their use of Unicode as a multiscript character mix. Therefore, Swing components can often display a script even when peered AWT components cannot. Table 6 shows some of the supported scripts.

Writing SystemLanguage
Arabic Arabic
Chinese (simplified) Chinese
Chinese (traditional) Chinese
Devanagari Hindi
Hebrew Hebrew
Japanese Japanese
Korean Korean
Latin: Western European subset English, French, German, Italian, Spanish, Swedish, & so on
Thai Thai
Greek Greek
Cyrillic Belorussian, Russian, and so on
Latin: Baltic subset Latvian, Lithuanian
Latin: Central European subset Czech, Hungarian, Polish, & so on
Latin: Turkic subset Turkish and so on

JRE và SDK Localizations

User interface elements in the runtime environment have been localized for several locales. These elements include AWT và Swing components và other messages generated by the JRE & included tools. Table 7 shows all the localizations provided for J2SE 5.0.

Xem thêm:

LanguageLocale ID
Chinese (simplified) zh_CN
Chinese (traditional) zh_TW
English en
French fr
German de
Italian it
Japanese ja
Korean ko
Spanish es
Swedish sv

Some tools, such as the Javac compiler, come only with the J2SE Software Development Kit (SDK). These tools provide error, warning, & informational messages to the user. Those messages within the SDK utilities và tools, including the compiler, are translated inlớn English và Japanese. These translations are available in the J2SE 5.0 SDK.

Representing Locale as a String

Although most of your use of locale will require a Locale object reference, it is sometimes convenient to use an alternative representation, especially for internal debugging purposes. A Locale object"s toString() method returns a String that is the concatenation of the language, region, và variant codes. The toString() method separates each component with the underscore character, _. You may want to lớn use this method during debugging because it provides a convenient & readable representation.

Consider the locale created with this code:

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

The toString() method will return ja_JPhường for this locale.

This string is not appropriate for presentation lớn most kết thúc users. Most customers are not familiar with the ISO 639 & 3166 standards for language and country codes và will think the string is too cryptic. Fortunately, more user-friendly text representations are available, & we will discuss those later in this article.

Using Locale

Although not always obvious, Locale objects are used throughout the Java class libraries. Even when you don"t explicitly ask for a locale preference, the Java environment uses mặc định locale settings to lớn provide you with localized information & behavior. When you use an explicit locale, you can use a different locale for each part of your application.

For example, you can use the es_MX, Spanish (Mexico), locale for displaying localized messages in Spanish & use the en_US, English (United States), locale for number và currency formatting. This type of support would be useful for Spanish speakers who live & work in the United States. Although the application user could view Spanish menus, prompts, và text, the rest of the application could format numbers & currency correctly for the United States. This is a simple example of how you can use multiple locales in a single application. If your applications ever require this cấp độ of locale tư vấn, you have the freedom to determine the behavior of every aspect of an application.

Some of the locale-sensitive classes format numbers, currencies, dates, và time. Others provide collation as well as word-breaking services. Classes will typically provide a constructor or factory method for creating instances. In each case, you usually have sầu the option of providing an explicit locale preference.

Using a Default Locale

The mặc định locale is used by locale-sensitive sầu objects whenever your application doesn"t specify an explicit locale choice. Depending on the default locale is not wise. In multiuser applications, a single default locale is usually not appropriate for everyone using the system. Instead your application should explicitly provide a preference lớn all locale-sensitive sầu objects. The default locale is a systemwide resource, available throughout your application lớn any locale-sensitive sầu object. As the default, it may be correct for your application"s user, although you should be explicit in multilingual or multicultural environments. This is especially important when your application runs on a single host that supports many users.

Retrieve the mặc định locale using the following method:

public static Locale getDefault()

The mặc định locale of your application is determined in three ways. First, unless you have sầu explicitly changed the default, the getDefault() method returns the locale that was initially determined by the Java Virtual Machine (JVM) when it first loaded. That is, the JVM determines the mặc định locale from the host environment. The host environment"s locale is determined by the host operating system and the user preferences established on that system.

Second, on some Java runtime implementations, the application user can override the host"s mặc định locale by providing this information on the commvà line by setting the user.language,, và user.variant system properties.

The following code will print out a different locale depending on the value of these properties when it is invoked:

You can experiment with the above code example. Running on a U.S. English system, the above sầu code prints en_US. If you provide command-line options as described above sầu, you can coax your application inlớn using any locale you need. For example, you can invoke the application like this:

java -Duser.language=fr Default

This invocation prints fr_CA as the mặc định locale.

Third, your application can Gọi the setDefault(Locale aLocale) method. The setDefault(Locale aLocale) method lets your application phối a systemwide resource. After you mix the default locale with this method, subsequent calls to Locale.getDefault() will return the newly set locale.

Note: Take care not to hotline setDefault() in applets. The Security Manager will not allow you khổng lồ gọi this method because it affects a systemwide resource within the JVM that runs on the host.

In most cases, using the mặc định locale with other classes means ignoring it altogether. For example, if you want to format a number for your default locale, you simply create a NumberFormat without any arguments:

NumberFormat nf = NumberFormat.getInstance();

That"s it. Using the default locale requires almost nothing on your part. Other locale-sensitive sầu classes follow this same pattern. If you want the mặc định locale behavior, bởi nothing special when creating the object. However, the mặc định isn"t always appropriate, và you"ll need to lớn be more explicit at those times.

Using an Explicit Locale

In some computing environments, applications use only a single locale throughout their life cycle. In other environments, applications use a global locale that can be changed. Those environments allow you lớn programmatically change the global locale preference, which remains in effect until you explicitly change it again. The Java application environment is chất lượng, providing you with the ability to use a variety of locales throughout your application in any way you require.

Multinational companies have sầu customers all around the globe. This means that both their customers & employees may speak different languages & have sầu different expectations for how the company và its software should behave. Moreover, it is entirely possible, even common, khổng lồ have sầu a French employee handle a sales record for an Italian customer. In those situations, you will need absolute control over which locale your business & user interface objects use lớn manipulate và represent data. Your application may need to print sales receipts using Italian date và currency formats, yet sort customer lists for an English sales employee. The combinations are far too numerous to menu, but Java công nghệ provides you the flexibility to lớn handle that complexity.

In order to lớn get the most flexibility, you must explicitly request tư vấn for a target locale for each locale-sensitive class that you use. That means you must traông xã the locale preferences for multiple aspects of the application or assign locale preferences to lớn different users và customers.

If you have tracked the user"s locale preference, you would create instances of locale-sensitive sầu classes by explicitly providing a locale in a constructor or creation method. Imagine that a preferences object stores your customer"s locale choice:

Locale userLocale = preferences.getLocale(); NumberFormat nf = NumberFormat.getInstance(userLocale);
Retrieving Locale Information Although Locale objects don"t contain much information, they bởi provide a few interesting methods. As you might expect, the information is tightly related to the object"s language, country, và variant. Some of this information is locale-independent; some is locale-dependent. All this means is that the Locale object has two different forms for most of its methods. One mix of information is not customer-oriented or localized. The other set is localized và is suitable for presentation to lớn the user.

Locale-Independent Information

The getLanguage() method returns the ISO 639 two-letter abbreviation for the locale"s language. For example, if you have created the locale ja_JP.., this method returns the code ja. The method"s full signature is

public String getLanguage()

An extension of the ISO 639 standard defines three-letter language codes. Although these codes are not currently used in J2SE 5.0, the codes are available. Use the following method khổng lồ retrieve sầu the three-letter language code:

public String getISO3Language()

An example shows the difference:

If your Locale object has a variant field, the getVariant() method will identify và return it as a String. If the Locale object has not defined a variant, this method returns an empty String. This method"s declaration is the following:

public String getVariant()

The following class methods can be used to lớn retrieve arrays of all the valid language và country codes available:

public static String<> getISOCountries() public static String<> getISOLanguages()

A developer is much more likely to lớn appreciate & khổng lồ use the code returned by getLanguage() than is a customer. Your customer probably expects something different, as described in the next section.

Locale-Dependent Information

The codes supplied by the getLanguage(), getCountry(), & getVariant() methods are not especially user-friendly. Your customer should probably not have to lớn interpret these codes, so locale provides additional methods that provide more readable, customer-oriented information.

Locale objects provide methods that return human-understandable text representations. This text representation is different from what the toString() method provides. Unlike the simple concatenation of the language, country, and variant fields, these methods provide human-readable, localized information about the locale:

public final String getDisplayLanguage() public final String getDisplayCountry() public final String getDisplayVariant()

Display Language

When you need to display a locale"s language khổng lồ your user, you should use the Locale object"s getDisplayLanguage() method. This method returns the displayable, human-readable name of the locale"s language. The display name is localized for the default locale if you don"t provide a target locale argument. There are two forms of this method:

public final String getDisplayLanguage() public final String getDisplayLanguage(Locale targetLocale)

The following examples show how these methods can be used:

The output German is the U.S. English word for the locale"s language. That"s not especially impressive, but notice how you can provide a target locale argument. In that situation, getDisplayLanguage() tries to find & return a localized version of its language component.

This is important because you can show your customer the language of each locale that your application supports in the customer"s target language. You can provide this danh sách in your application lớn allow your customers lớn choose their preferred locale.

This brings up an interesting question: How vày you present a locale"s display language in the locale"s language? You would vì it with the following code:

String displayLang = aLocale.getDisplayLanguage(aLocale);

In other words, you simply provide the Locale object to lớn itself in the hotline khổng lồ getDisplayLanguage(). This same trick works with other displayable locale elements as well. For example, the display country & variant can be handled this way too. The following code snippet demonstrates this technique (see Figure 1):


Figure 1. Displaying the Display Language in the Locale"s Language

Display Country

Retrieve a locale"s country or region component for user display with the following code:

public final String getDisplayCountry() public final String getDisplayCountry(Locale targetLocale)

The first method form provides a localized country name for the mặc định locale. The second size provides the same information localized for the target locale.

Display Variant

Variants are less used than other elements of a Locale. However, at times you still need to access that information. The getDisplayVariant() method returns the display name for the private variant member of Locale:

public final String getDisplayVariant() public final String getDisplayVariant(Locale targetLocale)

One way the Java platsize uses this variant is to lớn support the Tnhì language. By convention, a NumberFormat object for the th and th_TH locales will use comtháng Arabic digit shapes, or Arabic numerals, to format Thai numbers. However, a NumberFormat for the th_TH_TH locale uses Tnhì digit shapes. The following code demonstrates (see Figure 2):


Figure 2. Displaying Numbers in Arabic và Traditional Tnhị Digits

Display Name

The display name is simply a combination of the localized language, country, & variants demonstrated earlier. The method forms are the following:

public final String getDisplayName() public final String getDisplayName(Locale targetLocale)

Unlike locale"s toString() method, which concatenates the individual components & separates them with an underscore character, the getDisplayName() method uses parentheses to lớn separate the elements.

Summary Locale is an identifier for a language, an optional country (or region), & an optional variant code. Locale objects provide several methods that provide information about the locale"s state. Although a locale doesn"t itself contain much functionality, locale-sensitive objects depover on locale for an indication on how to lớn behave. Locale-sensitive objects use the locale khổng lồ customize their behavior so that they meet the user"s expectations. In the Java platform, each locale-sensitive sầu object is responsible for its own locale-dependent behavior. By kiến thiết, locale-sensitive classes are independent of each other. That is, the set of supported locales in one class does not need lớn be the same as the set in another class.

In traditional operating systems and localization models, only one locale setting is active sầu at a time. In those systems, after you programmatically mix the locale, all locale-sensitive sầu functions use the specified locale, which remains active sầu throughout the application as a global locale. It changes when there is another global locale activation through a setlocale or similar Điện thoại tư vấn. The Java platkhung, however, treats locales a little differently. A Java application can actually have sầu multiple locales active at the same time. That is, it is possible to lớn use a U.S. date format & a German number format in the same application. The ability to lớn use multiple Locale objects with various Format objects provides developers the opportunity to create complex combinations necessary for creating multicultural và multilingual applications.

Bài viết liên quan

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *