← Concepts

How Langsys works

Langsys turns the sentences already in your UI into the translation system. There is no keys file to maintain and no build-time extraction step — the phrase in your code is both the lookup key and the base-language default.

The phrase is the key

In traditional i18n you invent an identifier for every string, store the real text in a locale file, and keep the two in sync forever. Langsys drops the indirection: you write the actual sentence, and that sentence is the key.

// Traditional i18n — indirection + a keys file to maintain
t('greetings.hello');            // what does this say? open en.json to find out

// en.json
{ "greetings": { "hello": "Hello, {name}!" } }

// Langsys — the phrase IS the key and the base-language default
t('Hello, {name}!', 'Greetings', { name });

Because the source text is the key, the same phrase written anywhere in your app is one translatable entry — deduplication is automatic — and a locale that hasn't been translated yet simply falls back to the source text. There is no such thing as a missing-key placeholder.

Realtime and continuous

You never run an extraction command. As your app renders, the SDK discovers the phrases it uses. New ones are machine-translated in the background into your project's target locales, and your app fetches the finished catalog. Ship a new sentence today; it's translated shortly after, no redeploy of a locale bundle required.

The lifecycle

1. Your UI renders phrases with t(), <Translate>, and friends.
2. In development, a write key lets the SDK discover and register any new phrases.
3. Langsys machine-translates them into every target locale of your project.
4. In production, a read-only key fetches the finished catalog for the user's locale.
5. Change the locale and the whole UI re-renders translated — instantly, no reload.