Automatic key discovery
Automatic key discovery
Your code already contains the information needed to know which translation keys exist. Keykit uses that source information to keep the translation catalog aligned with the application.
Translation catalogs drift when code and translation state are maintained separately
Every manual synchronization boundary creates another place for application state and translation state to disagree.
A key exists in code but not in the catalog
The feature ships before every locale knows the string exists.
A key exists in the catalog but not in code
Nobody knows whether it is stale, intentionally retained or still used somewhere else.
A key is renamed
The new key appears while the old one quietly survives for years.
Different repositories synchronize differently
The central catalog stops representing the applications that actually consume it.
Use the translation. Keykit finds the key.
The ideal developer workflow should be no more complicated than writing the translation where it is needed.
translate('billing.subscription.cancel', 'Cancel subscription')Keykit can register the key, identify missing languages and keep its source-usage state connected to the application.
Predictable keys make automation reliable
Static translation identifiers are easier to discover, search, refactor and deprecate safely.
Prefer explicit translation keys whenever practical. Dynamic key generation can make it impossible for static analysis to know the complete set of possible translations.
translate('documents.upload.success', 'Uploaded')
// less analyzable:
translate(`documents.${type}.${state}`)The important event is not only when a key appears
A useful translation system should also notice when a key that used to exist has disappeared. A new key is created and translated. A missing key is marked no longer detected, then reviewed, and removed only when that is safe.
One catalog can have several consumers
Applications often share translation infrastructure across more than one codebase. Keykit makes usage information explicit instead of treating the catalog as an isolated list of strings.
A key that disappears from one source should not automatically be treated as globally unused while another connected source still depends on it.
Translation cleanup can happen naturally during refactoring
When developers rename or remove UI, the translation catalog should be able to follow instead of accumulating every historical version forever. The new key is detected. The old key becomes a deprecation candidate.
Automatic translation-key discovery FAQ
What is translation-key discovery?
Translation-key discovery is the process of identifying translation identifiers directly from the code that uses them rather than relying only on a separately maintained translation catalog.
Can Keykit discover dynamically generated translation keys?
Static string keys are the most reliable input for source analysis. Dynamically generated identifiers may require explicit handling because the complete key cannot always be determined from source code.
What happens when a discovered key is removed from the code?
Keykit can record that the key is no longer detected and move it into a deprecation workflow instead of immediately deleting it.
Can more than one application contribute key usage?
Keykit is designed around source-aware translation management, so source identity can be used to distinguish where a key is still being detected.
Make translation state follow application state
Discover new keys when developers add them and surface old keys when the code stops using them.
Start discovering keys