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.s...@oracle.com
<mailto:naoto.s...@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 <marti...@google.com
<mailto:marti...@google.com>
> <mailto:marti...@google.com <mailto:marti...@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.s...@oracle.com
<mailto:naoto.s...@oracle.com>
> <mailto:naoto.s...@oracle.com
<mailto:naoto.s...@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.s...@oracle.com
<mailto:naoto.s...@oracle.com>
> <mailto:naoto.s...@oracle.com <mailto:naoto.s...@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
> > >>
> > >>
> > >>
> >
>
