Guides · Updates
Continuous localization: changed text re-translated, the rest left alone
Continuous localization is the way a site or an app keeps its languages current after launch: the platform notices what changed, translates only that, a person marks it ready, and the translations that were already approved stay exactly as they were. This guide walks through the loop for websites and for app strings, with what a visitor sees at each step.
The continuous localization loop, in four steps
- Detect. A sync from the CLI, the SDK or a JSON upload sends only the rows whose source changed; a site served through the WordPress plugin or the edge proxy reports new text as pages are rendered.
- Translate. The changed rows go through the same memory, termbase, machine translation and 18 live checks as a document; an exact match from the memory is reused before the model is consulted.
- Review. A person reads the new rows in the editor and marks them ready, per language, one row or all of them at once.
- Publish. Only rows marked ready are served; the edge cache is purged and the plugin picks the change up on its next refresh.
Two kinds of key make the loop work. A named key (a JSON path, a block in WordPress) keeps its translation when the source changes: the old approved text stays live, flagged as outdated in the editor, until a person approves the new one. Website text is keyed by its content, so an edited sentence arrives as a new string while every other sentence on the page keeps its translation, and text that was already approved anywhere in the project is reused on the spot. The website localization workflow below follows one page through exactly that.
A changed sentence is one row of work, not a page, and a translation a person approved is never overwritten by a sync.
- a source word is counted once against the served-word cap, however many languages you serve
- 1×
- automatic retries for a failed sync before it is set aside for you to re-run
- 3
- row per repeated text: the same sentence on ten pages is translated and approved once
- 1
- file formats the CLI syncs: JSON, YAML, PO, iOS strings, xcstrings, Android XML, ARB and XLIFF
- 8
Websites
Website localization workflow: a product page changes on Tuesday
Say a product page gets a new feature paragraph, a reworded price explanation and one updated FAQ answer, in a site served in English, Finnish and German. The next render reports three new strings. The forty other sentences on the page keep their approved translations and keep serving. The three new ones are translated by the machine with the page's memory and terms, and a visitor who opens the Finnish page meanwhile sees the new paragraph in English and the rest in Finnish. The reviewer opens the editor, filters to the three rows, edits one, marks all three ready, and the cache is purged. If the reworded price sentence already existed approved on the pricing page, it is reused without a review.
That is the whole website localization workflow after launch: the changes, reviewed, published, and nothing else touched.
- Three new rows, forty untouched
- Source shown until marked ready
- Approved text reused across pages
- Cache purged on publish
Apps and strings
Named keys: the old translation stays live until the new one is approved
For app strings the key is the identity, so a changed source keeps its translation. The sync marks the row outdated, machine translation drafts a new version for the languages you opted in, and the previously approved text keeps serving until a person approves the new draft. The CLI sends only the rows that changed since the last push, and it never overwrites a row a person committed on the server; those come back in the report as protected. In the pipeline, validate with the CI flag fails the build on a key with no published translation, an empty one, or one that exists only in a target file.
- Changed rows only
- Outdated flag, old text still live
- Protected rows never overwritten
- validate --ci exits 2 on a gap
Review
Approve per language, one row or all of them
Every language is its own lane. Add a target language, switch machine translation on or off for it, approve its pending rows in bulk when the draft quality is good enough for the page, or hold a locale back from search engines until a person has read it. Nothing is served to visitors until it is marked ready, on every route: plugin, proxy, script tag or API.
- Per-language approval
- Bulk approve pending rows
- Hold a locale back from search
- Ready rows only, every route
History
Every row keeps its versions, and any of them can come back
A row's history lists each source version and each target version with its author and when it was marked ready. The editor flags rows whose source changed since the translation was approved and filters to them in one click. Restoring an earlier text is an ordinary save, so a wrong edit on a live row is one click away from the previous version.
- Source and target versions
- Author and date per version
- Outdated filter
- Restore any version
Pipelines
Continuous localization that tells your systems what happened
A signed webhook fires once per approved row with its locale, namespace and key, and once per sync batch that added keys, so a build, a cache or a chat channel can react to translations, not to timers. The sync itself runs as a background job: a transient failure is retried three times with increasing delays, and a job that keeps failing is set aside where you can see it and re-run it, which is always safe because syncing the same content twice never creates duplicates.
- Webhook per approved row
- HMAC-signed payloads
- 3 retries, then set aside
- Re-run is always safe
Costs
Month two is billed as the changes, not the site
Machine translation draws words only for the rows that changed, so a stable site draws almost none and a busy one draws the words of its edits. The served-word cap counts a source word once across all languages, sites are unlimited on every plan, and a translator reviewing the changed rows quotes per word on exactly those rows. The [website translation cost guide](/guides/website-translation-cost) prices three sites, month one and month two.
- Changed words only
- Source words counted once
- Unlimited sites
- Review priced on the changed rows
FAQ
Continuous localization, answered
Continuous localization keeps the languages of a changing site or app current without repeating the whole job: the platform detects the strings that changed, translates only those, a person marks them ready, and the translations already approved stay as they were. It is the opposite of exporting the site every quarter and translating it as a document.
For a named key, the previously approved translation keeps serving until the new one is approved. For website text, the edited sentence shows in the source language until a person marks its translation ready, and every other sentence on the page stays translated; the website localization workflow above shows it on one page.
No. A row a person committed is protected: a push that tries to change it is reported back as protected, and machine translation never replaces an approved text on a live row. An edit after approval is made by a person, in the editor, where it is logged in the row's history.
The editor flags rows whose source changed after the translation was approved, filters to them in one click, and the row history lists every source version and every target version with its author. The CLI status command shows what the server did with the last push.
Yes. Approval is per language and per row: approve Finnish today and German next week, or hold a locale back from search engines until it has been read. A language you add later starts from the memory and the model, with nothing published until you say so.
The same text in the same project is one row: translate and approve it once and it is reused on every page, block and attribute where it appears. The same sentence across different sites is linked as well, so an approved translation can fill its copies and a disagreement between them is listed for a person to settle.
A transient failure is retried three times with increasing delays. A job that keeps failing is set aside rather than dropped, and because the sync is idempotent, re-running it from your side is a safe recovery. If the platform is unreachable, the proxy serves your page untranslated rather than not at all.
Per row, yes: open the row's history and restore any earlier text, which saves it like any edit. Unmark a row to take it off the live site, or hold the whole language back while you fix it.
Connect the site, then change a page and watch what happens
Every signup starts free with 3,000 words of documents; websites and app strings are on every paid plan, from EUR 9.90 a month.