<i18n dev> [8] Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data

[Steven R. Loomis]

Naoto,
 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
committee.

Regards,
Steven

On Mon, Aug 13, 2012 at 9:58 PM, Steven R. Loomis <srl at icu-project.org>wrote:

> Hello,
>  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.
>
> Steven
>
>
>
> -----
> Subject:
> 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
>
> Hello,
>
> 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:
>
> http://cr.openjdk.java.net/~naoto/6336885/webrev.00/
>