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.
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.mdvsREADME.zh-CN.md, or labels drifting between the dictionaries inweb/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
checks/*.check.mjs) asserting zh/en label parity across the i18n dictionaries and flagging ambiguous terms in the docs, orBefore 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.