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

Aperta
#47 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
javascript

Direzione di ricerca

Esamina la documentazione esistente del plugin in README.md e README.zh-CN.md, i dizionari in web/i18n.mjs e il pattern disponibile di checks/*.check.mjs. Chiarisci innanzitutto se il progetto vuole un check locale al plugin oppure un registro esterno e un passaggio di audit; il lavoro è considerato completato quando l’approccio preferito e i relativi criteri di accettazione sono stati concordati prima dell’implementazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
JavaScript
Stelle
17
Fork
13
Merge medio
2g 23h
PR unite (30g)
19

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.