Hi Steven,
Thanks for your comments. Finally we are getting comments on the i18n
part. :-)
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.
- 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?
Thanks,
Masayoshi
More later when I get a chance, but definitely good work here.
Steven
-----
Subject:
To: i18n-dev <i18n-dev@openjdk.java.net>, Java Core Libs
<core-libs-...@openjdk.java.net>, build-...@openjdk.java.net
Message-ID: <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/
