From masayoshi.okutsu at oracle.com  Sun Dec  1 23:09:27 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 02 Dec 2013 16:09:27 +0900
Subject: <i18n dev> [8] RFR: JDK-8028368 : There is no description
 whether or not java.util.ResourceBundle is thread-safe
In-Reply-To: <5297031B.2000408@oracle.com>
References: <52939BA7.4080402@oracle.com> <52961BCA.2080303@oracle.com>
	<5297031B.2000408@oracle.com>
Message-ID: <529C3227.4060202@oracle.com>

The proposal has been approved and the webrev looks good.

Masayoshi

On 11/28/2013 5:47 PM, Masayoshi Okutsu wrote:
> Hi Naoto,
>
> I'd like to wait until the API change proposal gets approved.
>
> Thanks,
> Masayoshi
>
> On 11/28/2013 1:20 AM, Naoto Sato wrote:
>> And this one too. Thanks!
>>
>> Naoto
>>
>> On 13-11-25 ??10:49, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix for the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8028368
>>>
>>> The proposed changeset is here:
>>>
>>> http://cr.openjdk.java.net/~naoto/8028368/webrev.00/
>>>
>>> It is just a clarification of the current behavior in the spec.
>>>
>>> Naoto
>


From francis.andre.kampbell at orange.fr  Mon Dec  2 20:03:37 2013
From: francis.andre.kampbell at orange.fr (Francis ANDRE)
Date: Tue, 03 Dec 2013 05:03:37 +0100
Subject: <i18n dev> [7u]: org.omg.PortableServer.AdapterActivator.java
 compile fails on French platform
Message-ID: <529D5819.2030202@orange.fr>

Hi

Found a surprising issue when building the jdk7u on a French platform with this 
compile error

Z:\JDK\JDK7U-~2\build\windows-i586\corba\gensrc\org\omg\PortableServer\AdapterActivator.java:8: 
error: unmappable character for encoding ascii
* lundi 2 d?cembre 2013 19 h 22 CET
            ^

In effect, the header generated is

/**
* org/omg/PortableServer/AdapterActivator.java .
* Generated by the IDL-to-Java compiler (portable), version "3.2"
* from ../../../../src/share/classes/org/omg/PortableServer/poa.idl
* lundi 2 d?cembre 2013 19 h 22 CET
*/
  which contains the "?" character in the french month of december.

As the compiling command request an ASCII encoding, it fails as "?" is not ASCII.

make[5]: Entering directory 
`/cygdrive/Z/JDK/jdk7u-dev/corba/make/org/omg/PortableServer'
if [ -s 
Z:/JDK/JDK7U-~2/build/windows-i586/corba/tmp/org/org.omg.PortableServer/.classes.list 
] ; then \
   /usr/bin/cat 
Z:/JDK/JDK7U-~2/build/windows-i586/corba/tmp/org/org.omg.PortableServer/.classes.list; 
\
   C:/Progra~1/Java/jdk1.6.0_35/bin/java -XX:-PrintVMOptions 
-XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx512m -Xms512m 
-XX:PermSize=32m -XX:MaxPermSize=160m 
"-Xbootclasspath/p:Z:/JDK/JDK7U-~2/build/WINDOW~1/LANGTO~1/dist/bootstrap/lib/javac.jar" 
-jar Z:/JDK/JDK7U-~2/build/WINDOW~1/LANGTO~1/dist/bootstrap/lib/javac.jar 
-XDignore.symbol.file=true -source 7 -target 7 *-encoding ascii *-classpath 
C:/Progra~1/Java/jdk1.6.0_35/lib/tools.jar  -Xprefer:source -sourcepath 
"Z:/JDK/JDK7U-~2/build/windows-i586/corba/gensrc;../../../../src/windows/classes;../../../../src/share/classes" 
-d Z:/JDK/JDK7U-~2/build/windows-i586/corba/classes 
@Z:/JDK/JDK7U-~2/build/windows-i586/corba/tmp/org/org.omg.PortableServer/.classes.list; 
\
fi


I would suggest to fix this issue by removing the "-encoding ascii" parameter 
since pao.idl should contains only ascii characters and is not subject to i18n 
problem (except for the idl-to-java translation time in the header comment).

Francis

From michael.fang at oracle.com  Tue Dec  3 17:10:42 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 03 Dec 2013 17:10:42 -0800
Subject: <i18n dev> [8] Request for review: 8029239: jdk8 l10n resource file
 translation update - localenames
Message-ID: <529E8112.1080907@oracle.com>

Hi,

Please help to review the changes for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8029239

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8029239/

The changes included the following:

Portuguese files were updated with resources generated from CLDR 2.1. 
LocaleNames_pt_BR.properties have been removed as a result. Regression 
tests were performed and failed tests were updated to be compatible with 
the changes to CLDR 2.1.

There are also translation capitalization changes. I did some research 
about capitalization rules and found that for Spanish, French, Italian, 
Portuguese, and Swedish, language names are not capitalized, but country 
names are and these are consistent with CLDR as well.

References about capitalization
http://meta.wikimedia.org/wiki/Capitalization_of_Wiktionary_pages#Languages_without_capitalization: 
es, fr, it, sv, pt, etc

Spanish: 
http://www.howto.gov/web-content/multilingual/spanish-guide/capitalization
French: http://french.about.com/library/writing/bl-capitalization.htm
Italian: http://www.translationdirectory.com/article714.htm
Swedish: http://en.wikibooks.org/wiki/Swedish/Nationalities

There are also translation changes performed by translators. I reviewed 
each change against CLDR. I only accepted the changes that's consistent 
with CLDR since I don't know the languages and could only use CLDR as a 
reference.

I did not add new regression tests for the translation changes since 
there are no formatting changes, just translation changes. We have a 
keyword noreg-l10n that covers the exception for requiring regression 
tests for translation changes.

thanks,

-michael

From michael.fang at oracle.com  Tue Dec  3 20:02:18 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 03 Dec 2013 20:02:18 -0800
Subject: <i18n dev> [8] Request for review: 8029239: jdk8 l10n resource
 file translation update - localenames
In-Reply-To: <529E8112.1080907@oracle.com>
References: <529E8112.1080907@oracle.com>
Message-ID: <529EA94A.3070101@oracle.com>

I have updated the webrev 
http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.01/

2 failed regression tests have been addressed:

----------System.out:(7/192)*----------
Mismatch in LocaleNames/pt/wa:
   file = "val\\\\u00e3o"
    jvm = "val\\u00e3o"
Mismatch in LocaleNames/pt/FM:
   file = "Micron\\\\u00e9sia"
    jvm = "Micron\\u00e9sia"
Test failed.  2 errors.


thanks,

-michael

On 13?12?03? 05:10 ??, Michael Fang wrote:
> Hi,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8029239
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8029239/
>
> The changes included the following:
>
> Portuguese files were updated with resources generated from CLDR 2.1. 
> LocaleNames_pt_BR.properties have been removed as a result. Regression 
> tests were performed and failed tests were updated to be compatible 
> with the changes to CLDR 2.1.
>
> There are also translation capitalization changes. I did some research 
> about capitalization rules and found that for Spanish, French, 
> Italian, Portuguese, and Swedish, language names are not capitalized, 
> but country names are and these are consistent with CLDR as well.
>
> References about capitalization
> http://meta.wikimedia.org/wiki/Capitalization_of_Wiktionary_pages#Languages_without_capitalization: 
> es, fr, it, sv, pt, etc
>
> Spanish: 
> http://www.howto.gov/web-content/multilingual/spanish-guide/capitalization
> French: http://french.about.com/library/writing/bl-capitalization.htm
> Italian: http://www.translationdirectory.com/article714.htm
> Swedish: http://en.wikibooks.org/wiki/Swedish/Nationalities
>
> There are also translation changes performed by translators. I 
> reviewed each change against CLDR. I only accepted the changes that's 
> consistent with CLDR since I don't know the languages and could only 
> use CLDR as a reference.
>
> I did not add new regression tests for the translation changes since 
> there are no formatting changes, just translation changes. We have a 
> keyword noreg-l10n that covers the exception for requiring regression 
> tests for translation changes.
>
> thanks,
>
> -michael


From masayoshi.okutsu at oracle.com  Wed Dec  4 01:17:52 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 04 Dec 2013 18:17:52 +0900
Subject: <i18n dev> [8] Request for review: 8029239: jdk8 l10n resource
 file translation update - localenames
In-Reply-To: <529EA94A.3070101@oracle.com>
References: <529E8112.1080907@oracle.com> <529EA94A.3070101@oracle.com>
Message-ID: <529EF340.9060804@oracle.com>

I still don't like the unnecessary case changes for the \uxxxx notation, 
which makes code review very difficult (even UTF-8 ones).

I noticed the following change uses '=' (the second one) as a word 
delimiter. This looks strange to me.

src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties:
-afa=\u30A2\u30D5\u30AC\u30CB\u30FC (1927-2002)
+afa=\u30A2\u30D5\u30ED=\u30A2\u30B8\u30A2\u8A9E\u65CF

Should the bug# be added to test/sun/text/resources/LocaleDataTest.java 
when LocaleData has been modified?

Thanks,
Masayoshi

On 12/4/2013 1:02 PM, Michael Fang wrote:
> I have updated the webrev 
> http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.01/
>
> 2 failed regression tests have been addressed:
>
> ----------System.out:(7/192)*----------
> Mismatch in LocaleNames/pt/wa:
>   file = "val\\\\u00e3o"
>    jvm = "val\\u00e3o"
> Mismatch in LocaleNames/pt/FM:
>   file = "Micron\\\\u00e9sia"
>    jvm = "Micron\\u00e9sia"
> Test failed.  2 errors.
>
>
> thanks,
>
> -michael
>
> On 13?12?03? 05:10 ??, Michael Fang wrote:
>> Hi,
>>
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-8029239
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8029239/
>>
>> The changes included the following:
>>
>> Portuguese files were updated with resources generated from CLDR 2.1. 
>> LocaleNames_pt_BR.properties have been removed as a result. 
>> Regression tests were performed and failed tests were updated to be 
>> compatible with the changes to CLDR 2.1.
>>
>> There are also translation capitalization changes. I did some 
>> research about capitalization rules and found that for Spanish, 
>> French, Italian, Portuguese, and Swedish, language names are not 
>> capitalized, but country names are and these are consistent with CLDR 
>> as well.
>>
>> References about capitalization
>> http://meta.wikimedia.org/wiki/Capitalization_of_Wiktionary_pages#Languages_without_capitalization: 
>> es, fr, it, sv, pt, etc
>>
>> Spanish: 
>> http://www.howto.gov/web-content/multilingual/spanish-guide/capitalization
>> French: http://french.about.com/library/writing/bl-capitalization.htm
>> Italian: http://www.translationdirectory.com/article714.htm
>> Swedish: http://en.wikibooks.org/wiki/Swedish/Nationalities
>>
>> There are also translation changes performed by translators. I 
>> reviewed each change against CLDR. I only accepted the changes that's 
>> consistent with CLDR since I don't know the languages and could only 
>> use CLDR as a reference.
>>
>> I did not add new regression tests for the translation changes since 
>> there are no formatting changes, just translation changes. We have a 
>> keyword noreg-l10n that covers the exception for requiring regression 
>> tests for translation changes.
>>
>> thanks,
>>
>> -michael
>


From michael.fang at oracle.com  Wed Dec  4 15:02:24 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 04 Dec 2013 15:02:24 -0800
Subject: <i18n dev> [8] Request for review: 8029239: jdk8 l10n resource
 file translation update - localenames
In-Reply-To: <529EF340.9060804@oracle.com>
References: <529E8112.1080907@oracle.com> <529EA94A.3070101@oracle.com>
	<529EF340.9060804@oracle.com>
Message-ID: <529FB480.9090301@oracle.com>

Thanks Masayoshi for the feedback.

I looked at the existing LocaleNames_xx.properties files and it contains 
lower case \uxxxx notation for most of sections of the files, but newer 
sections as ISO 639.2 language code and ISO 15924 script code were in 
upper case since they were added by the current translation team.

I converted the files to all lower case \uxxxx notation and the webrev 
didn't help (worse with even more deltas):
http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.02/

To make it easier to review, I have created updated version of webrev 
that ignores cases with "diff -i" option.
http://cr.openjdk.java.net/~mfang/8029239/webrev_ignore_case.ksh
But I kept the upper case \uxxxx notation because that's what I will be 
receiving from translation team going forward. In the future, the diff 
should be more manageable.

The resulting webrev:
http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.03/
http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.03.utf8/

I need to check with translation team about the Japanese translation 
issue for "afa".

I have added bug# to test/sun/text/resources/LocaleDataTest.java

thanks,

-michael

On 13?12?04? 01:17 ??, Masayoshi Okutsu wrote:
> I still don't like the unnecessary case changes for the \uxxxx 
> notation, which makes code review very difficult (even UTF-8 ones).
>
> I noticed the following change uses '=' (the second one) as a word 
> delimiter. This looks strange to me.
>
> src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties:
> -afa=\u30A2\u30D5\u30AC\u30CB\u30FC (1927-2002)
> +afa=\u30A2\u30D5\u30ED=\u30A2\u30B8\u30A2\u8A9E\u65CF
>
> Should the bug# be added to 
> test/sun/text/resources/LocaleDataTest.java when LocaleData has been 
> modified?
>
> Thanks,
> Masayoshi
>
> On 12/4/2013 1:02 PM, Michael Fang wrote:
>> I have updated the webrev 
>> http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.01/
>>
>> 2 failed regression tests have been addressed:
>>
>> ----------System.out:(7/192)*----------
>> Mismatch in LocaleNames/pt/wa:
>>   file = "val\\\\u00e3o"
>>    jvm = "val\\u00e3o"
>> Mismatch in LocaleNames/pt/FM:
>>   file = "Micron\\\\u00e9sia"
>>    jvm = "Micron\\u00e9sia"
>> Test failed.  2 errors.
>>
>>
>> thanks,
>>
>> -michael
>>
>> On 13?12?03? 05:10 ??, Michael Fang wrote:
>>> Hi,
>>>
>>> Please help to review the changes for the following CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8029239
>>>
>>> The webrev is available here:
>>> http://cr.openjdk.java.net/~mfang/8029239/
>>>
>>> The changes included the following:
>>>
>>> Portuguese files were updated with resources generated from CLDR 
>>> 2.1. LocaleNames_pt_BR.properties have been removed as a result. 
>>> Regression tests were performed and failed tests were updated to be 
>>> compatible with the changes to CLDR 2.1.
>>>
>>> There are also translation capitalization changes. I did some 
>>> research about capitalization rules and found that for Spanish, 
>>> French, Italian, Portuguese, and Swedish, language names are not 
>>> capitalized, but country names are and these are consistent with 
>>> CLDR as well.
>>>
>>> References about capitalization
>>> http://meta.wikimedia.org/wiki/Capitalization_of_Wiktionary_pages#Languages_without_capitalization: 
>>> es, fr, it, sv, pt, etc
>>>
>>> Spanish: 
>>> http://www.howto.gov/web-content/multilingual/spanish-guide/capitalization
>>> French: http://french.about.com/library/writing/bl-capitalization.htm
>>> Italian: http://www.translationdirectory.com/article714.htm
>>> Swedish: http://en.wikibooks.org/wiki/Swedish/Nationalities
>>>
>>> There are also translation changes performed by translators. I 
>>> reviewed each change against CLDR. I only accepted the changes 
>>> that's consistent with CLDR since I don't know the languages and 
>>> could only use CLDR as a reference.
>>>
>>> I did not add new regression tests for the translation changes since 
>>> there are no formatting changes, just translation changes. We have a 
>>> keyword noreg-l10n that covers the exception for requiring 
>>> regression tests for translation changes.
>>>
>>> thanks,
>>>
>>> -michael
>>
>


From masayoshi.okutsu at oracle.com  Wed Dec  4 23:23:33 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 05 Dec 2013 16:23:33 +0900
Subject: <i18n dev> [8] Request for review: 8029239: jdk8 l10n resource
 file translation update - localenames
In-Reply-To: <529FB480.9090301@oracle.com>
References: <529E8112.1080907@oracle.com> <529EA94A.3070101@oracle.com>
	<529EF340.9060804@oracle.com> <529FB480.9090301@oracle.com>
Message-ID: <52A029F5.30505@oracle.com>

Thanks for making the \uxxxx changes. It's much easier to review.

I checked LocaleNames_ja.properties with JIS X 0412 (Japanese version of 
ISO 639) and JIS X 0304 (Japanese version of ISO 3166). Many changes 
corrected wrong names, but there are still questionable ones, and some 
are inconsistent with JIS X 0412/0304, such as ??????? to ?? 
for CN because ?? is too ambiguous [1]. My preference is to follow the 
JIS standards (where applicable).

Also I noticed some new script names are missing, such as Jurc for 
Jurchen. Should this problem be out of the scope with the 8029239 fix?

Thanks,
Masayoshi

[1] 
http://ja.wikipedia.org/wiki/%E4%B8%AD%E5%9B%BD_%28%E6%9B%96%E6%98%A7%E3%81%95%E5%9B%9E%E9%81%BF%29

On 12/5/2013 8:02 AM, Michael Fang wrote:
> Thanks Masayoshi for the feedback.
>
> I looked at the existing LocaleNames_xx.properties files and it 
> contains lower case \uxxxx notation for most of sections of the files, 
> but newer sections as ISO 639.2 language code and ISO 15924 script 
> code were in upper case since they were added by the current 
> translation team.
>
> I converted the files to all lower case \uxxxx notation and the webrev 
> didn't help (worse with even more deltas):
> http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.02/
>
> To make it easier to review, I have created updated version of webrev 
> that ignores cases with "diff -i" option.
> http://cr.openjdk.java.net/~mfang/8029239/webrev_ignore_case.ksh
> But I kept the upper case \uxxxx notation because that's what I will 
> be receiving from translation team going forward. In the future, the 
> diff should be more manageable.
>
> The resulting webrev:
> http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.03/
> http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.03.utf8/
>
> I need to check with translation team about the Japanese translation 
> issue for "afa".
>
> I have added bug# to test/sun/text/resources/LocaleDataTest.java
>
> thanks,
>
> -michael
>
> On 13?12?04? 01:17 ??, Masayoshi Okutsu wrote:
>> I still don't like the unnecessary case changes for the \uxxxx 
>> notation, which makes code review very difficult (even UTF-8 ones).
>>
>> I noticed the following change uses '=' (the second one) as a word 
>> delimiter. This looks strange to me.
>>
>> src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties:
>> -afa=\u30A2\u30D5\u30AC\u30CB\u30FC (1927-2002)
>> +afa=\u30A2\u30D5\u30ED=\u30A2\u30B8\u30A2\u8A9E\u65CF
>>
>> Should the bug# be added to 
>> test/sun/text/resources/LocaleDataTest.java when LocaleData has been 
>> modified?
>>
>> Thanks,
>> Masayoshi
>>
>> On 12/4/2013 1:02 PM, Michael Fang wrote:
>>> I have updated the webrev 
>>> http://cr.openjdk.java.net/~mfang/8029239/webrev.jdk.01/
>>>
>>> 2 failed regression tests have been addressed:
>>>
>>> ----------System.out:(7/192)*----------
>>> Mismatch in LocaleNames/pt/wa:
>>>   file = "val\\\\u00e3o"
>>>    jvm = "val\\u00e3o"
>>> Mismatch in LocaleNames/pt/FM:
>>>   file = "Micron\\\\u00e9sia"
>>>    jvm = "Micron\\u00e9sia"
>>> Test failed.  2 errors.
>>>
>>>
>>> thanks,
>>>
>>> -michael
>>>
>>> On 13?12?03? 05:10 ??, Michael Fang wrote:
>>>> Hi,
>>>>
>>>> Please help to review the changes for the following CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8029239
>>>>
>>>> The webrev is available here:
>>>> http://cr.openjdk.java.net/~mfang/8029239/
>>>>
>>>> The changes included the following:
>>>>
>>>> Portuguese files were updated with resources generated from CLDR 
>>>> 2.1. LocaleNames_pt_BR.properties have been removed as a result. 
>>>> Regression tests were performed and failed tests were updated to be 
>>>> compatible with the changes to CLDR 2.1.
>>>>
>>>> There are also translation capitalization changes. I did some 
>>>> research about capitalization rules and found that for Spanish, 
>>>> French, Italian, Portuguese, and Swedish, language names are not 
>>>> capitalized, but country names are and these are consistent with 
>>>> CLDR as well.
>>>>
>>>> References about capitalization
>>>> http://meta.wikimedia.org/wiki/Capitalization_of_Wiktionary_pages#Languages_without_capitalization: 
>>>> es, fr, it, sv, pt, etc
>>>>
>>>> Spanish: 
>>>> http://www.howto.gov/web-content/multilingual/spanish-guide/capitalization
>>>> French: http://french.about.com/library/writing/bl-capitalization.htm
>>>> Italian: http://www.translationdirectory.com/article714.htm
>>>> Swedish: http://en.wikibooks.org/wiki/Swedish/Nationalities
>>>>
>>>> There are also translation changes performed by translators. I 
>>>> reviewed each change against CLDR. I only accepted the changes 
>>>> that's consistent with CLDR since I don't know the languages and 
>>>> could only use CLDR as a reference.
>>>>
>>>> I did not add new regression tests for the translation changes 
>>>> since there are no formatting changes, just translation changes. We 
>>>> have a keyword noreg-l10n that covers the exception for requiring 
>>>> regression tests for translation changes.
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>
>>
>


From michael.fang at oracle.com  Thu Dec  5 17:15:39 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Thu, 05 Dec 2013 17:15:39 -0800
Subject: <i18n dev> [8] Request for review: 8025974: l10n for policytool
Message-ID: <52A1253B.7040000@oracle.com>

Hi,

Please help to review the changes for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8025974

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8025974/

thanks,

-michael

From naoto.sato at oracle.com  Fri Dec  6 13:41:27 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 06 Dec 2013 13:41:27 -0800
Subject: <i18n dev> [8] Request for review: 8025974: l10n for policytool
In-Reply-To: <52A1253B.7040000@oracle.com>
References: <52A1253B.7040000@oracle.com>
Message-ID: <52A24487.3000103@oracle.com>

Looks good to me.

Naoto

On 12/5/13, 5:15 PM, Michael Fang wrote:
> Hi,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8025974
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8025974/
>
> thanks,
>
> -michael


From michael.fang at oracle.com  Fri Dec  6 13:57:35 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Fri, 6 Dec 2013 13:57:35 -0800
Subject: <i18n dev> [8] Request for review: 8025974: l10n for policytool
In-Reply-To: <52A24487.3000103@oracle.com>
References: <52A1253B.7040000@oracle.com> <52A24487.3000103@oracle.com>
Message-ID: <1DE06A4A-4C08-4CAD-8D05-F11993DBA012@oracle.com>

Thanks for the review!

Regards,

Michael
Sent from my iPhone

> On Dec 6, 2013, at 1:41 PM, Naoto Sato <naoto.sato at oracle.com> wrote:
> 
> Looks good to me.
> 
> Naoto
> 
>> On 12/5/13, 5:15 PM, Michael Fang wrote:
>> Hi,
>> 
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-8025974
>> 
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8025974/
>> 
>> thanks,
>> 
>> -michael
> 

From michael.fang at oracle.com  Mon Dec  9 14:32:11 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 09 Dec 2013 14:32:11 -0800
Subject: <i18n dev> [8] Request for review: 7090826: Newly added codes need
 to be localized into pt_BR in LocaleNames.
Message-ID: <52A644EB.6030104@oracle.com>

Hi,

Since it's a little bit complicated to review 8029239: jdk8 l10n 
resource file translation update - localenames, I would like to separate 
out the Portuguese portion out back to 7090826 Newly added codes need to 
be localized into pt_BR in LocaleNames.

The Portuguese files are fully generated from CLDR, so it should be 
relatively easy to review. LocaleNames_pt_BR.properties have been 
removed as a result since CLDR doesn't have a separate pt_BR.xml file now.

Please help to review the changes for the following CR:
https://bugs.openjdk.java.net/browse/JDK-7090826

The webrev is available here:
http://cr.openjdk.java.net/~mfang/7090826/webrev.00/

thanks,

-michael

From michael.fang at oracle.com  Wed Dec 11 16:04:34 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 11 Dec 2013 16:04:34 -0800
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
Message-ID: <52A8FD92.9090406@oracle.com>

Hi,

Please help to review the changes for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8026115

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8026115/

thanks,

-michael

From naoto.sato at oracle.com  Wed Dec 11 16:19:03 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Dec 2013 16:19:03 -0800
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
In-Reply-To: <52A8FD92.9090406@oracle.com>
References: <52A8FD92.9090406@oracle.com>
Message-ID: <52A900F7.6040408@oracle.com>

Looks good to me.

Naoto

On 12/11/13 4:04 PM, Michael Fang wrote:
> Hi,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8026115
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8026115/
>
> thanks,
>
> -michael

From michael.fang at oracle.com  Wed Dec 11 17:03:47 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 11 Dec 2013 17:03:47 -0800
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
In-Reply-To: <52A900F7.6040408@oracle.com>
References: <52A8FD92.9090406@oracle.com> <52A900F7.6040408@oracle.com>
Message-ID: <52A90B73.3080007@oracle.com>

Thanks Naoto for the review!

-michael

On 13?12?11? 04:19 ??, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 12/11/13 4:04 PM, Michael Fang wrote:
>> Hi,
>>
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-8026115
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8026115/
>>
>> thanks,
>>
>> -michael


From yong.huang at oracle.com  Wed Dec 11 20:01:11 2013
From: yong.huang at oracle.com (Yong Huang)
Date: Thu, 12 Dec 2013 12:01:11 +0800
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
In-Reply-To: <52A8FD92.9090406@oracle.com>
References: <52A8FD92.9090406@oracle.com>
Message-ID: <52A93507.30404@oracle.com>

It looks good to me.

thanks,
Yong

On 2013/12/12 8:04, Michael Fang wrote:
> Hi,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8026115
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8026115/
>
> thanks,
>
> -michael


From michael.fang at oracle.com  Wed Dec 11 20:02:23 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Wed, 11 Dec 2013 20:02:23 -0800
Subject: <i18n dev> [8] Request for review: 8026115: [zh_CN] inproper
 translation in output of jarsigner command
In-Reply-To: <52A93507.30404@oracle.com>
References: <52A8FD92.9090406@oracle.com> <52A93507.30404@oracle.com>
Message-ID: <52A9354F.7080009@oracle.com>

Thanks Yong for the co-review!

-michael

On 13?12?11? 08:01 ??, Yong Huang wrote:
> It looks good to me.
>
> thanks,
> Yong
>
> On 2013/12/12 8:04, Michael Fang wrote:
>> Hi,
>>
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-8026115
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8026115/
>>
>> thanks,
>>
>> -michael
>


From masayoshi.okutsu at oracle.com  Wed Dec 11 20:14:11 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 12 Dec 2013 13:14:11 +0900
Subject: <i18n dev> [8] Request for review: 7090826: Newly added codes
 need to be localized into pt_BR in LocaleNames.
In-Reply-To: <52A644EB.6030104@oracle.com>
References: <52A644EB.6030104@oracle.com>
Message-ID: <52A93813.1040808@oracle.com>

src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties:

Looks like CS (transitionally reserved) has been removed and fallback is 
expected. But CS seems to be still alive in other locales according to 
the 8029239 webrev. I think it should be consistent with other locales 
(either remove CS from all locales or keep it in pt).

test/sun/text/resources/LocaleData:

+#bug 7090826 pt data updated to CLDR 2.1

Should the CLDR version be 21?

Otherwise, the fix looks good to me.

Thanks,
Masayoshi

On 12/10/2013 7:32 AM, Michael Fang wrote:
> Hi,
>
> Since it's a little bit complicated to review 8029239: jdk8 l10n 
> resource file translation update - localenames, I would like to 
> separate out the Portuguese portion out back to 7090826 Newly added 
> codes need to be localized into pt_BR in LocaleNames.
>
> The Portuguese files are fully generated from CLDR, so it should be 
> relatively easy to review. LocaleNames_pt_BR.properties have been 
> removed as a result since CLDR doesn't have a separate pt_BR.xml file 
> now.
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-7090826
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/7090826/webrev.00/
>
> thanks,
>
> -michael


From michael.fang at oracle.com  Thu Dec 12 14:33:59 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Thu, 12 Dec 2013 14:33:59 -0800
Subject: <i18n dev> [8] Request for review: 7090826: Newly added codes
 need to be localized into pt_BR in LocaleNames.
In-Reply-To: <52A93813.1040808@oracle.com>
References: <52A644EB.6030104@oracle.com> <52A93813.1040808@oracle.com>
Message-ID: <52AA39D7.2050507@oracle.com>

Thanks Masayoshi for the review.

I have added CS back to LocaleNames_pt.properties file, corrected 
LocaleData test related to CS and corrected the CLDR version number, 
which is 21.0.1.

The new webrev is:
http://cr.openjdk.java.net/~mfang/7090826/webrev.01/

JPRT build also completed successfully and passed the core testset.

thanks,

-michael

On 13?12?11? 08:14 ??, Masayoshi Okutsu wrote:
> src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties:
>
> Looks like CS (transitionally reserved) has been removed and fallback 
> is expected. But CS seems to be still alive in other locales according 
> to the 8029239 webrev. I think it should be consistent with other 
> locales (either remove CS from all locales or keep it in pt).
>
> test/sun/text/resources/LocaleData:
>
> +#bug 7090826 pt data updated to CLDR 2.1
>
> Should the CLDR version be 21?
>
> Otherwise, the fix looks good to me.
>
> Thanks,
> Masayoshi
>
> On 12/10/2013 7:32 AM, Michael Fang wrote:
>> Hi,
>>
>> Since it's a little bit complicated to review 8029239: jdk8 l10n 
>> resource file translation update - localenames, I would like to 
>> separate out the Portuguese portion out back to 7090826 Newly added 
>> codes need to be localized into pt_BR in LocaleNames.
>>
>> The Portuguese files are fully generated from CLDR, so it should be 
>> relatively easy to review. LocaleNames_pt_BR.properties have been 
>> removed as a result since CLDR doesn't have a separate pt_BR.xml file 
>> now.
>>
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-7090826
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/7090826/webrev.00/
>>
>> thanks,
>>
>> -michael
>


From masayoshi.okutsu at oracle.com  Mon Dec 16 16:45:00 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 17 Dec 2013 09:45:00 +0900
Subject: <i18n dev> [8] Request for review: 7090826: Newly added codes
 need to be localized into pt_BR in LocaleNames.
In-Reply-To: <52AA39D7.2050507@oracle.com>
References: <52A644EB.6030104@oracle.com> <52A93813.1040808@oracle.com>
	<52AA39D7.2050507@oracle.com>
Message-ID: <52AF9E8C.70302@oracle.com>

Looks good.

Masayoshi

On 12/13/2013 7:33 AM, Michael Fang wrote:
> Thanks Masayoshi for the review.
>
> I have added CS back to LocaleNames_pt.properties file, corrected 
> LocaleData test related to CS and corrected the CLDR version number, 
> which is 21.0.1.
>
> The new webrev is:
> http://cr.openjdk.java.net/~mfang/7090826/webrev.01/
>
> JPRT build also completed successfully and passed the core testset.
>
> thanks,
>
> -michael
>
> On 13?12?11? 08:14 ??, Masayoshi Okutsu wrote:
>> src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties:
>>
>> Looks like CS (transitionally reserved) has been removed and fallback 
>> is expected. But CS seems to be still alive in other locales 
>> according to the 8029239 webrev. I think it should be consistent with 
>> other locales (either remove CS from all locales or keep it in pt).
>>
>> test/sun/text/resources/LocaleData:
>>
>> +#bug 7090826 pt data updated to CLDR 2.1
>>
>> Should the CLDR version be 21?
>>
>> Otherwise, the fix looks good to me.
>>
>> Thanks,
>> Masayoshi
>>
>> On 12/10/2013 7:32 AM, Michael Fang wrote:
>>> Hi,
>>>
>>> Since it's a little bit complicated to review 8029239: jdk8 l10n 
>>> resource file translation update - localenames, I would like to 
>>> separate out the Portuguese portion out back to 7090826 Newly added 
>>> codes need to be localized into pt_BR in LocaleNames.
>>>
>>> The Portuguese files are fully generated from CLDR, so it should be 
>>> relatively easy to review. LocaleNames_pt_BR.properties have been 
>>> removed as a result since CLDR doesn't have a separate pt_BR.xml 
>>> file now.
>>>
>>> Please help to review the changes for the following CR:
>>> https://bugs.openjdk.java.net/browse/JDK-7090826
>>>
>>> The webrev is available here:
>>> http://cr.openjdk.java.net/~mfang/7090826/webrev.00/
>>>
>>> thanks,
>>>
>>> -michael
>>
>


From michael.fang at oracle.com  Mon Dec 16 16:49:13 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 16 Dec 2013 16:49:13 -0800
Subject: <i18n dev> [8] Request for review: 7090826: Newly added codes
 need to be localized into pt_BR in LocaleNames.
In-Reply-To: <52AF9E8C.70302@oracle.com>
References: <52A644EB.6030104@oracle.com> <52A93813.1040808@oracle.com>
	<52AA39D7.2050507@oracle.com> <52AF9E8C.70302@oracle.com>
Message-ID: <52AF9F89.30906@oracle.com>

Thanks Masayoshi for the review!

-michael

On 13?12?16? 04:45 ??, Masayoshi Okutsu wrote:
> Looks good.
>
> Masayoshi
>
> On 12/13/2013 7:33 AM, Michael Fang wrote:
>> Thanks Masayoshi for the review.
>>
>> I have added CS back to LocaleNames_pt.properties file, corrected 
>> LocaleData test related to CS and corrected the CLDR version number, 
>> which is 21.0.1.
>>
>> The new webrev is:
>> http://cr.openjdk.java.net/~mfang/7090826/webrev.01/
>>
>> JPRT build also completed successfully and passed the core testset.
>>
>> thanks,
>>
>> -michael
>>
>> On 13?12?11? 08:14 ??, Masayoshi Okutsu wrote:
>>> src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties:
>>>
>>> Looks like CS (transitionally reserved) has been removed and 
>>> fallback is expected. But CS seems to be still alive in other 
>>> locales according to the 8029239 webrev. I think it should be 
>>> consistent with other locales (either remove CS from all locales or 
>>> keep it in pt).
>>>
>>> test/sun/text/resources/LocaleData:
>>>
>>> +#bug 7090826 pt data updated to CLDR 2.1
>>>
>>> Should the CLDR version be 21?
>>>
>>> Otherwise, the fix looks good to me.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 12/10/2013 7:32 AM, Michael Fang wrote:
>>>> Hi,
>>>>
>>>> Since it's a little bit complicated to review 8029239: jdk8 l10n 
>>>> resource file translation update - localenames, I would like to 
>>>> separate out the Portuguese portion out back to 7090826 Newly added 
>>>> codes need to be localized into pt_BR in LocaleNames.
>>>>
>>>> The Portuguese files are fully generated from CLDR, so it should be 
>>>> relatively easy to review. LocaleNames_pt_BR.properties have been 
>>>> removed as a result since CLDR doesn't have a separate pt_BR.xml 
>>>> file now.
>>>>
>>>> Please help to review the changes for the following CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-7090826
>>>>
>>>> The webrev is available here:
>>>> http://cr.openjdk.java.net/~mfang/7090826/webrev.00/
>>>>
>>>> thanks,
>>>>
>>>> -michael
>>>
>>
>


From naoto.sato at oracle.com  Tue Dec 17 14:40:06 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 17 Dec 2013 14:40:06 -0800
Subject: <i18n dev> [8] Request for review: 8026741: jdk8 l10n resource
 file translation update 5
In-Reply-To: <52953A52.6040704@oracle.com>
References: <52953A52.6040704@oracle.com>
Message-ID: <52B0D2C6.80306@oracle.com>

Looks good to me.

Naoto

On 11/26/13, 4:18 PM, Michael Fang wrote:
> Hi,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8026741
>
> A list of English resource files were sent to translation vendors for
> translation update periodically that's why these l10n resource files
> have been updated.
>
> You do not need to review the translation content. We just need to make
> sure there are no technical issues. Follow up i18n/l10n testing will be
> performed in promotion builds and i18n/l10n bugs will be reported and
> addressed.
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8026741/
>
> thanks,
>
> -michael


From michael.fang at oracle.com  Tue Dec 17 14:37:18 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 17 Dec 2013 14:37:18 -0800
Subject: <i18n dev> [8] Request for review: 8026741: jdk8 l10n resource
 file translation update 5
In-Reply-To: <52B0D2C6.80306@oracle.com>
References: <52953A52.6040704@oracle.com> <52B0D2C6.80306@oracle.com>
Message-ID: <52B0D21E.9060601@oracle.com>

Thank you Naoto for the review.

-michael

On 13?12?17? 02:40 ??, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 11/26/13, 4:18 PM, Michael Fang wrote:
>> Hi,
>>
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-8026741
>>
>> A list of English resource files were sent to translation vendors for
>> translation update periodically that's why these l10n resource files
>> have been updated.
>>
>> You do not need to review the translation content. We just need to make
>> sure there are no technical issues. Follow up i18n/l10n testing will be
>> performed in promotion builds and i18n/l10n bugs will be reported and
>> addressed.
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8026741/
>>
>> thanks,
>>
>> -michael
>


From aleksej.efimov at oracle.com  Wed Dec 18 01:43:47 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 18 Dec 2013 13:43:47 +0400
Subject: <i18n dev> RFR: 8025051: Update resource files for TimeZone display
	names
Message-ID: <52B16E53.7090705@oracle.com>

Hi,

Please help to review a fix [1] for 8025051 bug [2]. The following fix 
includes:
  - The translation of time zone generic names were added to all locales.
  - Time Zone names were updated according to the latest translations.
  - Added tz names regression test 
(test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names 
across all locales. This test compares short/long 
standard/daylight/generic names with translations stored in .properties 
files.
  - Tests updates to address current changes ( 
GenericTimeZoneNamesTest.sh and Bug6317929.java).

The following fix was tested with JPRT build and the 'jdk_util' test set 
succeeded (new test is included in this test set).

[1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
[2] https://bugs.openjdk.java.net/browse/JDK-8025051


From masayoshi.okutsu at oracle.com  Thu Dec 19 00:04:54 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 19 Dec 2013 17:04:54 +0900
Subject: <i18n dev> RFR: 8025051: Update resource files for TimeZone
 display names
In-Reply-To: <52B16E53.7090705@oracle.com>
References: <52B16E53.7090705@oracle.com>
Message-ID: <52B2A8A6.4020903@oracle.com>

On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
> Hi,
>
> Please help to review a fix [1] for 8025051 bug [2]. The following fix 
> includes:

Common to all modified files:
- All year ranges in the copyright header should be modified accordingly.

>  - The translation of time zone generic names were added to all locales.

I haven't fully reviewed translations, especially all \uxxxx strings. 
But I noticed the following.

Common to all TimeZoneNames_*.java:
- The same generic abbreviation is used for the long name in MET. I 
thought this was fixed in the root properties...
- Some generic names don't match the style of their standard and/or 
daylight time names.

src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
- Some generic names use "Normalzeit". Is that OK?

src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
- "Chuuk Time" isn't translated.

>  - Time Zone names were updated according to the latest translations.
>  - Added tz names regression test 
> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names 
> across all locales. This test compares short/long 
> standard/daylight/generic names with translations stored in 
> .properties files.

test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:

- lines 33, 34: unused imports?
- line 75: Should it be detected as an error?
- line 108: IOException should be used as a cause. (OK to assume "not 
found"?)
- lines 118 -121: Locale.getDefault() has to be replaced with 
Locale.ROOT. Regression tests are run in different locales.

>  - Tests updates to address current changes ( 
> GenericTimeZoneNamesTest.sh and Bug6317929.java).

The TODO comment in GenericTimeZoneNamesTest.sh should fully been removed.

>
> The following fix was tested with JPRT build and the 'jdk_util' test 
> set succeeded (new test is included in this test set).

Have you executed all date-time related regression tests (including 
java.time and java.text)?

Thanks,
Masayoshi

>
> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>


From aleksej.efimov at oracle.com  Fri Dec 20 03:39:14 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 20 Dec 2013 15:39:14 +0400
Subject: <i18n dev> RFR: 8025051: Update resource files for TimeZone
 display names
In-Reply-To: <52B2A8A6.4020903@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
Message-ID: <52B42C62.9090603@oracle.com>

Masayoshi,
Thank you for the detailed review and your comments. I tried to address 
all of them. The responses are below. The new webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
<http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/>

Michael,
As Masayoshi mentioned, we have a list of inconsistent translations in 
translation files. I suggest two approaches to resolve it: 1. Log 
different bug with all problems in translation files. 2. Wait for the 
next resource file translation update to address these problems.

-Aleksej

On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>> Hi,
>>
>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>> fix includes:
>
> Common to all modified files:
> - All year ranges in the copyright header should be modified accordingly.

Fixed.

>
>>  - The translation of time zone generic names were added to all locales.
>
> I haven't fully reviewed translations, especially all \uxxxx strings. 
> But I noticed the following.
>
> Common to all TimeZoneNames_*.java:
> - The same generic abbreviation is used for the long name in MET. I 
> thought this was fixed in the root properties...

No, the "MET" is used in root properties both for generic long and short 
names. I will update these names when new translation update will be 
available.

> - Some generic names don't match the style of their standard and/or 
> daylight time names.

The same as previous. This is a first large update for generic names and 
latest translations. All inconsistency in translations will be fixed 
during next translation update.

>
> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
> - Some generic names use "Normalzeit". Is that OK?

It's not good. But the resolution is same as previous two.

>
> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
> - "Chuuk Time" isn't translated.

I think it will be translated in next translations update.

>
>>  - Time Zone names were updated according to the latest translations.
>>  - Added tz names regression test 
>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone names 
>> across all locales. This test compares short/long 
>> standard/daylight/generic names with translations stored in 
>> .properties files.
>
> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>
> - lines 33, 34: unused imports?

Removed

> - line 75: Should it be detected as an error?

Agree, now the test will fail if there is some incorrect entries in the 
test .properties files.

> - line 108: IOException should be used as a cause. (OK to assume "not 
> found"?)

The IOException cause is added. Currently, the test will stop with 
RuntimeException, because the test file is not found.

> - lines 118 -121: Locale.getDefault() has to be replaced with 
> Locale.ROOT. Regression tests are run in different locales.

Thank you for catching this one. Fixed.

>
>>  - Tests updates to address current changes ( 
>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>
> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
> removed.

Removed

>
>>
>> The following fix was tested with JPRT build and the 'jdk_util' test 
>> set succeeded (new test is included in this test set).
>
> Have you executed all date-time related regression tests (including 
> java.time and java.text)?

Yes, I have executed the following set of tests via JTREG:
test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/closed/java/util/TimeZone test/java/util/TimeZone
  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
All tests gave "PASS" results.
Please, let me know if you think that some other tests should be executed.


>
> Thanks,
> Masayoshi
>
>>
>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>
>


From aleksej.efimov at oracle.com  Sun Dec 22 10:14:52 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Sun, 22 Dec 2013 22:14:52 +0400
Subject: <i18n dev> RFR: 8025051: Update resource files for TimeZone
 display names
In-Reply-To: <52B42C62.9090603@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com>
Message-ID: <52B72C1C.8000703@oracle.com>

Hi,
The new version of patch for TimeZone display names update is available. 
Previous webrev contains incorrect naming for Acre timezone generic name 
(ACT[] array) across all non-root locales. The name was corrected and 
test TimeZoneNames_*.properties files were modified accordingly.
The new webrev: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
<http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/>

-Aleksej

On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
> Masayoshi,
> Thank you for the detailed review and your comments. I tried to 
> address all of them. The responses are below. The new webrev can be 
> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
> <http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/>
>
> Michael,
> As Masayoshi mentioned, we have a list of inconsistent translations in 
> translation files. I suggest two approaches to resolve it: 1. Log 
> different bug with all problems in translation files. 2. Wait for the 
> next resource file translation update to address these problems.
>
> -Aleksej
>
> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>> Hi,
>>>
>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>> fix includes:
>>
>> Common to all modified files:
>> - All year ranges in the copyright header should be modified 
>> accordingly.
>
> Fixed.
>
>>
>>>  - The translation of time zone generic names were added to all 
>>> locales.
>>
>> I haven't fully reviewed translations, especially all \uxxxx strings. 
>> But I noticed the following.
>>
>> Common to all TimeZoneNames_*.java:
>> - The same generic abbreviation is used for the long name in MET. I 
>> thought this was fixed in the root properties...
>
> No, the "MET" is used in root properties both for generic long and 
> short names. I will update these names when new translation update 
> will be available.
>
>> - Some generic names don't match the style of their standard and/or 
>> daylight time names.
>
> The same as previous. This is a first large update for generic names 
> and latest translations. All inconsistency in translations will be 
> fixed during next translation update.
>
>>
>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>> - Some generic names use "Normalzeit". Is that OK?
>
> It's not good. But the resolution is same as previous two.
>
>>
>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>> - "Chuuk Time" isn't translated.
>
> I think it will be translated in next translations update.
>
>>
>>>  - Time Zone names were updated according to the latest translations.
>>>  - Added tz names regression test 
>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>> names across all locales. This test compares short/long 
>>> standard/daylight/generic names with translations stored in 
>>> .properties files.
>>
>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>
>> - lines 33, 34: unused imports?
>
> Removed
>
>> - line 75: Should it be detected as an error?
>
> Agree, now the test will fail if there is some incorrect entries in 
> the test .properties files.
>
>> - line 108: IOException should be used as a cause. (OK to assume "not 
>> found"?)
>
> The IOException cause is added. Currently, the test will stop with 
> RuntimeException, because the test file is not found.
>
>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>> Locale.ROOT. Regression tests are run in different locales.
>
> Thank you for catching this one. Fixed.
>
>>
>>>  - Tests updates to address current changes ( 
>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>
>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>> removed.
>
> Removed
>
>>
>>>
>>> The following fix was tested with JPRT build and the 'jdk_util' test 
>>> set succeeded (new test is included in this test set).
>>
>> Have you executed all date-time related regression tests (including 
>> java.time and java.text)?
>
> Yes, I have executed the following set of tests via JTREG:
> test/sun/util/calendar test/java/util/Calendar 
> test/sun/util/resources/TimeZone test/sun/util/calendar 
> test/closed/java/util/TimeZone test/java/util/TimeZone
>  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
> All tests gave "PASS" results.
> Please, let me know if you think that some other tests should be 
> executed.
>
>
>>
>> Thanks,
>> Masayoshi
>>
>>>
>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>
>>
>


From michael.fang at oracle.com  Mon Dec 23 00:54:15 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 23 Dec 2013 00:54:15 -0800
Subject: <i18n dev> [8] Request for review: 8026570: NLS: jdk8 man page
	update
Message-ID: <52B7FA37.8050207@oracle.com>

Hi,

Please help to review the changes for the following CR:
https://bugs.openjdk.java.net/browse/JDK-8026570

The webrev is available here:
http://cr.openjdk.java.net/~mfang/8026570/webrev.00/

The built man page files can be found at:
http://cr.openjdk.java.net/~mfang/8026570/solaris/ja_JP.UTF-8/man1/
http://cr.openjdk.java.net/~mfang/8026570/linux/ja_JP.UTF-8/man1/

The SQE team has tested the man pages and the following issues have been 
reported:
JDK-8030947 jcmd.1 Japanese man page is corrupted after the build
JDK-8030946 No jmc.1 for man page of JMC
.sh "NAME" not translated - hardcoded and not included in the xml source 
file for translation

thanks,

-michael

From michael.fang at oracle.com  Mon Dec 23 21:52:02 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Mon, 23 Dec 2013 21:52:02 -0800
Subject: <i18n dev> RFR: 8025051: Update resource files for TimeZone
 display names
In-Reply-To: <52B72C1C.8000703@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com> <52B72C1C.8000703@oracle.com>
Message-ID: <52B92102.9090201@oracle.com>

Thanks Aleksej for addressing the ACT issue. The l10n files look fine to 
me. I agree that we should work on translation consistency issues 
separately the next time we have a translation cycle.

thanks,

-michael

On 13?12?22? 10:14 ??, Aleksej Efimov wrote:
> Hi,
> The new version of patch for TimeZone display names update is 
> available. Previous webrev contains incorrect naming for Acre timezone 
> generic name (ACT[] array) across all non-root locales. The name was 
> corrected and test TimeZoneNames_*.properties files were modified 
> accordingly.
> The new webrev: 
> http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
> <http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/>
>
> -Aleksej
>
> On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
>> Masayoshi,
>> Thank you for the detailed review and your comments. I tried to 
>> address all of them. The responses are below. The new webrev can be 
>> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/>
>>
>> Michael,
>> As Masayoshi mentioned, we have a list of inconsistent translations 
>> in translation files. I suggest two approaches to resolve it: 1. Log 
>> different bug with all problems in translation files. 2. Wait for the 
>> next resource file translation update to address these problems.
>>
>> -Aleksej
>>
>> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>>
>>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>>> fix includes:
>>>
>>> Common to all modified files:
>>> - All year ranges in the copyright header should be modified 
>>> accordingly.
>>
>> Fixed.
>>
>>>
>>>>  - The translation of time zone generic names were added to all 
>>>> locales.
>>>
>>> I haven't fully reviewed translations, especially all \uxxxx 
>>> strings. But I noticed the following.
>>>
>>> Common to all TimeZoneNames_*.java:
>>> - The same generic abbreviation is used for the long name in MET. I 
>>> thought this was fixed in the root properties...
>>
>> No, the "MET" is used in root properties both for generic long and 
>> short names. I will update these names when new translation update 
>> will be available.
>>
>>> - Some generic names don't match the style of their standard and/or 
>>> daylight time names.
>>
>> The same as previous. This is a first large update for generic names 
>> and latest translations. All inconsistency in translations will be 
>> fixed during next translation update.
>>
>>>
>>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>>> - Some generic names use "Normalzeit". Is that OK?
>>
>> It's not good. But the resolution is same as previous two.
>>
>>>
>>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>>> - "Chuuk Time" isn't translated.
>>
>> I think it will be translated in next translations update.
>>
>>>
>>>>  - Time Zone names were updated according to the latest translations.
>>>>  - Added tz names regression test 
>>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>>> names across all locales. This test compares short/long 
>>>> standard/daylight/generic names with translations stored in 
>>>> .properties files.
>>>
>>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>>
>>> - lines 33, 34: unused imports?
>>
>> Removed
>>
>>> - line 75: Should it be detected as an error?
>>
>> Agree, now the test will fail if there is some incorrect entries in 
>> the test .properties files.
>>
>>> - line 108: IOException should be used as a cause. (OK to assume 
>>> "not found"?)
>>
>> The IOException cause is added. Currently, the test will stop with 
>> RuntimeException, because the test file is not found.
>>
>>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>>> Locale.ROOT. Regression tests are run in different locales.
>>
>> Thank you for catching this one. Fixed.
>>
>>>
>>>>  - Tests updates to address current changes ( 
>>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>>
>>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>>> removed.
>>
>> Removed
>>
>>>
>>>>
>>>> The following fix was tested with JPRT build and the 'jdk_util' 
>>>> test set succeeded (new test is included in this test set).
>>>
>>> Have you executed all date-time related regression tests (including 
>>> java.time and java.text)?
>>
>> Yes, I have executed the following set of tests via JTREG:
>> test/sun/util/calendar test/java/util/Calendar 
>> test/sun/util/resources/TimeZone test/sun/util/calendar 
>> test/closed/java/util/TimeZone test/java/util/TimeZone
>>  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
>> All tests gave "PASS" results.
>> Please, let me know if you think that some other tests should be 
>> executed.
>>
>>
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>>>
>>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>>
>>>
>>
>

From masayoshi.okutsu at oracle.com  Mon Dec 23 22:39:12 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 24 Dec 2013 15:39:12 +0900
Subject: <i18n dev> RFR: 8025051: Update resource files for TimeZone
 display names
In-Reply-To: <52B72C1C.8000703@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com> <52B72C1C.8000703@oracle.com>
Message-ID: <52B92C10.2060008@oracle.com>

Looks good to me.

Masayoshi

On 12/23/2013 3:14 AM, Aleksej Efimov wrote:
> Hi,
> The new version of patch for TimeZone display names update is 
> available. Previous webrev contains incorrect naming for Acre timezone 
> generic name (ACT[] array) across all non-root locales. The name was 
> corrected and test TimeZoneNames_*.properties files were modified 
> accordingly.
> The new webrev: 
> http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
> <http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/>
>
> -Aleksej
>
> On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
>> Masayoshi,
>> Thank you for the detailed review and your comments. I tried to 
>> address all of them. The responses are below. The new webrev can be 
>> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/>
>>
>> Michael,
>> As Masayoshi mentioned, we have a list of inconsistent translations 
>> in translation files. I suggest two approaches to resolve it: 1. Log 
>> different bug with all problems in translation files. 2. Wait for the 
>> next resource file translation update to address these problems.
>>
>> -Aleksej
>>
>> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>>
>>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>>> fix includes:
>>>
>>> Common to all modified files:
>>> - All year ranges in the copyright header should be modified 
>>> accordingly.
>>
>> Fixed.
>>
>>>
>>>>  - The translation of time zone generic names were added to all 
>>>> locales.
>>>
>>> I haven't fully reviewed translations, especially all \uxxxx 
>>> strings. But I noticed the following.
>>>
>>> Common to all TimeZoneNames_*.java:
>>> - The same generic abbreviation is used for the long name in MET. I 
>>> thought this was fixed in the root properties...
>>
>> No, the "MET" is used in root properties both for generic long and 
>> short names. I will update these names when new translation update 
>> will be available.
>>
>>> - Some generic names don't match the style of their standard and/or 
>>> daylight time names.
>>
>> The same as previous. This is a first large update for generic names 
>> and latest translations. All inconsistency in translations will be 
>> fixed during next translation update.
>>
>>>
>>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>>> - Some generic names use "Normalzeit". Is that OK?
>>
>> It's not good. But the resolution is same as previous two.
>>
>>>
>>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>>> - "Chuuk Time" isn't translated.
>>
>> I think it will be translated in next translations update.
>>
>>>
>>>>  - Time Zone names were updated according to the latest translations.
>>>>  - Added tz names regression test 
>>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>>> names across all locales. This test compares short/long 
>>>> standard/daylight/generic names with translations stored in 
>>>> .properties files.
>>>
>>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>>
>>> - lines 33, 34: unused imports?
>>
>> Removed
>>
>>> - line 75: Should it be detected as an error?
>>
>> Agree, now the test will fail if there is some incorrect entries in 
>> the test .properties files.
>>
>>> - line 108: IOException should be used as a cause. (OK to assume 
>>> "not found"?)
>>
>> The IOException cause is added. Currently, the test will stop with 
>> RuntimeException, because the test file is not found.
>>
>>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>>> Locale.ROOT. Regression tests are run in different locales.
>>
>> Thank you for catching this one. Fixed.
>>
>>>
>>>>  - Tests updates to address current changes ( 
>>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>>
>>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>>> removed.
>>
>> Removed
>>
>>>
>>>>
>>>> The following fix was tested with JPRT build and the 'jdk_util' 
>>>> test set succeeded (new test is included in this test set).
>>>
>>> Have you executed all date-time related regression tests (including 
>>> java.time and java.text)?
>>
>> Yes, I have executed the following set of tests via JTREG:
>> test/sun/util/calendar test/java/util/Calendar 
>> test/sun/util/resources/TimeZone test/sun/util/calendar 
>> test/closed/java/util/TimeZone test/java/util/TimeZone
>>  test/java/time  test/java/util/Formatter test/closed/java/util/Calendar
>> All tests gave "PASS" results.
>> Please, let me know if you think that some other tests should be 
>> executed.
>>
>>
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>>>
>>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Tue Dec 24 01:06:04 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 24 Dec 2013 18:06:04 +0900
Subject: <i18n dev> [8] Request for review: 8026570: NLS: jdk8 man page
 update
In-Reply-To: <52B7FA37.8050207@oracle.com>
References: <52B7FA37.8050207@oracle.com>
Message-ID: <52B94E7C.3000207@oracle.com>

Looks like all spaces between English words and Japanese characters have 
been removed. Why is that?

I checked (OS native) man pages in Japanese on Solaris and Linux. They 
have spaces. I do prefer to have spaces.

Thanks,
Masayoshi

On 12/23/2013 5:54 PM, Michael Fang wrote:
> Hi,
>
> Please help to review the changes for the following CR:
> https://bugs.openjdk.java.net/browse/JDK-8026570
>
> The webrev is available here:
> http://cr.openjdk.java.net/~mfang/8026570/webrev.00/
>
> The built man page files can be found at:
> http://cr.openjdk.java.net/~mfang/8026570/solaris/ja_JP.UTF-8/man1/
> http://cr.openjdk.java.net/~mfang/8026570/linux/ja_JP.UTF-8/man1/
>
> The SQE team has tested the man pages and the following issues have 
> been reported:
> JDK-8030947 jcmd.1 Japanese man page is corrupted after the build
> JDK-8030946 No jmc.1 for man page of JMC
> .sh "NAME" not translated - hardcoded and not included in the xml 
> source file for translation
>
> thanks,
>
> -michael


From aleksej.efimov at oracle.com  Tue Dec 24 05:21:23 2013
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 24 Dec 2013 17:21:23 +0400
Subject: <i18n dev> RFR: 8025051: Update resource files for TimeZone
 display names
In-Reply-To: <52B92C10.2060008@oracle.com>
References: <52B16E53.7090705@oracle.com> <52B2A8A6.4020903@oracle.com>
	<52B42C62.9090603@oracle.com> <52B72C1C.8000703@oracle.com>
	<52B92C10.2060008@oracle.com>
Message-ID: <52B98A53.4020408@oracle.com>

Masayoshi, Michael,
Many thanks for reviewing this fix and for all your comments.

Can I ask someone for a JDK8 commit sponsorship? The hg export is 
located here: 
http://cr.openjdk.java.net/~aefimov/8025051/8/8025051_jdk8.patch

Also, I want to take this opportunity and wish a Merry Christmas and 
Happy New Year to all OpenJDK community members (at least members who 
read this letter :) ).

-Aleksej

On 12/24/2013 10:39 AM, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
> On 12/23/2013 3:14 AM, Aleksej Efimov wrote:
>> Hi,
>> The new version of patch for TimeZone display names update is 
>> available. Previous webrev contains incorrect naming for Acre 
>> timezone generic name (ACT[] array) across all non-root locales. The 
>> name was corrected and test TimeZoneNames_*.properties files were 
>> modified accordingly.
>> The new webrev: 
>> http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.02/ 
>> <http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.02/>
>>
>> -Aleksej
>>
>> On 12/20/2013 03:39 PM, Aleksej Efimov wrote:
>>> Masayoshi,
>>> Thank you for the detailed review and your comments. I tried to 
>>> address all of them. The responses are below. The new webrev can be 
>>> found here: http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Eaefimov/8025051/8/webrev.01/>
>>>
>>> Michael,
>>> As Masayoshi mentioned, we have a list of inconsistent translations 
>>> in translation files. I suggest two approaches to resolve it: 1. Log 
>>> different bug with all problems in translation files. 2. Wait for 
>>> the next resource file translation update to address these problems.
>>>
>>> -Aleksej
>>>
>>> On 12/19/2013 12:04 PM, Masayoshi Okutsu wrote:
>>>> On 12/18/2013 6:43 PM, Aleksej Efimov wrote:
>>>>> Hi,
>>>>>
>>>>> Please help to review a fix [1] for 8025051 bug [2]. The following 
>>>>> fix includes:
>>>>
>>>> Common to all modified files:
>>>> - All year ranges in the copyright header should be modified 
>>>> accordingly.
>>>
>>> Fixed.
>>>
>>>>
>>>>>  - The translation of time zone generic names were added to all 
>>>>> locales.
>>>>
>>>> I haven't fully reviewed translations, especially all \uxxxx 
>>>> strings. But I noticed the following.
>>>>
>>>> Common to all TimeZoneNames_*.java:
>>>> - The same generic abbreviation is used for the long name in MET. I 
>>>> thought this was fixed in the root properties...
>>>
>>> No, the "MET" is used in root properties both for generic long and 
>>> short names. I will update these names when new translation update 
>>> will be available.
>>>
>>>> - Some generic names don't match the style of their standard and/or 
>>>> daylight time names.
>>>
>>> The same as previous. This is a first large update for generic names 
>>> and latest translations. All inconsistency in translations will be 
>>> fixed during next translation update.
>>>
>>>>
>>>> src/share/classes/sun/util/resources/de/TimeZoneNames_de.java:
>>>> - Some generic names use "Normalzeit". Is that OK?
>>>
>>> It's not good. But the resolution is same as previous two.
>>>
>>>>
>>>> src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java:
>>>> - "Chuuk Time" isn't translated.
>>>
>>> I think it will be translated in next translations update.
>>>
>>>>
>>>>>  - Time Zone names were updated according to the latest translations.
>>>>>  - Added tz names regression test 
>>>>> (test/sun/util/resources/TimeZone/TimeZoneNames) for a timezone 
>>>>> names across all locales. This test compares short/long 
>>>>> standard/daylight/generic names with translations stored in 
>>>>> .properties files.
>>>>
>>>> test/sun/util/resources/TimeZone/TimeZoneNames/TimeZoneNamesTest.java:
>>>>
>>>> - lines 33, 34: unused imports?
>>>
>>> Removed
>>>
>>>> - line 75: Should it be detected as an error?
>>>
>>> Agree, now the test will fail if there is some incorrect entries in 
>>> the test .properties files.
>>>
>>>> - line 108: IOException should be used as a cause. (OK to assume 
>>>> "not found"?)
>>>
>>> The IOException cause is added. Currently, the test will stop with 
>>> RuntimeException, because the test file is not found.
>>>
>>>> - lines 118 -121: Locale.getDefault() has to be replaced with 
>>>> Locale.ROOT. Regression tests are run in different locales.
>>>
>>> Thank you for catching this one. Fixed.
>>>
>>>>
>>>>>  - Tests updates to address current changes ( 
>>>>> GenericTimeZoneNamesTest.sh and Bug6317929.java).
>>>>
>>>> The TODO comment in GenericTimeZoneNamesTest.sh should fully been 
>>>> removed.
>>>
>>> Removed
>>>
>>>>
>>>>>
>>>>> The following fix was tested with JPRT build and the 'jdk_util' 
>>>>> test set succeeded (new test is included in this test set).
>>>>
>>>> Have you executed all date-time related regression tests (including 
>>>> java.time and java.text)?
>>>
>>> Yes, I have executed the following set of tests via JTREG:
>>> test/sun/util/calendar test/java/util/Calendar 
>>> test/sun/util/resources/TimeZone test/sun/util/calendar 
>>> test/closed/java/util/TimeZone test/java/util/TimeZone
>>>  test/java/time  test/java/util/Formatter 
>>> test/closed/java/util/Calendar
>>> All tests gave "PASS" results.
>>> Please, let me know if you think that some other tests should be 
>>> executed.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>>>
>>>>> [1] http://cr.openjdk.java.net/~aefimov/8025051/8/webrev.00/
>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8025051
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Tue Dec 24 10:02:55 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 24 Dec 2013 10:02:55 -0800
Subject: <i18n dev> [8] Request for review: 8026570: NLS: jdk8 man page
 update
In-Reply-To: <52B94E7C.3000207@oracle.com>
References: <52B7FA37.8050207@oracle.com> <52B94E7C.3000207@oracle.com>
Message-ID: <52B9CC4F.40109@oracle.com>

Also, I would like to at least find out why the man page is corrupt 
before the push.

Naoto

On 12/24/13, 1:06 AM, Masayoshi Okutsu wrote:
> Looks like all spaces between English words and Japanese characters have
> been removed. Why is that?
>
> I checked (OS native) man pages in Japanese on Solaris and Linux. They
> have spaces. I do prefer to have spaces.
>
> Thanks,
> Masayoshi
>
> On 12/23/2013 5:54 PM, Michael Fang wrote:
>> Hi,
>>
>> Please help to review the changes for the following CR:
>> https://bugs.openjdk.java.net/browse/JDK-8026570
>>
>> The webrev is available here:
>> http://cr.openjdk.java.net/~mfang/8026570/webrev.00/
>>
>> The built man page files can be found at:
>> http://cr.openjdk.java.net/~mfang/8026570/solaris/ja_JP.UTF-8/man1/
>> http://cr.openjdk.java.net/~mfang/8026570/linux/ja_JP.UTF-8/man1/
>>
>> The SQE team has tested the man pages and the following issues have
>> been reported:
>> JDK-8030947 jcmd.1 Japanese man page is corrupted after the build
>> JDK-8030946 No jmc.1 for man page of JMC
>> .sh "NAME" not translated - hardcoded and not included in the xml
>> source file for translation
>>
>> thanks,
>>
>> -michael
>


From michael.fang at oracle.com  Tue Dec 24 11:15:20 2013
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 24 Dec 2013 11:15:20 -0800
Subject: <i18n dev> [8] Request for review: 8026570: NLS: jdk8 man page
 update
In-Reply-To: <52B9CC4F.40109@oracle.com>
References: <52B7FA37.8050207@oracle.com> <52B94E7C.3000207@oracle.com>
	<52B9CC4F.40109@oracle.com>
Message-ID: <52B9DD48.9010909@oracle.com>

Thank you Masayoshi and Naoto for looking into it.

About the missing space, unfortunately, this is a "feature" of the 
translation system. It's out of my control. I received the following 
from translation team when copyright line was causing conversion error:

When we translate the statement, "Copyright (c) xxxx, xxxx, Oracle 
and&sol;or its affiliates. All rights reserved.", each single sentence 
is handled as translatable string segment, then stored into Repository 
as they are. However, when the Japanese contents are rebuild, the spaces 
between two sentences are removed because these are also treated as 
Japanese strings. In general, no space is required between multiple 
sentences in Japanese, so this feature is implemented in the current system.

About the corruption of jcmd.1, in the current promotion, Japanese 
jcmd.1 has size 0 as well. It's not a regression, but something still to 
be investigated.

thanks,

-michael

On 13?12?24? 10:02 ??, Naoto Sato wrote:
> Also, I would like to at least find out why the man page is corrupt 
> before the push.
>
> Naoto
>
> On 12/24/13, 1:06 AM, Masayoshi Okutsu wrote:
>> Looks like all spaces between English words and Japanese characters have
>> been removed. Why is that?
>>
>> I checked (OS native) man pages in Japanese on Solaris and Linux. They
>> have spaces. I do prefer to have spaces.
>>
>> Thanks,
>> Masayoshi
>>
>> On 12/23/2013 5:54 PM, Michael Fang wrote:
>>> Hi,
>>>
>>> Please help to review the changes for the following CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8026570
>>>
>>> The webrev is available here:
>>> http://cr.openjdk.java.net/~mfang/8026570/webrev.00/
>>>
>>> The built man page files can be found at:
>>> http://cr.openjdk.java.net/~mfang/8026570/solaris/ja_JP.UTF-8/man1/
>>> http://cr.openjdk.java.net/~mfang/8026570/linux/ja_JP.UTF-8/man1/
>>>
>>> The SQE team has tested the man pages and the following issues have
>>> been reported:
>>> JDK-8030947 jcmd.1 Japanese man page is corrupted after the build
>>> JDK-8030946 No jmc.1 for man page of JMC
>>> .sh "NAME" not translated - hardcoded and not included in the xml
>>> source file for translation
>>>
>>> thanks,
>>>
>>> -michael
>>
>