Localization bugs usually do not look like bugs at first.
They sit inside JSON, YAML, CSV, or resource files as ordinary strings. A missing key, a renamed placeholder, a translation file that slowly falls out of sync with the source language. Nothing dramatic. Nothing that immediately looks like a broken build.
Then one day the UI ships in another language, and the problem becomes visible.
That is why I started building LocaLint, a small open-source tool for checking localization files before these issues reach users.
The idea is simple: translation files should be treated less like passive text and more like part of the codebase.
We already lint code, format files, check configs, and run tests before shipping. But localization files are still often reviewed manually, even though they can break the product in very real ways.
A few examples:
one language has a key that another language is missing
- a placeholder exists in one file but not in another
- old translation keys stay in the project long after the code stops using them
- files drift apart structurally as the project grows
- small mistakes only appear outside the default language _ LocaLint is meant to catch that kind of problem early.
It is not trying to replace translators or localization platforms. It is closer to a developer tool that checks the structure around translations: keys, placeholders, consistency, and output that can be used in a normal workflow.
The first version is focused on:
- missing translation keys
- unused keys
- placeholder mismatches
- inconsistent localization structures
- readable CLI output
The project is still early, so the rules, supported file formats, and output style may change. I would rather shape it around real developer problems than build a large tool full of checks nobody wants to use.
The main design question I keep coming back to is this:
A localization checker should be strict enough to catch real mistakes, but quiet enough that developers do not disable it after one run.
That balance matters.
I am especially looking for feedback from people who have dealt with i18n or localization in actual projects:
- Which file formats should be supported first?
- What localization bugs have caused real problems for you?
- Should missing translations fail CI by default, or only warn?
- What makes CLI output useful instead of noisy?
- Are placeholder and missing-key checks enough for a first version?
Project link: https://github.com/bsagir61/LocaLint
LocaLint is still small, but the goal is clear: make localization files easier to trust before they reach production.
Top comments (0)