How Keykit works
How Keykit works
Keykit connects your translation catalog directly to the code using it. Add a normal translation call, let Keykit discover the key, and manage the entire translation lifecycle without keeping a second inventory in sync by hand.
Source-driven localization
One translation call is enough to introduce a key
With a traditional workflow, developers often have to think about both the code and the translation system. Keykit treats usage in the application as the important signal. When a new static translation key appears in your source, Keykit can discover it and bring it into the project automatically.
import { useKeykit } from '@keykithq/sdk/react';
function CreateProjectButton() {
const { translate } = useKeykit();
return <Button>{translate('projects.actions.create', 'Create')}</Button>;
}Keykit sees the key used by the application and adds it to the translation workflow. There is no separate step to register the key in a dashboard first.
From source code to every supported language
Keykit keeps the translation workflow centered around the product code instead of forcing developers to maintain synchronization plumbing around it.
1. Use the key
Write a normal translation call where the text belongs. Use a stable, statically analyzable key that describes the product concept.
2. Keykit discovers it
Keykit scans the connected source and recognizes new translation keys used by the application.
3. Missing translations are created
New locale values can be generated automatically, reviewed and edited from the Keykit project.
4. Your application gets the translations
Use Keykit's live or static delivery model depending on how you want translations to reach the application.
Choose your delivery model
Fetch translations live or keep them as static application resources
Keykit supports two delivery models so teams can choose between runtime freshness and build-time control. Set delivery: "live" or delivery: "static" in the project config.
Live delivery
Load translations from Keykit at runtime so updated copy can become available without maintaining generated locale files manually. Useful when you want translation changes to move independently from application builds.
Static delivery
Keep translations as static resources inside your application and use the Keykit CLI pull workflow to populate them. Useful when translations should be versioned, bundled and deployed with the application.
npx @keykithq/cli pull
Automatic lifecycle tracking
Removing UI should also clean up its translation debt
Translation systems are good at accumulating keys and much worse at telling you when those keys stopped mattering. Keykit treats disappearance from source as useful information.
Keykit no longer detects the key
Instead of immediately deleting the translation, Keykit can mark it as no longer detected or deprecated so the team can review it safely.
Unused does not always mean safe to delete
A key may disappear from one frontend while another application, backend service or older deployed version still depends on it. That is why Keykit separates detection from deletion.
Another source may still use it
A web app can stop using a key while an admin application or backend service still references it.
A rollback may still need it
Immediate deletion turns a normal refactor into a potentially breaking operation for older deployed code.
Developers keep the final decision
Keykit records that a key disappeared and surfaces it for review instead of pretending absence always means deletion is safe.
Translation keys have a lifecycle
Treating keys as long-lived entities makes localization easier to understand and much safer to clean up.
Discovered
The key has appeared in a connected source.
Active
The key is currently detected and belongs to the live translation catalog.
Translated
Required locales have values available.
No longer detected
A source that previously referenced the key no longer does.
Deprecated
The key has become a cleanup candidate and should be reviewed.
Removed
The team has confirmed the key is no longer needed.
You should not need a second engineering system just to synchronize strings
Localization often grows into a collection of extraction scripts, generated files, upload jobs, download jobs, repository integrations and cleanup conventions. Keykit is built around a simpler idea: let source usage drive translation state.
The exact runtime path depends on whether your project uses live or static delivery.
How Keykit works
Does Keykit replace my i18n library?
Keykit manages the translation workflow, key lifecycle and delivery around your application. Runtime concerns such as formatting, interpolation, pluralization and locale routing still depend on the integration and framework you use.
How does Keykit discover translation keys?
Keykit analyzes supported translation calls in connected source code and records statically identifiable keys used by the application.
Does Keykit immediately delete a key when it disappears?
No. Disappearance from source is a signal, not proof that deletion is safe. Keykit can mark the key as no longer detected or deprecated so it can be reviewed first.
Can I use Keykit with an existing application?
Yes. Existing translations can be brought into the project first, then Keykit can use source discovery to help show which keys are actively detected by the connected application.
Do translations have to be fetched at runtime?
No. Keykit supports both live delivery and a static workflow where the CLI pulls translation resources into the application.
Let the code drive the translation catalog
Create translations when features appear, identify stale keys when features disappear, and stop maintaining translation state twice.
Start with Keykit