incorrect localization type for chinese

[XhstormR]

I noticed the Chinese locale files in uutils/coreutils-l10n are currently named:

• zh-Hans.ftl
• zh-Hant.ftl

This causes a practical problem on Linux/Unix systems: when users set locale environment variables in the usual way, for example:

export LANG='zh_CN.UTF-8'

the Chinese localization does not take effect, because the locale name does not match the file naming.

Currently, for Simplified Chinese the LANG environment variable coreutils-l10n uses zh-Hans, while fish-shell uses zh_CN.

This is also reflected in fish shell documentation for LANG:
https://fishshell.com/docs/current/language.html#envvar-LANG

Suggested change

Please consider renaming:

locales/zh-Hans.ftl -> locales/zh_CN.ftl
locales/zh-Hant.ftl -> locales/zh_TW.ftl

This would better match common Unix/Linux locale conventions, where users typically use values like:

LANG=zh_CN.UTF-8
LANG=zh_TW.UTF-8

In this ecosystem, zh_CN / zh_TW are the standard, practical, and interoperable identifiers, while zh-Hans / zh-Hant are generally not the expected naming convention.

$ locale -a|grep zh|grep UTF
1:19:zh_CN.UTF-8
9:198:zh_TW.UTF-8
11:225:zh_HK.UTF-8

Why zh_CN / zh_TW are better here

For Linux CLI localization, the distinction users usually expect is not only script, but also the locale convention used by the platform.

Using:

• zh_CN for Simplified Chinese
• zh_TW for Traditional Chinese

would better align with:

• Linux locale naming conventions
• gettext expectations
• common CLI/i18n practices on Unix-like systems
• user expectations when mapping translations to system locale settings

Suggested change

Please consider renaming:

locales/zh-Hans.ftl -> locales/zh_CN.ftl
locales/zh-Hant.ftl -> locales/zh_TW.ftl

If compatibility is a concern, another option would be to support both naming styles, but prefer locale-style names in Linux-facing workflows.

Additional note

This is not to say that zh-Hans / zh-Hant are universally wrong — they are valid and useful in BCP 47 contexts. But for a Linux/coreutils localization project, zh_CN / zh_TW would be more consistent with established conventions in the gettext and Unix locale ecosystem.

Thanks for considering this.