Greetings!
I recently added dino to Fedora, and rpmlint seems unhappy with the locale in the package:
dino.x86_64: E: incorrect-locale-subdir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-openpgp.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino.mo
The upstream locale is zh_Hans, which has similar error messages. I know very little about this topic - could someone enlighten me about what is upsetting wrong here?
On 14/02/2019 15:41, Randy Barlow wrote:
I recently added dino to Fedora, and rpmlint seems unhappy with the locale in the package:
dino.x86_64: E: incorrect-locale-subdir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-openpgp.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino.mo
The upstream locale is zh_Hans, which has similar error messages. I know very little about this topic - could someone enlighten me about what is upsetting wrong here?
It's not a fully specified locale but it's not wrong either. Per the CLDR likely subtag rules it would expand to zh_Hans_CN.
It specifies simplified chinese without any specific country being targeted - so it's the equivalent of en compared to en_US say.
Technically en_Latn would a closer equivalent but nobody ever bothers to specify a script for english because there is only one option whereas chinese has several so it is normal to add either the script or the country or both.
Tom
On Thu, 2019-02-14 at 15:53 +0000, Tom Hughes wrote:
It's not a fully specified locale but it's not wrong either. Per the CLDR likely subtag rules it would expand to zh_Hans_CN.
It specifies simplified chinese without any specific country being targeted - so it's the equivalent of en compared to en_US say.
Thanks for the explanation!
Would you recommend just letting it be, or would you recommend adding the _CN to the end?
On 14/02/2019 15:58, Randy Barlow wrote:
On Thu, 2019-02-14 at 15:53 +0000, Tom Hughes wrote:
It's not a fully specified locale but it's not wrong either. Per the CLDR likely subtag rules it would expand to zh_Hans_CN.
It specifies simplified chinese without any specific country being targeted - so it's the equivalent of en compared to en_US say.
Thanks for the explanation!
Would you recommend just letting it be, or would you recommend adding the _CN to the end?
I'm not sure there's a clear answer to that - it would depend on things like the logic used whatever has to match user locales to those directories and whether it really is "as in china" data or not - there are other countries where simplified chinese is the default script for chinese.
Tom
On 14/02/2019 20:20, Florian Weimer wrote:
- Tom Hughes:
It's not a fully specified locale but it's not wrong either. Per the CLDR likely subtag rules it would expand to zh_Hans_CN.
zh_Hans_CN or zh-Hans_CN?
Well I think that depends on the system parsing the name and which standard if any it's following as there are some differences between unicode and RFCs on that I think.
Looking at /usr/share/locales it seems to be underscore for both?
Tom
* Tom Hughes:
On 14/02/2019 20:20, Florian Weimer wrote:
- Tom Hughes:
It's not a fully specified locale but it's not wrong either. Per the CLDR likely subtag rules it would expand to zh_Hans_CN.
zh_Hans_CN or zh-Hans_CN?
Well I think that depends on the system parsing the name and which standard if any it's following as there are some differences between unicode and RFCs on that I think.
Looking at /usr/share/locales it seems to be underscore for both?
I actually see empty directories with dashes there on Fedora 29, and dashes seems to be what Microsoft uses, too.
Any reason not to use the more standard glibc locale name: zh_CN? I don't think glibc (or gettext) knows about zh_Hans, let alone zh-Hans.
I think what Tom says is basically correct: zh-Hans is a CLDR locale name.
Jens
On Thu, Feb 14, 2019 at 11:42 PM Randy Barlow bowlofeggs@fedoraproject.org wrote:
I recently added dino to Fedora, and rpmlint seems unhappy with the locale in the package:
dino.x86_64: E: incorrect-locale-subdir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino-openpgp.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh-Hans/LC_MESSAGES/dino.mo
The upstream locale is zh_Hans, which has similar error messages. I know very little about this topic - could someone enlighten me about what is upsetting wrong here?
I think "zh_CN" is specified by ISO 639-1 and ISO 3166-1, and "zh-Hans" is used mainly in Unicode CLDR.
The default locale for Simplified Chinese is "zh_CN.UTF-8".
When gettext or glibc lookup the locale data, it will do some conversion to match from "zh_CN.UTF-8" locale to "zh_CN".
But I suspect gettext or glibc can't match from "zh_CN.UTF-8" to "zh- Hans".
Peng
在 2019-02-15 的 15:13 +0800，Jens-Ulrik Petersen写道：
Any reason not to use the more standard glibc locale name: zh_CN? I don't think glibc (or gettext) knows about zh_Hans, let alone zh- Hans.
I think what Tom says is basically correct: zh-Hans is a CLDR locale name.
Jens
On Thu, Feb 14, 2019 at 11:42 PM Randy Barlow < bowlofeggs@fedoraproject.org> wrote:
I recently added dino to Fedora, and rpmlint seems unhappy with the locale in the package:
dino.x86_64: E: incorrect-locale-subdir /usr/share/locale/zh- Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh- Hans/LC_MESSAGES/dino-omemo.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh- Hans/LC_MESSAGES/dino-openpgp.mo dino.x86_64: E: invalid-lc-messages-dir /usr/share/locale/zh- Hans/LC_MESSAGES/dino.mo
The upstream locale is zh_Hans, which has similar error messages. I know very little about this topic - could someone enlighten me about what is upsetting wrong here?
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
I have filed an upstream ticket about this, in case anyone is interested in participating there:
-
Florian Weimer -
Jens-Ulrik Petersen -
Peng Wu -
Randy Barlow -
Tom Hughes