JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data (original) (raw)
| Owner | Naoto Sato |
|---|---|
| Type | Feature |
| Scope | JDK |
| Status | Closed / Delivered |
| Release | 8 |
| Component | core-libs / java.util:i18n |
| Discussion | i18n dash dev at openjdk dot java dot net |
| Effort | M |
| Duration | L |
| Endorsed by | Brian Goetz |
| Created | 2011/07/15 20:00 |
| Updated | 2024/07/12 11:25 |
| Issue | 8046117 |
Summary
Create a tool to convert LDML (Locale Data Markup Language) files into a format usable directly by the runtime library, define a way to package the results into modules, and then use these to incorporate the de-facto standard locale data published by the Unicode Consortium's CLDR project into the JDK.
Description
- Develop a tool to generate locale data files for the runtime from the LDML format, assuming that interpreting LDML at runtime isn't feasible due to performance constraints. The output file format shall be opaque so as to allow for future extensions.
- Develop a mechanism to package and install locale data in the form of modules.
- Support some locale elements from underlying platforms. For example, if the user preference for the date format specifies the Japanese calendar then the Java runtime should use that information to select the Japanese calendar as the default calendar. (See 6337471: desktop/system locale preferences support)
- Provide a mechanism to manage the user's locale data preference through some kind of UI, in an application (through an SPI), or at the OS level (e.g., through the Java control panel in Windows).
Testing
Need to verify that the installed locale data is correctly returned via locale-sensitive APIs such as DateFormat/NumberFormat, etc.
Risks and Assumptions
Since the JDK's collation API does not yet support the Unicode Collation Algorithm, on which LDML is based, collation data contained in LDML files will not be supported.
Impact
- Compatibility: Some of the locale data in CLDR won't be compatible with the JDK's own locale data. There should be some mechanism for users to specify their preference.
- Localization: Developers working on localization will be able to add/modify locale data from CLDR in an established way.