uutils / uutils/coreutils

incorrect localization type for chinese

Open Beginner friendly
#12,305 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

J - Locale
Dominant language
Rust
Stars
24.1k
Forks
2k
Avg merge
1d 5h
Merged PRs (30d)
365

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting the locale lookup and the files under uutils/coreutils-l10n/locales, especially zh-Hans.ftl and zh-Hant.ftl. Verify how LANG values such as zh_CN.UTF-8 and zh_TW.UTF-8 are resolved, then confirm the renamed files are selected without breaking any existing naming support.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, localization
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.