For developers
Localization as part of the stack
A universal JS SDK serves strings cache-first with background sync: the network is an optimization, not a blocking dependency. The REST API is keyed by locale, namespace, and key, and ICU MessageFormat is parsed, not mangled: plurals and selects survive. An edge proxy translates the sites you'd rather not touch, and human translators and QA sit behind the same API.
SDK
One client, every runtime
In Node, the browser, and React, the SDK wraps the REST API cache-first with background sync and pluggable persistent storage, typed end to end: a types CLI regenerates definitions live as translators add keys, so a missing key or wrong ICU parameter fails at compile time. Push new source strings from CI; translated strings flow back through the same pipe.
- Node · browser · React
- Cache-first with background sync
- Pluggable persistent storage
- Typed end to end
Format safety
ICU MessageFormat, actually parsed
Plural rules and select branches survive translation with their structure intact, and the QA detectors treat a lost placeholder or a malformed ICU message as a defect, not a detail. XLIFF goes in and out for everything else in your toolchain.
- Plurals & selects preserved
- Nested messages
- Placeholder QA
- XLIFF round-trip
Humans included
MT for speed, translators for the strings that matter
Every string your API syncs lands in the same editor the translators use, so “machine-translate now, humanize the checkout flow next sprint” is a workflow, not a migration. Continuous-localization projects keep the feed open, with per-project integration keys you can create, toggle, and revoke.
And your content only goes to MT when you want it to: exact TM matches are reused first, high TM matches can skip MT entirely, and copy-source and none are first-class engine modes.
- Same rows, same editor
- Entity protection in MT
- QA gates before release
Product
Dig into the details
Ship the first namespace
Join the waitlist and we’ll tell you the day API keys open.