On 8/14/12 11:43 AM, Steven R. Loomis wrote:
On Tue, Aug 14, 2012 at 10:53 AM, Naoto Sato <naoto.s...@oracle.com
<mailto:naoto.s...@oracle.com>> wrote:
Hi Steven,
I'll leave the implementation part discussion of the parser to
Masayoshi, but one of the main reasons we used the internally
existing parser was mainly the adaptation work that would be
required to port CLDR's parser into the JDK. In this regard, I
briefly had a chat with Yoshito a while ago, and he mentioned
someone was working on a filter mechanism on CLDR tool that could
emit JDK style format. That may be promising and worth considering
in the future release of JDK.
Thanks. Is there a need to put the parser itself (and data) into the JDK
? I noticed some discussion of licensing. Would it not be sufficient to
ensure that the CLDR tools could generate JDK format data, and check the
output of that into the JDK? Then you wouldn't need the xml itself in
the JDK (other than, of course, storing it for your own archival purposes)
I think the main reason to include the XML data and converter tool in
the JDK build tree is the integrity. Otherwise the result from different
CLDR data could generate different output from the Java APIs. JDK has
been including the Unicode Character Database for a particular version
per JDK release for the same reason.
Naoto
Thanks,
Steven
Naoto
On 8/13/12 10: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.
- Are you aware of the fact that CLDR 22 is nearly released? Has
there been
any testing with the interim data, or any plans to do so?
I think the summary again is, talk to us. Where "us" is the
CLDR technical
committee.
Regards,
Steven
On Mon, Aug 13, 2012 at 9:58 PM, Steven R. Loomis
<s...@icu-project.org <mailto:s...@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
<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@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
<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/~naoto/6336885/webrev.00/>
