On 8/15/2012 1:38 AM, Steven R. Loomis wrote:
On Tue, Aug 14, 2012 at 2:03 AM, Masayoshi Okutsu
<masayoshi.oku...@oracle.com <mailto:masayoshi.oku...@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@openjdk.java.net
<mailto:i18n-dev@openjdk.java.net>>, Java Core Libs
<core-libs-...@openjdk.java.net
<mailto:core-libs-...@openjdk.java.net>>,
build-...@openjdk.java.net <mailto:build-...@openjdk.java.net>
Message-ID: <4ffc93cf.40...@oracle.com
<mailto:4ffc93cf.40...@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/>
