Continuous localization
Continuous localization is for content that keeps changing — the strings of an app or a live website rather than a one-off document. A continuous project is an ongoing feed, not a single job: your software sends strings to the project as they appear, translations are kept up to date as sources change, and your app or site fetches the current translations at runtime.
Everything you know from document projects still applies. Every new or changed string runs through the same machinery: your translation memories and glossaries, machine translation, QA checks, and human editing in the editor. A synced string can be machine-translated, reviewed, and edited exactly like a line from an uploaded file — the difference is only how content arrives and how it is delivered back.
How a continuous project differs from a document project
Section titled “How a continuous project differs from a document project”- Content arrives continuously. There is no file upload; strings flow in through an integration and new ones can arrive at any time.
- The project never “finishes”. A document project completes when its files are translated and delivered. A continuous project stays active, translating each increment as it lands.
- Delivery is live. Instead of downloading a finished file, your app or website fetches current translations through the integration endpoints.
- The workflow is the same. TM, terminology, QA, and human review apply to every increment, so quality doesn’t depend on whether a string arrived on day one or day one hundred.
Create a continuous project
Section titled “Create a continuous project”- From the dashboard, start a new project and give it a name.
- Pick the source language — the language your content is written in.
- Choose how you’ll connect (you can change this later):
- I’m building an app — sync translations from your codebase with the SDK, CLI, or API.
- I have a website — paste one JavaScript tag into your site.
- One domain, every language — the zero-code edge proxy: point your domain and translated pages are served from the CDN edge.
- I use WordPress — install the plugin and enter your API key.
- Pick a translation workflow and create the project.
The project is created with your source language and a first integration key, and you land in the project hub. Add target languages there — one entry per language you want to serve.
You can also set an optional monthly token limit: a cap on billable translation tokens per month for the project. Leave it empty for no limit; you can change it at any time in the hub’s Settings tab.
The four integration modes
Section titled “The four integration modes”| Mode | What it is | Best for |
|---|---|---|
| Developer | Sync and fetch strings from your codebase with the SDK, CLI, or API | Web and mobile apps with an i18n setup |
| JS snippet | One script tag on your pages; translation happens in the visitor’s browser | Any site where you can edit the HTML |
| Edge proxy | Your domain’s pages are served already translated from the CDN edge | Sites you can’t or don’t want to modify |
| WordPress | A plugin that translates pages server-side before they are sent | WordPress sites |
The mode you pick controls which setup guide the hub’s Integration tab shows — it doesn’t lock anything in. You can switch the mode at any time in the Settings tab; your strings and translations are preserved.
For the developer mode, see the developer quickstart. The three site-facing modes are covered in Website translation.
Integration keys
Section titled “Integration keys”Integration keys authenticate your app or site against the project. Each key belongs to exactly one project (and one source language) — a key can never read or write another project’s content.
There are two key types:
- Publishable (
pk_) — can read translations and sync source strings. Safe to embed in client-side code: the JS snippet, the edge proxy, anything shipped to a browser. - Master (
sk_) — full access: read, sync, and write translated text back through the API. Use it server-side only, and never put it in code a visitor can see.
Manage keys in the project hub under Settings → API Keys:
- Create — click + Create Key, add a description of where the key will live (for example “Production web app”), and pick the type.
- Pause and reactivate — toggle a key off without deleting it. A paused key stops working immediately; reactivate it whenever you like. The key string itself doesn’t change.
- Revoke — delete the key. This is permanent and cannot be undone; any integration still using the key stops working.
Key rotation and other practices are covered in String sync and integration keys.
Know your integration is connected
Section titled “Know your integration is connected”The project hub shows a connection banner for continuous projects. Green means the integration has been seen — for the snippet, edge proxy, and WordPress modes it also shows the domain or the time of the last ping or sync. Amber means nothing has connected yet, with a shortcut to the setup guide in the Integration tab.
Where to go next
Section titled “Where to go next”- Website translation — the JS snippet, the edge proxy, and the WordPress plugin in detail.
- String sync and integration keys — how strings flow into the project and how to manage keys safely.
- Developer quickstart — the SDK, type generation, and consuming translations from code.