hoangsonww / hoangsonww/Claude-Code-Agent-Monitor
i18n: community translations for new languages (Spanish, German, French, ...) -- contributors welcome
- Dominant language
- TypeScript
- Stars
- 1k
- Forks
- 234
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 18
Description
## Summary
The dashboard currently ships **3 languages**: English (`en`), Chinese (`zh`), Vietnamese (`vi`). I'd love to support more — Spanish, German, French, Japanese, Portuguese, etc. — but I'm only fluent in English, Vietnamese, and Chinese, so I can't author or vouch for the correctness of other languages myself.
**This is an open call for community contributors.** If you're fluent in a language we don't support yet, please add it! One language per PR is ideal.
## The bar: same standard as the existing languages
A new language is only useful if it's **correct, comprehensive, and complete**. That means:
- **Full coverage** — all **~1,452 translation keys across 15 namespaces** must be present in the new locale. No missing keys, no silent fall-back to English in the UI. (For reference, `en` has 1,452 leaf strings today; `zh`/`vi` are at 1,446 — a small pre-existing drift new locales should *not* copy; match `en` exactly.)
- **Correctness** — a **fluent/native speaker must review every namespace**. AI tools (incl. Claude) are fine for a first pass and are encouraged to move fast, **but a human who actually speaks the language must verify the output** before it's merged. Machine translation alone is not acceptable — UI microcopy, button labels, pluralization, and domain terms break in subtle ways that only a speaker catches.
- **Consistency with our conventions** — keep technical identifiers and the **"Agent" terminology untranslated** the way `zh`/`vi` already do (there's a test that enforces this). Don't translate interpolation variables or placeholders — `{{count}}`, `{{name}}`, `…`, etc. must stay intact. Match tone/length so the UI doesn't overflow.
## What "adding a language ``" actually involves
Please read **[`docs/I18N.md`](docs/I18N.md)** first — it documents the architecture (i18next + react-i18next, detection order, namespaces). Concretely, a complete PR touches:
1. **`client/src/i18n/locales//*.json`** — translate **all 15 namespaces**:
`activity`, `alerts`, `analytics`, `ccConfig`, `common`, `dashboard`, `errors`, `kanban`, `nav`, `run`, `sessions`, `settings`, `splash`, `updates`, `workflows`.
Largest are `workflows` (411), `settings` (269), `ccConfig` (227), `common` (163), `run` (141). Keep the exact key structure as `en`.
2. **`client/src/i18n/index.ts`** — import each `_` bundle, add to `resources`, and add `""` to `supportedLngs`.
3. **`client/src/i18n/format.ts`** — wire locale-aware date/number/model-name formatting for the new locale.
4. **`client/src/i18n/__tests__/i18n.test.ts`** — extend the assertions to cover `` (key parity vs `en`, "Agent" left untranslated, non-explicit tag like `es-ES` → `es`). Bonus: a real parity test that fails on any missing key would help all locales.
5. **`README-.md`** — a full translation of `README.md` (we keep `README-VN.md` / `README-CN.md` as standalone files; add the language switcher link at the top like the others).
6. **`wiki/`** — add `` entries to **`wiki/i18n-content.js`** following **[`.claude/rules/wiki-i18n.md`](.claude/rules/wiki-i18n.md)**, then bump the cache: `CACHE_NAME` in `wiki/sw.js` and the `i18n-content.js?v=` query in `wiki/index.html`.
7. **`docs/I18N.md`** — add the language to "Supported languages" and the `supportedLngs` list.
## Acceptance criteria
- [ ] All 15 namespaces present in `client/src/i18n/locales//` with **the same keys as `en`** (no missing, no extra)
- [ ] Registered in `index.ts` (`resources` + `supportedLngs`) and `format.ts`
- [ ] `npm run test:client` passes, including the i18n test extended for ``
- [ ] Interpolation placeholders and ``/identifiers/"Agent" terminology preserved
- [ ] `README-.md` added; switcher links updated across README variants
- [ ] Wiki `i18n-content.js` updated per the wiki-i18n rule + cache version bumped
- [ ] `docs/I18N.md` updated
- [ ] PR states **who reviewed the translation** and their fluency (self/native/professional). If AI-assisted, say which tool and confirm a fluent human verified it.
## Notes for contributors
- **One language per PR** keeps review tractable.
- If you can only do part (e.g. the client UI but not the README/wiki), open a draft PR and say so — partial-but-correct beats complete-but-wrong, and others can build on it.
- Not sure where to start? The client `locales//*.json` files are the highest-impact piece. Copy `en/` as the scaffold and translate in place.
- Questions welcome in this thread. 🙏
_Filed as a standing community task — comment to claim a language so we don't duplicate effort._
Contributor guide
Assessment
This issue has not been assessed yet.