What is continuous localization? Definition, workflow, and what it does not mean

Continuous localization is a translation workflow in which new and changed strings flow from the codebase to the people or systems that translate them automatically and continuously, in parallel with development, and approved translations are delivered to the running application without a release. It is the localization counterpart of continuous integration and continuous delivery: instead of a translation handoff before each release, translation is a process that is always running, and a translation fix never waits for a deploy.

This post is the definition: what the term means, what it does not mean, the four stages every implementation has, how it differs from the batch workflow it replaces, and what it does not solve. The product side, how Locize implements it, and the teams that use it that way are on the continuous localization page.

What continuous localization means, and what it does not

The word "continuous" is borrowed from continuous integration and continuous delivery on purpose. In those practices, code is integrated and shipped in small increments, all the time, instead of in large batches with a freeze before each one. Continuous localization applies the same idea to translation: the unit of work is the string, not the release, and the pipeline moves strings from code to translators to users without waiting for a cut.

Three readings of the term are wrong often enough to spell out:

• It does not mean "translate everything with AI and ship it". Machine and AI translation are how the first draft stops waiting; what is published is still decided by checks and review. A pipeline that pushes unreviewed model output to production is continuous and ungoverned, which is the combination behind terminology drift and the occasional insulting error message.
• It does not require abolishing translation files. Some continuous setups have no locale files in the repository at all because the application loads translations at runtime; others generate the files in CI and commit them. Both are continuous if nothing waits for a manual handoff.
• It does not remove the need for a glossary, a review workflow or quality checks. It makes them more important, because more strings move faster.

Continuous versus batch localization

A batch workflow has a recognisable shape. Development reaches a cut. Someone exports the strings that changed, or all of them, into files or a spreadsheet. The files go to translators, in-house or at an agency. Days or weeks later they come back, someone imports them, resolves what broke in the meantime, and the translations ship with the next deploy. Every step is a wait, and the feature that finished on the day of the cut ships in its default language only.

A continuous workflow removes the cut. Strings are detected as developers write them. Translation happens while the feature is still being built. A review gate decides what is ready. Delivery does not depend on a deploy. The visible effects on an engineering team: translation stops being a release-blocking dependency, and a wrong label in Polish is fixed in minutes rather than in the next release. The visible effect on a localization team: work arrives as a stream instead of as a pile.

The four stages of a continuous localization workflow

Every implementation, whatever the tooling, has the same four stages.

1. Detect: strings leave the code automatically

A developer writes a translation call with a new key and a default value. Either a static extraction step in CI reads the calls and reports the keys, or the running application reports a key the first time it renders it (in i18next this is the saveMissing option). Nobody exports anything; the key exists in the translation system with its default text before the pull request is merged.

2. Translate: people, machines and AI work while development continues

New keys get a first draft from machine or AI translation, with the project's glossary and style guide as context, so that no language is empty while the feature is in progress. Translators and reviewers work on the same keys in an editor that shows the source, the context and the terminology. Development does not wait for this stage, and this stage does not wait for a release.

3. Publish: a gate, not a freeze

What goes live is decided per string, not per release: automated checks for placeholders, numbers, tags and consistency; a quality-estimation score for machine-generated drafts; human review for the strings that need it. Versions or branches let a team stage translations for a feature that is not public yet. The gate replaces the freeze: the release train keeps running, and a translation joins it when it is ready.

4. Deliver: the running application picks up translations

Approved translations reach users without a build: the application loads them at runtime from a content delivery network, with a cache lifetime that balances freshness against latency. Teams that need files for server-side rendering or offline bundles download them in CI as generated artifacts. Either way, a fix published in the editor is live without a commit.

How teams implement continuous localization today

• CI sync with generated files. Extraction runs in the pipeline, a sync step pushes new keys to the translation system and pulls translated files back, the files are committed or downloaded at build time. Continuous, with the files kept for builds that need them. Diff-based sync matters here, so a pull request only translates the keys it added.
• Runtime reporting and CDN delivery. The application reports new keys as it runs (gated to development) and loads translations at runtime; the repository holds no locale files. The most direct form of the pattern, common in single-page and mobile applications.
• A translation management system in the middle. Both of the above need a place where translators, machine translation and AI meet the keys, with review, history and publishing. The TMS is the stage-2 and stage-3 half of the workflow; the CI or runtime integration is the stage-1 and stage-4 half.
• AI in CI only. A workflow that extracts keys and machine-translates them on push, with no editor and no review. Continuous by the definition above, and the setup that the "what it does not mean" section is about: nothing between the model and production. What breaks in it, and how to add the missing layer, is in when AI translations break.

What you need before it works

• Keys originate in code. If someone still types keys into a file or a spreadsheet, stage 1 is manual and everything downstream waits for it.
• One source of truth. Translations live in one system; files, if any, are generated from it. Two sources of truth reintroduce the merge step that batch workflows spend their time on.
• A written quality policy. Which content types may ship on an AI draft plus automated checks, which need a person, which are held in review proposals until approved. Continuous flow without this policy is a faster way to ship mistakes.
• A staging mechanism. Versions or branches, so translations for unreleased features do not go live early and a production version can be promoted deliberately.
• Checks that run on the whole corpus. Placeholders, numbers, tags and cross-key consistency need to be checked where all the strings are, on every save, not only on a diff. The taxonomy is in what actually breaks in translations.
• A measure. The one number that tells you whether the workflow is continuous: the time from a string being written to it being live in every language. If it is measured in release cycles, the workflow is batch with better tooling.

What continuous localization does not solve

• Translation quality. Flow is not quality. Terminology governance, human review and quality checks are separate layers, and continuous flow raises the cost of skipping them.
• Context. A string that arrives from the code without a screenshot or a note is still ambiguous. Continuous detection makes context capture more important, not less.
• Regulated content. Text that informs the public on matters of public interest can fall under the visible-disclosure duty of Article 50 of the EU AI Act (in force since August 2, 2026), unless it has undergone documented human review with editorial responsibility. The workflow can record that review; it cannot decide which content needs it. The Article 50 explainer has the details, and none of this is legal advice.
• Small, slow projects. Two languages the team reads, a few releases a year: a batch process is fine. Runtime delivery is still usually worth having, because a typo fix without a deploy is useful at any size.

How this works in Locize

Locize was built by the i18next team around exactly this workflow, and the four stages map onto four pieces:

• Detect: saveMissing with i18next-locize-backend reports keys from the running application; the CLI and the GitHub Actions do it from the pipeline, including diff-based sync for pull requests.
• Translate: automatic translation drafts new keys with the glossary and style guide as context; translators and reviewers work in the editor.

New keys arriving from the code and drafted in every target language by automatic translation, marked for review

• Publish: review proposals and needs-review marks gate what goes live, versions and branches stage it, and automated checks run on every save.
• Deliver: approved translations are published to the CDN by default, with per-version caching; the application loads them at runtime.

How that looks in practice, with the comparison to a batch workflow and the teams that ship this way, is on the continuous localization page. The engineering view of the same transition, how a batch handoff breaks continuous deployment and what the wired-in pipeline looks like, is in how batch translation workflows break continuous deployment.

If you want to measure your own string-to-live time: create a project, connect one namespace, and time the next key from commit to every language.

Frequently asked questions

What is continuous localization? A translation workflow in which new and changed strings flow from the codebase to the people or systems that translate them automatically and continuously, in parallel with development, and approved translations are delivered to the running application without a release. It is the localization counterpart of continuous integration and continuous delivery.

How is continuous localization different from traditional localization? In a batch workflow the strings wait: freeze, export, translate, import, redeploy. In continuous localization nothing waits for a cut: strings are detected as they are written, translated while development continues, gated by review rather than by a freeze, and delivered at runtime. The difference is where the strings sit between being written and being live.

What do you need to implement continuous localization? Keys that originate in code, one place where translators, machine translation and AI work on them with context, a review and publish gate, and a delivery path that reaches the running application without a redeploy, usually a CDN. Versioning and corpus-wide consistency checks are the two additions most teams need next.

Does continuous localization mean AI translation without human review? No. Continuous describes the flow, not the quality policy. AI fills the first draft so nothing waits; what is published is decided by checks, a quality-estimation score and human review where needed. Unreviewed machine output pushed straight to production is continuous and ungoverned.

Is continuous localization worth it for a small team? When translation is a release dependency: several deploys a week, more than a handful of languages, non-developers changing text, or fixes that must ship faster than the release cycle. A small team with two languages it reads itself can keep a batch process; runtime delivery is still usually worth having.