> CLDR is written in XML. If its spec is well defined and stable, what's
the problem (risk) to write an XML parser to convert the XML files to
another format?
The issue is not the definition or stability. We have found that if
implementations are not aware of the aliasing and parent relations (as
On 8/15/2012 1:52 AM, Steven R. Loomis wrote:
On Tue, Aug 14, 2012 at 2:37 AM, Masayoshi Okutsu
mailto:masayoshi.oku...@oracle.com>> wrote:
On 8/14/2012 2:25 PM, Steven R. Loomis wrote:
Naoto,
okay, thought I was done for the night, but just two more
things..
On 8/15/2012 1:38 AM, Steven R. Loomis wrote:
On Tue, Aug 14, 2012 at 2:03 AM, Masayoshi Okutsu
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
Thanks, Erik!
I incorporated your build-infra changes into the main changeset, and
created a new combined webrev as follows:
http://cr.openjdk.java.net/~naoto/6336885/webrev.02/
Naoto
On 8/13/12 11:40 PM, Erik Joelsson wrote:
I finished making the changes yesterday, but didn't manage to get
On 8/14/12 11:43 AM, Steven R. Loomis wrote:
On Tue, Aug 14, 2012 at 10:53 AM, Naoto Sato 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
On Tue, Aug 14, 2012 at 10:53 AM, Naoto Sato 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
Hi David,
We are planning to push the changes through T/L repos.
Although I think it's unlikely that our changes and JSR 292 ones would
interfere, it would be good to push them in a later promotion build. I
will shoot for the next one after the "flag day."
Naoto
On 8/13/12 11:57 PM, David H
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
On Tue, Aug 14, 2012 at 2:37 AM, Masayoshi Okutsu <
masayoshi.oku...@oracle.com> wrote:
> On 8/14/2012 2: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
>> con
On Tue, Aug 14, 2012 at 2:03 AM, Masayoshi Okutsu <
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,
>>
>> -
Andrew - good catch. We're reviewing.
On Aug 14, 2012, at 2:51 AM, Andrew Hughes wrote:
> - Original Message -
>> 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 lo
- Original Message -
> 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/
>
> The main bug id for this
On 8/14/2012 2: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.
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
14 matches
Mail list logo
