<i18n dev>  Review request for JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data
masayoshi.okutsu at oracle.com
Tue Aug 14 17:00:31 PDT 2012
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:
> 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,
> ( 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.
> More later when I get a chance, but definitely good work here.
> 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
> 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