public inbox for libc-locales@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Jean-Baptiste Holcroft <jean-baptiste@holcroft.fr>
Cc: libc-alpha@sourceware.org,  libc-locales@sourceware.org
Subject: Re: Language code changes over time: zh_CN -> zh_Hans
Date: Thu, 10 Oct 2019 16:25:00 -0000	[thread overview]
Message-ID: <87lftsmuug.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <9c492c49060a079cf36b28269ea2a981@holcroft.fr> (Jean-Baptiste Holcroft's message of "Thu, 10 Oct 2019 17:22:47 +0200")

* Jean-Baptiste Holcroft:

> the Fedora community is migrating to the Weblate translation platform.
> This translation platform uses zh_Hans, zh_Hant, zh_Hant_HK by
> default, instead of zh_CN, zh_TW and zh_HK.

Is zh_Hant_HK perhaps a typo?  Written as-is, that's going to be
problematic.  We had some bugs specific to the eo locale because its
name does not have an underscore in it.

I'm not sure if the language tag syntax is actually compatible with our
locale names.  For example, we write sr-Latn-RS (mentioned in RFC 5646)
as sr_RS@latin.

We have an aliasing mechanism, so we don't need to store the locale data
several times over, so that part shouldn't be a problem.

> If I understand correctly, we need to make sure the language code
> exists in glibc before deciding using the new code for Linux
> applications.
>
> The issue is as follow: a translation platform can be used by many
> projects, not all using glibc, like Websites or mobile application who
> already are using the new code.
>
> The web tells that the codes zh_CN, zh_TW, zh_HK are old codes and
> should be replaced by the new ones.
> Multiple sources tends to confirm this (and show that other actors
> already did the move), the most relevant ones are:
> https://www.w3.org/TR/i18n-html-tech-lang/#h2_langvalues

This says:

| Where possible, use the codes zh-Hans and zh-Hant to refer to Simplified
| and Traditional Chinese, respectively. more...

And the “more...” link goes to:

<https://www.w3.org/International/articles/language-tags/Overview.var#script>

which is dead.  This isn't very reassuring.

> What is the support status of these new language codes in Glibc?
> If not supported, can we imagine to have backward compatibility while
> upstream projects migrate to the new language code?
> I assume these are not the only language code renaming, what policy do
> you suggest concerning these?

We must have renamed language codes in the past, but I don't remember
any examples.  Mostly we hadn't 1:1 replacements, but transitions due to
changing political circumstances.  There were also some language codes
which were completely wrong.

Thanks,
Florian

  reply	other threads:[~2019-10-10 16:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10 15:22 Jean-Baptiste Holcroft
2019-10-10 16:25 ` Florian Weimer [this message]
2019-10-11 20:27   ` Mike FABIAN
2019-10-10 20:53 ` Carlos O'Donell
2019-10-11 20:41 ` Mike FABIAN
2019-10-12  9:35   ` Jean-Baptiste
2019-10-12 13:52     ` Mike FABIAN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lftsmuug.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=jean-baptiste@holcroft.fr \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-locales@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).