Question: would a zh/en term-consistency audit for plugin docs and i18n be welcome?

The marketplace validator checks that bilingual artifacts exist (bilingual descriptions, a Chinese README alongside the English one), but not that they stay consistent — e.g. the same concept named differently in README.md vs README.zh-CN.md, or labels drifting between the dictionaries in web/i18n.mjs. As a plugin grows (11 tools, 465 lines of i18n), that gap widens quietly.

We maintain a small deterministic term-registry tool (per-project term registry with five lookup entries plus a form-level doc audit; open-sourced as part of sih-engine) and could contribute either

• a plugin-local check (a checks/*.check.mjs) asserting zh/en label parity across the i18n dictionaries and flagging ambiguous terms in the docs, or
• an external registry + audit step, if you prefer to keep the plugin dependency-free.

Before building it: is this a real pain point for you, and which shape would you prefer? No hard feelings if the answer is "not now" — asking before building.

README.md と README.zh-CN.md にある既存のプラグインドキュメント、web/i18n.mjs の辞書、利用可能な checks/*.check.mjs パターンを確認する。まず、プロジェクトがプラグインローカルの check を求めているのか、それとも外部レジストリと監査ステップを求めているのかを明確にする。実装前に、推奨するアプローチとその受け入れ基準について合意できていれば完了とする。