<i18n dev> RFR: [8u] JDK-8218781: Localized names for Japanese Era Reiwa in COMPAT provider

[Steven R. Loomis]

[Resend from the correct address…]

Hi all,

For what it’s worth,
 CLDR itself doesn’t usually ‘backport’ data. (So there’s no CLDR source for such a backport.) I don’t know if CLDR has ever released a dot release for a release past the last released major version.


  FYI, For ICU, what we did (for a large number of releases) is a very specific spot fix of the locale data.

- icu4j changes for 56.2 including binary data locale blob change: https://github.com/unicode-org/icu/commit/b5999f7e7fa54c4f0fb9e9cd5e80095bb27eea32 <https://github.com/unicode-org/icu/commit/b5999f7e7fa54c4f0fb9e9cd5e80095bb27eea32>
- icu4c changes for 56.2 including textual changes to the intermediate format: https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43 <https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43> 

Example: 
 https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43#diff-2990754f360524737be2791c1ab20e94R2384 <https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43#diff-2990754f360524737be2791c1ab20e94R2384> ( change for Japanese )


--
Steven R. Loomis | @srl295 | git.io/srl295



> El jul. 5, 2019, a las 10:49 a. m., Andrew John Hughes <gnu.andrew at redhat.com> escribió:
> 
> 
> 
> On 05/07/2019 17:52, Severin Gehwolf wrote:
>> Hi Andrew,
>> 
>> On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218781
>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/
>>> 
>>> OpenJDK 8u uses an older version of the CLDR data to 9, and is thus
>>> missing a number of locale data files updated by the original version of
>>> 8218781. Thus, some chunks are absent from the 8u backport.
>> 
>> Ugh, the JDK 13 fix got pushed via 8219781 :( No wonder I wasn't
>> finding anything.
>> 
> 
> Ah, so it wasn't a typo on my part in 8u.
> 
>> Hmm, there is no COMPAT provider in JDK 8u. That's JDK 9 onwards. See:
>> https://bugs.openjdk.java.net/browse/JDK-8062006
>> 
>> In JDK 8u -Djava.locale.providers=COMPAT (as used in the test[1]) will
>> result in the default list, which is JRE,SPI as far as I can see.
>> 
> 
> Yes, it's effectively redundant. I guess we could remove it but it then
> creates divergence.
> 
>>> In most cases, this actually makes no difference in testing, because the
>>> locale data files for hr, in, lt, nl and sv simply duplicate the English
>>> values. Thus, the only ones that fail the test are no (uses a short era
>>> of "R") and sr_Latn ("Reiva").
>> 
>> Right, but why intentionally introduce test failures? I'm worried about
>> signal vs. noise here.
>> 
>>> I propose that we apply 8218781 for the locales we have now, and look at
>>> backporting updated CLDR data for 8u232 or 8u242. The updates -
>>> primarily JDK-8008577 - are tied up with configuration changes which we
>>> don't want to import to 8, so a backport will require some work and
>>> significant testing.
>>> 
>>> In short, please review this patch, taking into consideration that some
>>> locales will be absent and that data is duplicated for others
>>> (JDK-8159943, not in 8u, makes the short and long eras use a shared
>>> variable where they are identical)
>> 
>> Have you considered something like this patch so as to avoid the test
>> failures and then re-enable them once a fix comes in?
>> 
> 
> That seems like a good way to make sure it doesn't get fixed.
> 
>> diff --git a/test/java/util/Calendar/JapanEraNameCompatTest.java b/test/java/util/Calendar/JapanEraNameCompatTest.java
>> --- a/test/java/util/Calendar/JapanEraNameCompatTest.java
>> +++ b/test/java/util/Calendar/JapanEraNameCompatTest.java
>> @@ -96,12 +96,12 @@
>>             { new Locale("hi", "IN"), HindiName, HindiName },
>>             { new Locale("ru"), RussianName, RussianName },
>>             { new Locale("sr"), SerbianName, SerbianName },
>> -            { Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
>> +            //{ Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
>>             { new Locale("hr"), EngName, EngName },
>>             { new Locale("in"), EngName, EngName },
>>             { new Locale("lt"), EngName, EngName },
>>             { new Locale("nl"), EngName, EngName },
>> -            { new Locale("no"), EngName, "R" },
>> +            //{ new Locale("no"), EngName, "R" },
>>             { new Locale("sv"), EngName, EngName },
>>             // el fallback to root
>>             { new Locale("el"), EngName, EngName }
>> 
>> This would make it more apparent that it's intentional. Perhaps filing
>> a bug that it's not a complete fix would be even better. Thoughts?
>> 
> 
> As I said, the intention is to look at the viability of backporting the
> updated CLDR data. There are already bugs for that.
> 
>> Thanks,
>> Severin
>> 
>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/35818757a9c6/test/java/util/Calendar/JapanEraNameCompatTest.java#l29
>> 
> 
> -- 
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> https://keybase.io/gnu_andrew
>