i18n Missing Key Detector
Compare locale JSON files, find missing keys, and flag interpolation parameter mismatches before they ship to users.
Detected issues
2cta.save missingSave
(missing)
greeting param-mismatchHello {name} 你好
Compare locale files before missing keys and broken placeholders reach users
Internationalization debt accumulates quietly. A product ships one more feature, the English file gets updated, and one week later another locale is missing a key or has a broken placeholder name that crashes rendering in production. An i18n diff tool is valuable because it catches those inconsistencies before the UI turns them into visible bugs or runtime exceptions.
- Paste the base locale JSON on one side and the target locale JSON on the other, ideally from the same feature branch or release candidate.
- Review missing keys first, because they are the most visible user-facing gaps.
- Then review placeholder mismatches carefully. They are easy to miss in manual reviews and often create the ugliest runtime failures.
- Use the issue list to patch the target file before merging, publishing, or handing the file to translators.
Why missing translation keys are only half the problem
Teams usually notice missing keys because the UI falls back to the raw key name or the default locale. Placeholder mismatches are more subtle and often worse. If English uses Hello {name} but another locale becomes Hello, the screen may render awkwardly. If the target file uses {username} instead, the application may break entirely depending on the i18n framework.
That is why a serious i18n checker compares both presence and interpolation structure. A translation file that looks complete at a glance can still be functionally incompatible.
Where this kind of check fits in a delivery workflow
The sweet spot is before merge, before release, and whenever product or marketing content expands the locale surface area quickly. Indie builders and small teams especially benefit because translation review rarely has its own dedicated process.
A browser-based checker keeps the barrier low. Paste two locale JSON files, inspect the missing keys and placeholder mismatches, fix them, and move on. That simplicity is exactly what gives the page real retention value.
Best use cases
- Checking whether a newly added feature string exists across all supported locales.
- Catching interpolation mismatches like {name} vs {username} before they break rendering.
- Auditing translation completeness in small teams that do not have a dedicated localization pipeline yet.
Common mistakes to avoid
- A locale file can be syntactically valid JSON and still be operationally broken if placeholders do not match the source locale.
- Machine-translated locale files often preserve wording but accidentally alter placeholder names or punctuation around them.
- Do not treat fallback to English as harmless. It can hide real product gaps until a user reports them publicly.
Related tools
Move directly into the next step instead of leaving the site to do adjacent work elsewhere.
JSON Formatter / Validator
Format, minify and validate JSON data
Structured Data Diff
Compare JSON, YAML, and XML by normalizing them into a single structure and highlighting field-level differences.
YAML ↔ Properties Converter
Convert between YAML and Java .properties format
Unicode Converter
Convert text to Unicode code points and vice versa
FAQ
Why compare placeholder names and not just keys?
Because matching keys alone does not guarantee the runtime string contract is still compatible. Placeholder mismatches are a common source of broken UI rendering.
Can this replace a full localization platform?
No. It is a fast browser-side check for missing keys and mismatch detection, not a translation memory or workflow system.
Why is this useful for indie developers specifically?
Because smaller teams often manage locale files manually, which makes lightweight consistency checks disproportionately valuable before each release.