I’m trying to understand how localization is handled across different parts of a product, especially in teams that ship frequently.
On the product/UI side, I’ve seen cases where:
- new strings get merged without translations
- some languages lag behind others
- localization issues are only caught after release
- CI has no real signal that something is missing or out of sync
On the developer-facing side (API docs, READMEs, docs):
- docs stay English only even when the product is localized
- translated docs go stale quickly as content changes
- keeping multiple languages in sync is mostly manual
So I’m curious
- Which of these is more painful in practice: product/UI localization or docs localization?
- Do teams actively care about localizing docs, or is it usually not worth the effort?
- Are there any localization-related checks or automation you rely on during CI or PRs?
- What localization problems have actually caused real issues for we, developers, prioritizing docs or users?
Trying to figure out where localization tooling would provide real value versus being a "nice to have."
Top comments (1)
This is exactly what
i18n-validatedoes. Standalone CLI for CI pipelines:It checks: missing keys, extra/stale keys, broken placeholders, CLDR plural completeness, parse errors. Outputs terminal, JSON, or JUnit XML.
For pre-translation testing, add
i18n-pseudoto generate pseudo-localized files that catch layout/hardcoding issues before real translation.Both support 32 formats (JSON, YAML, PO, XLIFF, ARB, strings.xml...). Zero-config auto-detect.
Install:
npm install -g @i18n-agent/i18n-validate @i18n-agent/i18n-pseudo