Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
Most internationalization components in Java are designed to be locale data driven. For example, if date/time format strings (e.g., "yyyy-MM-dd") and calendar component names (e.g., month names) for a locale are added to the Java runtime, java.text.DateFormat produces desired date and time output for the targetted local users without implementing a DateFormat subclass. In Java SE, however, the process for defining and deploying such locale data isn't established. Currently, you have to handcraft Java programs only to define locale data. The lack of the process makes it difficult for our localizers and licensees to add more locale support. Even maintenance of existing locale data is difficult for localizers because they are often non-Java programmers. This RFE should address the following items. - Define an input format for defining locale dependent data. LDML (Locale Data Markup Language) is preferred because it's a standard defined by the Unicode consortium. The input format must be committed to by Sun as the public interface for defining locale data. - Develop a tool to generate locale data files for the runtime from the input format, assuming that interpreting an LDML file at runtime isn't feasible due to performance and footprint issues. The output file format shall remain Sun private for future extensions. - Develop a mechanism to deploy locale data. (We may utilize Modules - JSR277 or brew our own.)
|