New Supported Locales
June 23, 2005
If you pay close attention to the return values of the getAvailableLocales methods
in the java.text and java.util packages, you may
have noticed that the lists got a little longer in recent builds of JDK
6. The additions to the already long list of supported
locales in JRE 5.0 are:
| Language | Country | Locale ID |
|---|---|---|
| Chinese (Simplified) | Singapore | zh_SG |
| English | Malta | en_MT |
| English | Philippines | en_PH |
| English | Singapore | en_SG |
| Greek | Cyprus | el_CY |
| Indonesian | Indonesia | in_ID |
| Japanese (Japanese calendar) | Japan | ja_JP_JP |
| Malay | Malaysia | ms_MY |
| Maltese | Malta | mt_MT |
| Spanish | US | es_US |
You may wonder how we picked these locales. OK:
- One group is based on IT market sizes in the IDC Worldwide Black Book, from which we selected all countries above a certain market size. We also looked at the languages spoken within these countries, and tried to guesstimate IT market size for those. For example, 11% of the US population now speak Spanish at home, and at least in the consumer space companies can no longer afford to ignore this.
- Then we added locales to cover all countries in the European Union with their main languages. Malta is a small country, but it’s a member of the EU, Maltese is an official EU language, and some business in the EU simply requires support for all EU languages. As it turns out, the EU added Gaelic to its official languages just as we finished the addition of these locales, so we’re already behind again.
- The new Japanese locale finally is the way applications can access the
new Japanese calendar, which is not exposed as a separate class in the API.
To obtain an instance of the Japanese calendar, you’d use
Calendar.getInstance(new Locale("ja", "JP", "JP")).
The additions mark the first time that we use data from the Common Locale Data Repository for the JRE. The CLDR is maintained by the Unicode Consortium with contributions from IBM, Apple, Sun, and many others. We intend to continue to use CLDR for new locale data in the JRE. It’s an open question whether we should also update existing data from this source – it might fix some problems in our data and improve the alignment between the JRE and other software products, but it may also be seen as an unnecessary incompatibility. It’s pretty common for locale data to have two or more different versions that are all acceptable to users, while random changes between these versions are not acceptable. If you have an opinion on this issue, please let us know.