Question: would a zh/en term-consistency audit for plugin docs and i18n be welcome?
I maintainer di solito rispondono entro 1 giorno
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
- Ambito
- documentation, internationalization, tooling
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
- 19
- Fork
- 17
- Merge medio
- 2g 6h
- PR unite (30g)
- 15
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
daisy/a11y-meta-viewer#18 ·
-
good first issue status: needs triaging type: bug version: 2.0
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
medusajs/medusa#17094 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
browser: chrome package: @carbon/react package: styles
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
carbon-design-system/carbon#23567 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
clerk/javascript#10033 ·
I maintainer di solito rispondono entro 1 giorno
-
bug client p1
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
vercel/eve#4173 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno