Most localization breaks at the seam between engineering and translation. A new feature ships in English on Monday. The localized versions land four weeks later, by which time the team has already shipped two more features. That gap compounds. Users in non-English markets see stale UI. Marketing launches campaigns against landing pages that are still half English. Engineering ends up doing the same string twice.
Continuous localization is the model that closes that gap. New strings flow into translation as they are written. Translations come back in days, not weeks. The localized versions ship in the same release as the source.
This guide is for engineering leads and localization owners at product-led SaaS companies who want translation to run at the same velocity as the rest of the release pipeline.
KEY TAKEAWAYS
- Continuous localization runs translation in days, not weeks, by wiring it into the engineering pipeline.
- The model has three pieces: externalized strings, automation, and a translation workflow.
- A TMS with API support is non-negotiable. Manual upload and download breaks at PLG velocity.
- The hybrid AI plus human workflow runs continuously, not just on batches.
- A working pipeline can be set up in two to four weeks. Externalizing strings is the longer pole, not the automation.
What continuous localization actually means
Continuous localization is the practice of translating product strings as they are written, not in scheduled batches after release. Every push to the main branch that adds or changes a string triggers a translation workflow. When new strings land in English, the localized versions are queued, translated, reviewed, and merged back into the codebase within days.
This is different from waterfall localization. In a waterfall model, engineering ships a feature, then files a translation request, then waits for translations, then merges them in a second release. By the time the localized version goes live, the team has already shipped the next thing. The source language is always ahead of the target languages.
Continuous localization treats translation as part of the build, not a follow-up project.
Why the batch model breaks at product-led velocity
Product-led SaaS teams ship continuously. New features land in production every day. Strings change every sprint.
A batch translation cycle that takes four weeks to round-trip cannot keep up. Three problems compound:
- Localized versions are always behind the source. Users in non-English markets see stale UI.
- Engineering re-encounters the same strings. A button renamed in one sprint and renamed again in the next gets translated twice.
- Marketing campaigns launch on English-only landing pages because the translations are not ready.
The cost of batch localization is not just slow translations. It is a permanent feature parity gap between the source and target markets, and that gap costs conversion in every locale that lags.
The three pieces of a continuous localization pipeline
A working continuous localization pipeline has three layers. Each layer is independent of the others, but all three have to be in place for the model to work.
1. The i18n architecture
Strings are externalized from code, organized in locale files, and accessed via a runtime library. i18next, FormatJS, and react-intl are the common JavaScript choices. The same pattern exists for Python with gettext, Go with go-i18n, Swift with NSLocalizedString, and Kotlin with Android string resources. The exact library matters less than the principle: no hardcoded strings in the product surface.
2. The automation layer
When a new string lands in the main branch, a CI hook detects the change and sends the string to the translation management system. When translations come back, another hook merges them into a translation branch. This layer is typically a GitHub Action, GitLab CI job, or a CircleCI workflow.
3. The translation workflow
The TMS holds source strings, queues them for translation, runs them through the AI plus human workflow, and exposes them via API for the automation layer to consume. The workflow itself is the four-stage hybrid model: AI Draft, Human Refinement, AI QA, Final Human Approval.
These three layers together turn translation from a project into a pipeline.
Wiring translation into Git
The simplest pattern is a GitHub Action plus a TMS with API support. On every PR that touches a locale file, the action calls the TMS API and uploads new source strings. The TMS marks them for translation. As translations are completed, a webhook pushes them back as a PR against the main branch.
A more mature pattern uses a dedicated translation branch. Every new source string gets pushed to an i18n source branch. The TMS pulls from this branch on a schedule. Completed translations get merged back into a translations branch and rebased into main during the next release.
The key principle is automation. Manual upload and download from the TMS breaks at product-led velocity. If a person has to remember to push strings or pull translations, the pipeline will stall.
Choosing a translation management system
The TMS is the heart of the pipeline. Important things to evaluate before picking one:
- API-first. If the TMS does not have a programmatic API for upload, download, and status, it cannot support continuous localization.
- Native Git integration. GitHub or GitLab integration cuts setup time from weeks to days.
- Translation memory. Reuses past translations on repeat strings, which lowers cost over time.
- Workflow customization. AI Draft, Human Refinement, AI QA, and Final Approval stages should be configurable per content type.
- Linguist management. The TMS should track who translates which language and surface linguist performance in your dashboards.
Common picks in 2026 include Lokalise, Crowdin, Phrase, and Smartling. Platform partners that combine TMS with managed services, such as NexTranslate, fit teams that want one vendor to own both the pipeline and the linguist pool.
The hybrid AI plus human pass that does not slow you down
The continuous part of continuous localization does not mean skipping quality. It means running the hybrid AI plus human pass on every batch instead of every release.
The four-stage workflow runs in less than 24 hours for most string batches when the pipeline is set up correctly. For a sprint that adds 50 to 100 new strings, the round trip is small enough that translations land within the same release cycle.
This is the difference between continuous localization and AI-only autotranslation. Autotranslate is fast but inconsistent. Continuous hybrid translation is fast and reliable. The full reasoning for the hybrid model is in the SaaS localization playbook.
Continuous quality: LQA in a flow, not a batch
Linguistic Quality Assurance in a continuous model is sampled, not exhaustive. Every release pulls a sample of new strings and runs them through a senior reviewer. Error rates per 1000 words feed back into the linguist pool. Linguists whose error rate drifts get retrained or rotated out.
Three signals to watch on a continuous LQA program:
- LQA error rate per 1000 words, trending week over week, by locale.
- Time to publish for new strings, by locale and surface.
- Customer-reported translation issues, opened as support tickets in the target language.
If error rates spike, the answer is not to slow down the pipeline. It is to investigate which linguist or AI model is drifting and adjust.
Common engineering objections, and how to answer them
Engineering teams push back on continuous localization for predictable reasons. Three of the most common, and how to address them in a single sentence each:
“We do not have time to externalize all strings”
Do it incrementally. Externalize only the strings that change. Hardcoded strings that have not been touched in two years can wait. New code follows the rule from day one.
“Translation branches will conflict with feature branches”
Keep translations on a separate branch and rebase during release. The translation branch never blocks feature development. Merge conflicts on locale files are easy to resolve because the source language file is the only one engineers edit.
“We do not want to add a TMS dependency”
A TMS is a build dependency the same way a CI provider is. It does not affect runtime. The flexibility gained from automated translation outweighs the cost of taking on the dependency.
Sample implementation: GitHub Actions, i18next, and a TMS
A working setup looks like this:
- Source code in GitHub. Strings externalized in locales/en.json using i18next.
- A GitHub Action runs on every push to main. It diffs locales/en.json against the previous version and posts new strings to the TMS API.
- The TMS runs the strings through AI Draft, Human Refinement, AI QA, Final Approval.
- A webhook from the TMS triggers a second GitHub Action that opens a PR against main with the new translations in locales/es.json, locales/de.json, locales/pt-br.json.
- The translation PR is merged in the next release.
name: Localize strings
on:
push:
branches: [main]
paths: ['locales/en.json']
jobs:
upload:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Upload new strings to TMS
run: |
curl -X POST https://api.tms.example/strings \
-H "Authorization: Bearer $TMS_TOKEN" \
--data-binary @locales/en.json
env:
TMS_TOKEN: ${{ secrets.TMS_TOKEN }}
Total elapsed time from English landing to all locales in production: typically one to two days for the hybrid workflow, plus the release cadence. For most teams shipping a weekly release train, that means localized strings land in the same week as the source.
Frequently asked questions
What is continuous localization?
Continuous localization is the practice of translating product strings as they are written, with automation wiring engineering to a translation management system. Translations land in production within days of the source language, not weeks.
How is continuous localization different from machine translation?
Machine translation is one stage of a localization pipeline. Continuous localization is the broader system that wires that stage and the human review stages into engineering workflows so translations ship continuously.
Do I need a TMS for continuous localization?
Yes. The TMS is the system of record for source strings, translations, translation memory, and the linguist workflow. Trying to run continuous localization without one means manual coordination that breaks at scale.
How long does it take to set up continuous localization?
A working pipeline can be set up in two to four weeks for most teams. The longer pole is usually externalizing strings, not the automation. Teams with i18n already in place can be up and running in a week.
Will continuous localization slow down engineering?
When set up correctly, no. The translation workflow runs in parallel with engineering and does not block release. The pipeline absorbs new strings without engineering intervention beyond the initial setup.
Conclusion: translation as part of the build
Continuous localization is the model that closes the parity gap between the source language and target markets. It is built on three pieces: externalized strings, automation, and a translation workflow that runs continuously. None of those pieces is exotic. What is new is wiring them together so translation is part of every release, not a separate project.
At NexTranslate, we work with engineering teams to wire the hybrid AI plus human workflow into their CI so multilingual product updates ship at the same velocity as the source language. The four-stage workflow runs continuously, the TMS holds the pipeline together, and the LQA program runs in a flow rather than a batch.
If your team is shipping in multiple languages and the localized versions keep falling behind, NexTranslate can help.
Wire translation into your release pipeline.
NexTranslate runs the hybrid AI plus human workflow inside your CI so multilingual updates ship at the same velocity as the source language.
Written by: Karuppusamy Arunachalam, NexTranslate
Published: May 2026 · Filed under Product and Technology
