Internationalization

August 13, 2026 · View on GitHub

简体中文

Oh My DSH currently ships en and zh-CN messages.

Locale selection

Command-line tools resolve the locale in this order:

  1. --locale <tag> or --locale=<tag>
  2. LC_ALL
  3. LC_MESSAGES
  4. LANG
  5. English

Locale values may use POSIX suffixes, such as zh_CN.UTF-8. Unsupported environment locales fall back to English. An unsupported explicit --locale is reported as an error instead of being silently ignored.

Traditional Chinese locales are not mapped to Simplified Chinese. Until a zh-TW catalog exists, zh-TW, zh-HK, and zh-Hant fall back to English.

Fallback

English is the source locale. A missing localized key falls back to the English message. Tests require every shipped locale to contain the complete English key set, so fallback is defensive rather than the normal translation workflow.

Adding a locale

  1. Add the locale tag to SUPPORTED_LOCALES.
  2. Add locales/<tag>.json with exactly the same keys and placeholders as locales/en.json.
  3. Add translated documentation under docs/<tag>/ when applicable.
  4. Run npm run public:check.

Message interpolation only replaces named placeholders such as {path}. It does not evaluate templates, HTML, JavaScript, or shell syntax. Control characters in interpolated values are escaped before terminal output.

Manifest fields and CLI messages are separate localization surfaces. A v1 production manifest must provide both en and zh-CN for name and summary; additional valid locale tags can be added without changing the Schema.