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

[Masayoshi Okutsu]

On 8/14/2012 2:25 PM, Steven R. Loomis wrote:
> 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.

These are limitations of the existing parser. I've briefly checked the 
output, but I will need to work on the parser more.

Please note that we use the existing JRE classes (runtime) for CLDR 
support, not ICU4J. My understanding is that CLDR is after all the data 
part of ICU. A lot of adjustments need to be made to use the JRE classes.

> - Are you aware of the fact that CLDR 22 is nearly released?

Yes.

>   Has there been
> any testing with the interim data, or any plans to do so?

Currently we have no plan to use 22 in JDK 8. There are still tons of 
work to finish for JDK 8, including fixing ancient bugs.

> I think the summary again is, talk to us.  Where "us" is the CLDR technical
> committee.

Thanks for the suggestion, but do you mean it's risky to create 
something from the spec and its implementation (data)?

Masayoshi

>
> 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/
>>