<i18n dev>  Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data
Steven R. Loomis
srl at icu-project.org
Mon Aug 13 22:25:37 PDT 2012
okay, thought I was done for the night, but just two more things..
- again on the "talk to us" category.. Sun already wrote one LDML
converter, and contributed to another. They're part of the CLDR toolset and
work with OOo and Solaris data.
- also, it appears that the new converter doesn't handle aliases at all, or
parentLocales. You're guaranteed to get the wrong answer.
- Some of the processing (such as for Norwegian) and in other places seems
to be very .. hardcoded and fragile.
- Are you aware of the fact that CLDR 22 is nearly released? Has there been
any testing with the interim data, or any plans to do so?
I think the summary again is, talk to us. Where "us" is the CLDR technical
On Mon, Aug 13, 2012 at 9:58 PM, Steven R. Loomis <srl at icu-project.org>wrote:
> Some questions,
> - Is there a reason that a new parser was written, rather than leverage
> the existing CLDR tools (which are themselves written in Java)? (I've
> already suggested discussion with the CLDR-TC.. I know I've been personally
> more than a bit sparse, but, you know where we 'live')
> - It's incorrect to specifically open, for example, common/supplemental/numberingSystems.xml
> ( NUMBERING_SOURCE_FILE ) . You should not rely on the specific
> organization. See Appendix C of TR35, however, I filed
> http://unicode.org/cldr/trac/ticket/5189 to clarify the situation.
> More later when I get a chance, but definitely good work here.
> To: i18n-dev <i18n-dev at openjdk.java.net>, Java Core Libs
> <core-libs-dev at openjdk.java.net>, build-dev at openjdk.java.net
> Message-ID: <4FFC93CF.40105 at oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Please review the JDK8 changes for JEP 127: Improve Locale Data
> Packaging and Adopt Unicode CLDR Data
> (http://openjdk.java.net/jeps/127). The webrev is located at:
More information about the i18n-dev