Software internationalization, commonly referred to as I18N, is a design methodology for creating software that is neutral with respect to the language, culture and character data encodings they are expected to support. Internationalized software can have its processing results modified at runtime by the localization preferences set by users.
Once an internationalized application has been developed, localization provides the values necessary for a specific language, culture and character data encoding. This information is made available to the application via a named data structure known as the locale.
The locale contains the local information required for the proper processing of linguistic, cultural and character data. Locale information is grouped into categories such as date and time, holidays, or character classification.
The traditional I18N (POSIX) model
In this model, the locale is a container of specific language and country behavior that defines the correct cultural behavior for that language/country. Typically, it contains cultural information on collation, time and date formatting, numeric formatting, currency formatting, positive and negative responses, and character classification. There are many API's that are locale sensitive and produce output that reflects the settings of the locale in use. The scope of this locale is global.
This model, while reasonably useful in globalized program development, has a number of disadvantages. These include complications associated with a global locale state in multi-threaded applications, limitations on program customization, and character sets bound to each locale (if the character set does not contain enough characters to represent all the characters in all the locales).
The Java I18N model
Java uses Unicode as its native encoding, which means that each locale source is not bound to a specific character set. The Unicode character set is large enough to represent all the characters in all locales (for now!).
Furthermore, a locale in Java is not a container of locale-specific attributes; it is simply a mechanism for identifying objects.
Finally, the single global locale assignment is not used in Java. A locale may be passed explicitly as an argument on all locale-sensitive operations. For programmers who don't want to have to deal or manage locales explicitly, a system-wide default locale is provided. The default locale means that you can revert back to the single global locale concept where the behavior of the entire presentation is affected by that single locale.
Articles in this series
The article that follows is an introduction to numeric data. It is the first of a series that will address various categories of locale data. Future articles in this this series will include the following (and maybe a few more):
- Currency formatting - for positive and negative monetary values
- Calendar information - day and month names, and abbreviations, plus weekend information
- Date and time formatting
- Time zone information - including daylight savings time rules
- Responses - typed affirmative and negative responses
- Telephone information
- Locale naming - country and language code
These articles will not discuss how locales work or what API's to use to invoke a particular behavior Instead, they will provide an over of the cultural data that currently form part of the locale source for POSIX and Java, along with additional data that is not currently part of these locales. | 
