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.

Review the existing plugin documentation in README.md and README.zh-CN.md, the dictionaries in web/i18n.mjs, and the available checks/*.check.mjs pattern. First clarify whether the project wants a plugin-local check or an external registry and audit step; done means the preferred approach and its acceptance criteria are agreed before implementation.