<i18n dev> Turkish Time Zone name string and translation

[naoto.sato at oracle.com]

I should have been clearer, but the bug seems to be in the JDK tool 
which converts CLDR's xml into JDK's resource bundles. I implemented the 
CLDR's time zone names fallback spec with 
https://bugs.openjdk.java.net/browse/JDK-8181157, but again there seems 
to be a bug in the code.

Filed a JDK bug: https://bugs.openjdk.java.net/browse/JDK-8234347

Naoto

On 11/18/19 9:08 AM, Mark Davis ☕️ wrote:
> Could you file a ticket at
> https://unicode-org.atlassian.net/ ?
> 
> {phone}
> 
> On Mon, Nov 18, 2019, 16:02 <naoto.sato at oracle.com 
> <mailto:naoto.sato at oracle.com>> wrote:
> 
>     Thanks, Mark.
> 
>     Apparently there seems to be a bug in CLDR converter code, which cannot
>     generate the localized names for "Turkey" metazone. Thus the localized
>     names from the legacy COMPAT locale data are being used. I will look
>     into it.
> 
>     Apart from this, what Letu found out stands by itself as a bug in
>     COMPAT
>     provider.
> 
>     Naoto
> 
>     On 11/17/19 11:16 PM, Mark Davis ☕️ wrote:
>      > You'd have to look at the spec. For most names a pattern plus the
>      > country name is used. That can be overridden with a non-composed
>     name
>      > where needed.
>      >
>      > {phone}
>      >
>      > On Sun, Nov 17, 2019, 21:50 Martin Buchholz <martinrb at google.com
>     <mailto:martinrb at google.com>
>      > <mailto:martinrb at google.com <mailto:martinrb at google.com>>> wrote:
>      >
>      >     I've always wondered how the timezone-related translations
>     are managed.
>      >     CLDR seems to be the master repository of such data, and
>     projects like
>      >     OpenJDK are simply supposed to import that data.
>      >     But I looked at the CLDR sources, and there doesn't seem to
>     be any
>      >     "Turkey
>      >     Time" strings defined like there are for e.g. Turkmenistan.
>      >     Maybe that work never got done?
>      >
>      >     On Sat, Nov 16, 2019 at 6:44 AM <naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com>
>      >     <mailto:naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com>>> wrote:
>      >
>      >      > Letu,
>      >      >
>      >      > Please go ahead and fix the issue in English resource. As
>     to the
>      >      > translation, Oracle l10n will translate it in appropriate
>     locales.
>      >      >
>      >      > Naoto
>      >      >
>      >      > On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >      > > Hi Naoto
>      >      > >
>      >      > > Thank you for the quick response! We will file a ticket
>     later
>      >     today.
>      >      > >
>      >      > > Shall we make an effort on fixing and translating the
>     strings,
>      >     or you
>      >      > > prefer to take care of it at Oracle?
>      >      > >
>      >      > > Letu
>      >      > >
>      >      > > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com
>     <mailto:naoto.sato at oracle.com>
>      >     <mailto:naoto.sato at oracle.com <mailto:naoto.sato at oracle.com>>
>     wrote:
>      >      > > Hi Letu,
>      >      > >
>      >      > > Please file a JBS issue for this (component: core-libs,
>      >     subcomponent:
>      >      > > java.util:i18n).
>      >      > >
>      >      > > Naoto
>      >      > >
>      >      > > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >      > >> Hi,
>      >      > >>
>      >      > >> We recently found an issue with the Time Zone name for
>      >      > “Europe/Istanbul” and "Asian/Istanbul". Since Turkey moved to
>      >     their own
>      >      > Turkish Time (TRT) zone in 2016, although the tzdata had been
>      >     updated, the
>      >      > Time Zone name string has not been updated yet:
>      >      > >>
>      >      > >>
>      >      >
>      >
>     https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >      > >>
>      >      > >> It still returns "Eastern European Time" for the
>      >      > TimeZone.getDisplayName call, which has a summer time while
>      >     Turkish Time
>      >      > does not. An entry for TRT need to be added to this file, and
>      >     assign to
>      >      > both "Europe/Istanbul" and "Asian/Istanbul". This also
>     need to
>      >     be updated
>      >      > for other locales. I can create a JBS issue for this, but I
>      >      > > am not sure whether we should fix this bug, or there is
>     an existing
>      >      > > procedure for this kind of bug which requires language
>     translation.
>      >      > >>
>      >      > >> Letu
>      >      > >>
>      >      > >>
>      >      > >>
>      >      >
>      >
>