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

[Masayoshi Okutsu]

On 8/15/2012 1:38 AM, Steven R. Loomis wrote:
> On Tue, Aug 14, 2012 at 2:03 AM, Masayoshi Okutsu 
> <masayoshi.okutsu at oracle.com <mailto:masayoshi.okutsu at oracle.com>> wrote:
>
>     Hi Steven,
>
>     Thanks for your comments. Finally we are getting comments on the
>     i18n part. :-)
>
>
> You're welcome!
>
>     On 8/14/2012 1:58 PM, Steven R. Loomis 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')
>
>
>     The parser isn't new actually. It's been used to maintain JRE
>     locale data for years. I've been just extending the existing parser.
>
>
> The question could still apply years ago. Was it considered to use 
> org.unicode.cldr.util classes?

I don't know. I wasn't involved in the parser development. It was 
originally written by Norbert and has been maintained by several people, 
including some localization team members. This is the first time I 
touched the parser.

>
>
>           - 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.
>
>
>     The parser is a build-time tool, not for runtime, which allows us
>     to deal with CLDR changes. Actually TR#35 isn't stable. Right?
>
>
> I don't understand what you mean.  At build time, you should not 
> expect there to be a particular "numberingSystems.xml" file. All 
> of common/supplemental/* should be read together.

If the runtime directly depended on such file organization, it's harder 
to maintain releases.

>
> TR#35 is actually fairly stable, and we follow a very careful 
> stability policy. The vast majority of changes are simply adding new 
> data, or new structure that could otherwise be ignored.

I noticed that an item which was in the original parser no longer exists 
in the current CLDR. Also I was surprised because the calendar type 
definition was changed early this year. Those things give me an 
impression that TR#35 is unstable.

Masayoshi

>     Thanks,
>     Masayoshi
>
>
>
>         More later when I get a chance, but definitely good work here.
>
>         Steven
>
>
>
>         -----
>         Subject:
>         To: i18n-dev <i18n-dev at openjdk.java.net
>         <mailto:i18n-dev at openjdk.java.net>>,   Java Core Libs
>                  <core-libs-dev at openjdk.java.net
>         <mailto:core-libs-dev at openjdk.java.net>>,
>         build-dev at openjdk.java.net <mailto:build-dev at openjdk.java.net>
>         Message-ID: <4FFC93CF.40105 at oracle.com
>         <mailto: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/
>         <http://cr.openjdk.java.net/%7Enaoto/6336885/webrev.00/>
>
>