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

Xem xét tài liệu plugin hiện có trong README.md và README.zh-CN.md, các dictionary trong web/i18n.mjs và pattern checks/*.check.mjs hiện có. Trước tiên, hãy làm rõ liệu dự án muốn một check cục bộ cho plugin hay một registry bên ngoài cùng bước audit; được xem là hoàn tất khi cách tiếp cận được ưu tiên và các tiêu chí chấp nhận của nó đã được thống nhất trước khi triển khai.

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.