Choosing a Locale
Number formats are dependent on the locale, that is, the country/language/culture group of the local operating system. Most English-speaking Americans are accustomed to use a period as a decimal point, a comma to separate every three orders of magnitude, a dollar sign for currency, and numbers in base 10 that read from left to right. In this locale, Bill Gatess personal fortune, in Microsoft stock alone as of September 12, 2006, is represented as $27,075,657,331. However, in Egypt this number could be written as $ 
.
The primary difference here is that Egyptians use a different set of glyphs for the digits 0 through 9. For example, in Egypt zero is a and the glyph 
means two. There are other differences in how Arabic and English treat numbers, and these vary from country to country. In most of the rest of North Africa, this number would be $27,075,657,331 as it is in the U.S. These are just two different scripts; there are several dozen more to go!
Java encapsulates many of the common differences between language/script/culture/country combinations in a loosely defined group called a locale. Theres really no better word for it. You can just rely on language or country or culture alone. Many languages are shared between countries (English is only the most obvious example) but with subtle differences in how they are used in different places: Do commas and periods belong inside or outside of quotation marks? Is green a color or a colour? Many countries have no clearly dominant tongue: Is Canada an English- or a French-speaking nation? Switzerland has four official languages. Almost all countries have significant minority populations with their own languages. The New York City public school system has to hire teachers fluent in over 100 different languages.
Locales are identified by a language and an optional country and variant which are supplied to the constructors in java.util.Locale:
public Locale(String languageCode, String countryCode) public Locale(String languageCode, String countryCode, String variantCode)
The language is specified by a case insensitive two-letter ISO-639 language code such as EN for English or FR for French. The country is specified by a case insensitive two-letter ISO-3166 country code such as US for the United States or TT for Trinidad and Tobago. You can also pass the empty string to request a locale for a language independent of location. Finally, the variant can be pretty much anything. For example, you can ask for the locale for generic, standard French as spoken in France, French in the U.S., or French in the U.S. in New Orleans:
Locale french = new Locale("fr", "");
Locale parisian = new Locale("fr", "FR");
Locale french-US = new Locale("fr", "US");
Locale creoleFrench = new Locale("fr", "US", "NO");
Theres no guarantee that the VM supports any of these, though the first two are likely available. The variant code for New Orleans in the last line is completely nonstandard, but legal. When encountering this locale, Java will almost certainly fall back to a generic French locale. In fact, it will probably fall back to that for the fr-US locale too. However, the fr-FR locale will probably be recognized and won be quite the same as the fr-CA locale for Canadian French. The exact set of locales varies from one Java version and VM vendor to the next. However, these days the total number of available locales is usually well over a hundred.
The Locale class does include about twenty named constants for the most economically significant locales:
Locale.ENGLISH Locale.FRENCH Locale.GERMAN Locale.ITALIAN Locale.JAPANESE Locale.KOREAN Locale.CHINESE Locale.SIMPLIFIED_CHINESE Locale.TRADITIONAL_CHINESE Locale.FRANCE Locale.GERMANY Locale.ITALY Locale.JAPAN Locale.KOREA Locale.CHINA Locale.PRC Locale.TAIWAN Locale.UK Locale.US Locale.CANADA Locale.CANADA_FRENCH
However, not every available locale has such a constant.
