Translation architecture
Translation key lifecycle
Every feature creates new strings. Every refactor removes some of them. Most translation systems are good at the first half of that lifecycle and leave teams guessing about the second.
A developer adds a translation key while building a feature. The application grows, the feature changes and years later nobody remembers which system introduced the key or whether it is still safe to remove.
That uncertainty has a predictable result: teams keep old translation keys forever.
Do that hundreds or thousands of times and the translation catalog becomes another form of technical debt.
Translation catalogs naturally grow in one direction
Adding a key is low risk. Deleting one can break an interface, email, backend message or older deployed client.
So teams behave rationally: they add aggressively and delete cautiously.
The result is a catalog containing active product copy, historical copy, renamed keys, abandoned experiments and strings that nobody can confidently classify.
“Unused” is a system-level question, not always a repository-level question
Searching one frontend repository can tell you that a key is not used by that frontend. It cannot automatically prove that nothing else depends on it.
The same translation project may feed a web application, an admin application, backend messages, email templates and background workers.
The problem gets worse when every system synchronizes translations differently
A mature product can end up with translation resources moving through repositories, CI jobs, backend resource files, generated JSON and external translation tooling.
Every synchronization step becomes another script, token, convention and failure mode that the team has to maintain.
The harder the synchronization system is to understand, the less likely anyone is to trust automated cleanup.
Deletion should be a state transition, not a guess
A safer model separates the objective fact that a key disappeared from the decision to permanently remove it: active, no longer detected, deprecated, reviewed, then removed.
Active
At least one relevant source currently references the key.
No longer detected
A source that previously referenced the key no longer does.
Deprecated
The key is now a cleanup candidate rather than part of normal active development.
Reviewed
The team has checked whether another source, deployment or compatibility requirement still needs it.
Removed
The translation entry can now be deleted intentionally.
Automatic deprecation is more trustworthy than automatic deletion
Keykit does not need to guess that a translation is invalid. It only needs to record an observable fact: this connected source used to contain the key, and now it does not.
That signal can be automated safely.
Permanent deletion can remain a deliberate developer decision.
Keykit makes this lifecycle part of normal development
New translation calls create discovery signals. Removed calls create deprecation signals. Instead of periodically auditing a giant translation catalog by hand, teams can clean it as the product evolves.
Translation-key cleanup FAQ
How do I find unused translation keys?
The safest approach is to compare translation entries with usage across every relevant source rather than searching only one codebase.
Is it safe to automatically delete unused i18n keys?
Usually not immediately. A key can be absent from one source while still being needed elsewhere. Automatically marking it as no longer detected or deprecated is safer than permanent deletion.
What should happen when I rename a translation key?
The new key should become active while the previous key becomes a deprecation candidate once it is no longer detected.
What if a backend system also uses the translations?
Track the backend as another relevant source when possible. A key should not be considered globally unused merely because the frontend stopped using it.
Let refactoring clean up localization debt too
Keykit turns source changes into translation lifecycle changes automatically.
See automatic key discovery