Locales
|
| When you look at an application that is adapted to an international market, the most obvious difference you notice is the language. This observation is actually a bit too limiting for true internationalization: Countries can share a common language, but you still may need to do some work to make computer users of both countries happy.[1]
In all cases, menus, button labels, and program messages will need to be translated to the local language; they may also need to be rendered in a different script. There are many more subtle differences; for example, numbers are formatted quite differently in English and in German. The number 123,456.78 should be displayed as 123.456,78 for a German user. That is, the role of the decimal point and the decimal comma separator are reversed! There are similar variations in the display of dates. In the United States, dates are somewhat irrationally displayed as month/day/year. Germany uses the more sensible order of day/month/year, whereas in China, the usage is year/month/day. Thus, the date 3/22/61 should be presented as 22.03.1961 to a German user. Of course, if the month names are written out explicitly, then the difference in languages becomes apparent. The English March 22, 1961 should be presented as 22. März 1961 in German, or 1961 in Chinese. There are several formatter classes that take these differences into account. In order to control the formatting, you use the Locale class. A locale describes
For example, in the United States, you use a locale with
In Germany, you use a locale with
Switzerland has four official languages (German, French, Italian, and Rhaeto-Romance). A German speaker in Switzerland would want to use a locale with
This locale would make formatting work similarly to how it would work for the German locale; however, currency values would be expressed in Swiss francs, not German marks. If you only specify the language, say,
then the locale cannot be used for country-specific issues such as currencies. Variants are, fortunately, rare and are needed only for exceptional or system-dependent situations. For example, the Norwegians are having a hard time agreeing on the spelling of their language (a derivative of Danish). They use two spelling rule sets: a traditional one called BokmŒl and a new one called Nynorsk. The traditional spelling would be expressed as a variant
To express the language and location in a concise and standardized manner, the Java programming language uses codes that were defined by the International Organization for Standardization. The local language is expressed as a lowercase two-letter code, following ISO-639, and the country code is expressed as an uppercase two-letter code, following ISO-3166. Tables 10-1 and 10-2 show some of the most common codes.
NOTE
These codes do seem a bit random, especially since some of them are derived from local languages (German = Deutsch = de, Chinese = zhongwen = zh), but at least they are standardized. To describe a locale, you concatenate the language, country code, and variant (if any) and pass this string to the constructor of the Locale class. Locale german = new Locale("de"); Locale germanGermany = new Locale("de", "DE"); Locale germanSwitzerland = new Locale("de", "CH"); Locale norwegianNorwayBokmŒl = new Locale("no", "NO", "B"); For your convenience, the JDK predefines a number of locale objects: Locale.CANADA Locale.CANADA_FRENCH Locale.CHINA Locale.FRANCE Locale.GERMANY Locale.ITALY Locale.JAPAN Locale.KOREA Locale.PRC Locale.TAIWAN Locale.UK Locale.US The JDK also predefines a number of language locales that specify just a language without a location: Locale.CHINESE Locale.ENGLISH Locale.FRENCH Locale.GERMAN Locale.ITALIAN Locale.JAPANESE Locale.KOREAN Locale.SIMPLIFIED_CHINESE Locale.TRADITIONAL_CHINESE Besides constructing a locale or using a predefined one, you have two other methods for obtaining a locale object. The static getdefault method of the Locale class initially gets the default locale as stored by the local operating system. You can change the default Java locale by calling setDefault; however, that change only affects your program, not the operating system. Similarly, in an applet, the getLocale method returns the locale of the user viewing the applet. Finally, all locale-dependent utility classes can return an array of the locales they support. For example, Locale[] supportedLocales = DateFormat.getAvailableLocales(); returns all locales that the DateFormat class can handle. TIP
Once you have a locale, what can you do with it? Not much, as it turns out. The only useful methods in the Locale class are the ones for identifying the language and country codes. The most important one is getdisplayName. It returns a string describing the locale. This string does not contain the cryptic two-letter codes, but it is in a form that can be presented to a user, such as German (Switzerland) Actually, there is a problem here. The display name is issued in the default locale. That may not be appropriate. If your user already selected German as the preferred language, you probably want to present the string in German. You can do just that by giving the German locale as a parameter: The code Locale loc = new Locale("de", "CH"); System.out.println(loc.getDisplayName(Locale.GERMAN)); prints Deutsch (Schweiz) This example shows why you need Locale objects. You feed it to locale-aware methods that produce text that is presented to users in different locations. You can see many examples in the following sections. java.util.Locale 1.1
java.awt.Applet 1.0
|
3 
22 
|
EAN: 2147483647
Pages: 156