Skip to content

feat: add --lang zh for Chinese CLI output - #96

Closed
xiaohui-zhangxh wants to merge 3 commits into
agent-ecosystem:mainfrom
xiaohui-zhangxh:feat/output-lang-zh
Closed

feat: add --lang zh for Chinese CLI output#96
xiaohui-zhangxh wants to merge 3 commits into
agent-ecosystem:mainfrom
xiaohui-zhangxh:feat/output-lang-zh

Conversation

@xiaohui-zhangxh

Copy link
Copy Markdown

Summary

  • Add --lang zh / AFDOCS_LANG with an i18n catalog so check messages, scoring resolutions, and diagnostics can be emitted in Chinese (missing keys fall back to English)
  • Wire checks, resolutions, and diagnostics through t(), and update CLI docs plus unit tests
  • Fix prepare so Git installs build dist/, ensuring consumers get compiled output

Test plan

  • npm test (including test/unit/i18n/*) passes
  • afdocs check <url> --lang zh prints Chinese messages / resolutions / diagnostics
  • Default behavior (no --lang, or en) matches the previous English output
  • AFDOCS_LANG=zh and CLI --lang behave consistently
  • Installing from Git yields a usable package (dist/ present)

Made with Cursor

xiaohui-zhangxh and others added 3 commits July 22, 2026 14:54
Introduce an i18n catalog with en/zh strings and wire --lang / AFDOCS_LANG
through the CLI and runner so JSON messages, scoring resolutions, and
diagnostics can be emitted in Chinese with English fallback for missing keys.

Co-authored-by: Cursor <cursoragent@cursor.com>
Consumers installing from GitHub need compiled dist/; keep husky only when .git exists.

Co-authored-by: Cursor <cursoragent@cursor.com>
Drop prepare-husky helper; developers can run husky locally.

Co-authored-by: Cursor <cursoragent@cursor.com>
@dacharyc

dacharyc commented Aug 9, 2026

Copy link
Copy Markdown
Member

Thank you for the PR! Your catalog is comprehensive and I appreciate the effort in threading through where relevant and updated tests. But after thinking through the maintenance considerations this would introduce, I think I need to close this rather than merge it.

Routing every user-facing string through a two-language catalog is a permanent commitment: every future message change needs paired en/zh edits, and I can't verify translation accuracy or maintain the zh catalog myself. I took a look at how other projects handle this, and projects that localize CLIs successfully (git, the GNU tools) do it with per-locale maintainer teams and drift-detection tooling; projects that accepted translations without that (kubectl) have seen them go stale.

I don't currently have signal on which locales users need or a sustainable ownership model. If there's real demand, I'd rather design for it deliberately (extraction tooling, community locale ownership) than start from a single catalog.

Feel free to open an issue, instead, if you'd like to see this tracked as a potential future addition. I'm happy to track interest there and gather info about what other locales people might want to support if there's enough demand for this to justify future feature development around it.

@dacharyc dacharyc closed this Aug 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants