<i18n dev> RFR: 8025051: Update resource files for TimeZone display names

[Aleksej Efimov]

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
>>>
>>
>