Why does Weblate use zh_Hans and zh_Hant instead of zh_CN and zh_TW like everyone else?

[Wuzzy2]

For Chinese translations, I have seen many applications use zh_CN and zh_TW for like forever. Including Weblate.

But a while ago, that seemed to have changed in Weblate, introducing zh_Hans and zh_Hant. I know what they mean (language + script code), but I don't understand the switch, after the first two identifiers have worked for years with no issue. (Or did they? I'm not a Chinese speaker.)

Why did the switch happen?

The reason I ask this is because this seems to introduce an error in Gettext PO files. Weblate inserts zh_Hans and zh_Hant into the Language: header of PO files but technically, this syntax does not seem to be allowed there: https://www.gnu.org/software/gettext/manual/html_node/Header-Entry.html

[nijel]

Why does gettext still use zh_CN and zh_TW while everybody else is using IETF BCP 47 language tags zh_Hans and zh_Hant?

Using country classifiers (CN and TW) is wrong, because the language is actually Chinese written in traditional or simplified Han script (that's where the Han*t* and Han*s* come from).

Traditional script is used in Taiwan, Hong Kong, and Macau, so using zh_TW makes it wrong for many users. If you really want a translation focused on Taiwan, the correct name is zh_Hant_TW.

[Wuzzy2]

OK, that explain the decision. Makes sense. Gettext indeed does not use BCP 47, and the syntax <lang>_<script> does not seem to be officially supported. I suppose this is related to legacy cruft.

Looks like the year-old practice I have seen in so many softwares has been wrong for ages. Even Weblate followed this practice for quite some time IIRC. (I wonder, have you talked to other software projects about this common (but wrong) practice?)

So the problem still remains that zh_Hans in Gettext PO Language: header still technically is a syntax error.

In Gettext headers, officially supported values for Language: are: <lang>, <lang>_<country> and <lang>_<country>@<variant>. So how to code BCP 47 zh_Hans in Gettext correctly?

Thankfully, the manual states that <variant> may be a script. Annoyingly, there is no <lang>@<variant>, so looks like we're forced to add a country. But ISO permits some custom country codes like ZZ, which are for custom use.

I think zh_Hans in Gettext PO headers could be legally coded as zh_ZZ@Hans, where ZZ is just a dummy country code that we interpret as "no country specified" for our use. Yes, this is incompatible with BCP 47, but Gettext doesn't follow it anyway and I doubt it will change anytime soon due to backwards-compatibility.

[Wuzzy2]

Oh noes, I just noticed there is another problem. The manual says the variant must be in lowercase, too. :-(

[nijel]

You can use zh_CN in a gettext application, and it will work just fine in Weblate, you don't have to conform to Weblate naming of locales. See https://docs.weblate.org/en/latest/admin/languages.html#parsing-language-codes