Continuous Localisation: A Practical Guide for Agile Software Teams

Continuous localisation is a workflow where translation runs in parallel with software development, so the product stays release-ready in all supported languages at all times. New or changed strings are automatically sent for translation as developers commit code, and the translated versions are returned into the build before the next release.

If your team ships updates in one- or two-week sprints, continuous localisation is how you avoid a growing backlog of untranslated strings that eventually forces a choice between delaying the release or shipping a half-translated product.

This piece covers how the workflow actually runs, what you need in place before you start, what it means for translators and the teams working with them, and when a different approach makes more sense.

In this post:

How continuous localisation differs from batch and agile localisation

These terms get used interchangeably, but they describe different workflows with different trade-offs. The table below summarises the key differences.

The difference is easier to see visually. Agile localisation follows a circular cycle: planning, design, development, localisation, delivery, maintenance, then back to planning. Localisation sits as its own stage in that loop, which means the cycle has to pass through it before anything can ship. Continuous localisation looks more like an infinity loop: development and localisation run as two interconnected streams that feed into each other without a handoff point. There’s no stage where the team stops developing and starts localising. Both happen at the same time, and the product is release-ready at every point in the loop.

Batch (waterfall) localisation is the traditional approach. The development team finishes a version of the product, exports all the translatable strings, sends them to a translation team, waits for them to come back, integrates them, runs QA, and ships. This worked when software shipped once a quarter or once a year. It breaks down when you’re pushing updates every week.

Agile localisation syncs localisation with sprint cycles. Translation happens within each sprint rather than after the full release is built. The localisation team receives strings at the start of the sprint and returns translated versions before the sprint closes. This is a big improvement over batch, but it still creates a discrete translation step within each sprint, which means localisation has to be scheduled and tracked as a sprint task.

Continuous localisation removes the discrete translation step entirely. New or changed strings are automatically detected and pushed to translators as soon as developers commit code. Translated strings flow back into the build through the same automated pipeline. The product is always release-ready in every supported language, without anyone needing to manually trigger a translation handoff.

The practical difference shows up in how releases work. With agile localisation, you can release at the end of each sprint once the translation work is done. With continuous localisation, you can release at any point because the translations are always current. For teams practising continuous delivery (multiple deployments per day), this is the only model that keeps localisation from becoming a bottleneck.

What goes wrong without it

The case for continuous localisation is easier to understand through the problems it solves than through a list of benefits.

The patchwork product

Your development team ships a redesigned onboarding flow on Tuesday. The English version goes live immediately. The Spanish, French, and German versions still show the old onboarding because the new strings haven’t been translated yet. For the next two weeks, users in those markets see a product that’s visibly out of date compared to the English version.

This happens constantly in teams that batch their translations. The product ends up in a state where some screens are in the local language and others have reverted to English, or where the localised version is one or two releases behind. Users notice. It undermines trust, particularly in products where trust matters: fintech, healthtech, anything that handles personal data.

When we worked on Curve’s localisation across 6 European markets, the sprint cadence meant that batching translations would have left some markets permanently behind. Financial products can’t afford that inconsistency. A user whose transaction notifications suddenly appear in English instead of their language starts wondering what else has changed.

The growing backlog

Without an automated pipeline, every new string needs to be manually identified, exported, sent to translators, tracked, received, integrated, and tested. When the team is shipping fast, the strings accumulate faster than the translation process can handle them. The backlog grows. Eventually someone decides to skip translating “minor” updates, and the product gradually drifts further from full localisation in each language.

This is sometimes called “localisation debt,” and like technical debt, it compounds. The longer you leave it, the more expensive it is to fix.

Translator context disappears

In a batch workflow, translators can receive a complete set of strings with some sense of how they relate to each other. In a chaotic ad-hoc workflow (the common middle ground between batch and continuous), translators receive strings in random order, often without knowing where they appear in the product. “Cancel” could mean cancel an order, cancel a subscription, or close a dialogue box. Without context, the translator guesses. Without continuous localisation infrastructure (which typically includes context screenshots and string descriptions), guessing is all they can do.

Version conflicts and merge headaches

When translation files are managed manually, version conflicts are inevitable. A developer updates a resource file while a translator is working on the same file. The translator’s changes overwrite the developer’s, or vice versa. In a continuous pipeline with TMS-repo integration, this doesn’t happen because the TMS is the single source of truth for translations, and the integration handles merging automatically.

How the workflow runs in practice

The continuous localisation pipeline has four stages. Most of it is automated once the infrastructure is set up.

1. Developer commits code with new or changed strings

The developer writes code as usual, with all user-facing text stored in resource files (not hardcoded). When they push to the repository, the new or changed strings are automatically detected by the TMS integration.

2. Strings are pushed to the TMS

The Translation Management System (Phrase, Crowdin, Lokalise, or similar) is integrated with the code repository via API or CLI. When new strings land in the repo, the TMS pulls them in automatically. The translator sees them in their dashboard, ideally with context: a screenshot of the screen where the string appears, a description of what it does, and any relevant notes from the developer or a previous translator.

3. Translators translate and review

This happens in the TMS, not in spreadsheets or email attachments. The translator works on the new strings, drawing on:

• Translation memory (TM): a database of previously translated strings that automatically suggests matches for repeated or similar text, saving time and ensuring consistency
• The project glossary: approved translations for key terms that should always be rendered the same way
• Machine translation suggestions: pre-translations from MT engines that the translator can accept, edit, or reject
• Context screenshots and descriptions: visual and textual context attached to each string

If the string is ambiguous, they flag it within the TMS rather than sending an email that might not get answered before the deadline.

4. Translated strings are pushed back to the repo

Once the translation is reviewed and approved, the TMS pushes the translated resource files back to the code repository. The build now includes the updated translations. No manual file handling. No one needs to remember to copy a spreadsheet into the right folder.

Here’s how a typical sprint looks with continuous localisation integrated:

When what3words scaled from a handful of languages to over 60, they moved from Google Sheets to Phrase integrated with Figma for design context. Their published case study describes a workflow where translators can see context screenshots from Figma alongside every string, which reduces ambiguity and speeds up the process. Launching a new language now takes about five to six weeks covering roughly 1,000 strings, because the infrastructure handles the logistics and translators can focus on the language.

What you need in place first

Continuous localisation requires a few things to be working before you flip the switch. Attempting it without these foundations creates more problems than it solves.

Internationalised code

Every user-facing string needs to be externalised into resource files, not hardcoded into the application. This sounds obvious, but it’s the single most common blocker. If your codebase has English strings scattered throughout the source code, you need to extract them before continuous localisation can work.

What internationalised code looks like in practice:

• All user-facing strings stored in locale-specific resource files (e.g. en.json, es.json, de.json)
• No string concatenation (building sentences by joining fragments programmatically, which breaks in languages with different word order)
• Placeholder support for variables (e.g. “You have {count} new messages” rather than “You have ” + count + ” new messages”)
• Support for pluralisation rules (English has two forms, Arabic has six, Polish has four)
• Layouts that accommodate text expansion (up to 35% for English-to-German, per IBM’s globalisation guidelines)
• RTL (right-to-left) layout support if you’re targeting Arabic, Hebrew, or other RTL languages

Our internationalisation guide covers the technical specifics in full.

A TMS that integrates with your stack

The TMS is the hub. It needs to connect to your code repository, and ideally to your design tool so that translators can see where strings appear.

We’ve compared the main TMS options in our TMS comparison guide. The right choice depends on your stack, your team size, and how many languages you support. The wrong choice is no TMS at all, which usually means managing translations in spreadsheets. That works when you have a few hundred strings in two languages. It collapses when you hit a few thousand strings across five or more languages.

A glossary and style guide

This is the most underrated prerequisite. A glossary defines how key terms should be translated in each language. “Dashboard” might stay as “dashboard” in some languages and become a local equivalent in others. “Account” in a fintech product needs to translate to the specific financial term in each market, not a generic word that could also mean a social media account.

A style guide defines tone, formality level, and conventions:

• Should the app address the user as “tú” or “usted” in Spanish?
• Should error messages be formal or conversational?
• How should brand names and feature names be handled? Translated, transliterated, or left in English?
• What’s the approved translation for recurring UI elements like “Settings,” “Save,” “Cancel”?

Without a style guide, every translator makes their own call, and the product ends up with an inconsistent voice. The glossary and style guide together are what make translation consistent across strings, across translators, and across time.

Translators who know the product

In a continuous workflow, translators receive small batches of strings with limited surrounding context. A new feature might generate 15 strings that arrive in the TMS without any explanation of what the feature does. If the translator doesn’t know the product well enough to infer context, they’ll produce translations that are linguistically correct but functionally wrong.

The best continuous localisation setups use a small, consistent team of translators per language rather than a rotating pool. Those translators build up product knowledge over time, which makes them faster and more accurate. It also means they can spot inconsistencies that a new translator wouldn’t notice.

The context problem

This deserves its own section because it’s the biggest quality risk in continuous localisation, and the one most teams underestimate.

When a translator works on a batch of strings from a complete feature, they can see how the strings relate to each other. They understand the flow. They know that “Save” on this screen means “save your preferences” and “Save” on that screen means “save to your collection.”

In a continuous workflow, strings arrive individually or in small groups. The translator might see:

• “Save”
• “Your changes have been saved”
• “Undo”

Without knowing which screen these appear on, the translator is working blind. “Save” in Spanish could be “Guardar” (save a file) or “Ahorrar” (save money). The correct choice depends entirely on context that the translator doesn’t have.

The solutions are all about providing that missing context:

what3words’ Figma integration with Phrase is a good example of this done well. Translators working on the app can see exactly where each string appears in the interface, alongside questions and answers from translators who worked on previous languages. That accumulated context is one reason they can onboard a new language in five to six weeks.

File formats and resource files

Different platforms use different file formats for storing translatable strings. Your TMS needs to support the formats your product uses.

A few things that affect how smoothly continuous localisation runs:

• One resource file per language, not one giant file for all languages. Most frameworks enforce this, but some legacy setups cram everything into a single file, which causes merge conflicts.
• Avoid string concatenation. Building sentences by joining fragments (e.g. "Welcome to " + city_name + ", enjoy your stay") breaks in languages where the word order differs. Use placeholders instead: "Welcome to {city_name}, enjoy your stay".
• Handle pluralisation properly. English has two plural forms (one item, two items). Other languages have more: Polish has four, Arabic has six. Your resource file format needs to support plural rules, and your TMS needs to present all plural forms to the translator.
• Keep keys stable. If you rename a resource key, the TMS treats it as a new string and the existing translation is lost (or needs to be manually reconnected). Rename keys only when the meaning of the string has changed.

Team roles in a continuous localisation workflow

Continuous localisation requires collaboration across roles that don’t traditionally interact much. Here’s who’s involved and what they’re responsible for.

In smaller teams, several of these roles may be handled by the same person. The localisation manager role, in particular, often falls to a product manager or a senior translator. What matters is that the responsibilities are assigned, not that each one has a dedicated person.

What this means for translators (and the teams working with them)

Continuous localisation changes the translator’s role in ways that matter to both sides.

For product and development teams

Your translators are no longer operating downstream. They’re embedded in your release cycle. In practice that means:

• Give translators access to the product itself: a staging environment or at least a demo account so they can see strings in context
• Include them in release planning: a brief heads-up about upcoming features means translators aren’t blindsided by strings they can’t make sense of
• Set up a direct communication channel: Slack or Teams, not email routed through a project manager
• Write string descriptions: even a five-word note (“error message when payment fails”) saves the translator significant guesswork
• Attach screenshots to every new string: if your TMS supports Figma integration, automate this

Turnaround expectations change too. In a batch workflow, you give translators a week to handle 500 strings. In a continuous workflow, you might send 20 strings on Monday, 8 on Wednesday, and 35 on Friday. The translator needs to be available for regular small batches rather than occasional large ones.

This affects how you contract and pay for translation work:

For continuous localisation, hourly or retainer arrangements tend to work better than per-word pricing, because the value isn’t in the volume of words translated but in the speed and consistency of the output.

For translators

Working in a continuous workflow requires a different set of habits compared to batch translation:

• You’ll receive strings with less context. Be proactive about asking questions and flagging ambiguities early rather than making assumptions that might need correcting later.
• You need to know the product well. Not at a surface level, but well enough that when you see a string like “Go back” you can infer from the key name and surrounding strings whether it means navigating to a previous screen or Curve’s “Go Back in Time” feature (which lets users retroactively change which card they paid with).
• The pace is different. Rather than receiving a large brief and managing your own schedule over a week, you’re responding to smaller batches on a tighter cadence. Some translators prefer this rhythm. Others find it hard to manage alongside project-based work. Dedicated time blocks help.
• TMS fluency matters. Working effectively in a TMS, using translation memory and glossaries, and knowing how to flag issues within the platform (rather than over email) are practical skills that affect both speed and quality.

Measuring whether it’s working

Once your continuous localisation pipeline is running, you need to know whether it’s actually delivering results. These are the metrics worth tracking.

The most important of these is time to release parity. If your English release ships on Tuesday and the French version isn’t ready until the following Monday, you have a five-day gap. Continuous localisation should shrink that gap towards zero. If it’s not shrinking, something in the pipeline is bottlenecking, whether it’s translator availability, missing context, QA delays, or integration issues.

Track these monthly. Share them with the development team, the translation team, and product management. The numbers will tell you whether the investment in continuous localisation infrastructure is paying off, and where to focus improvement efforts.

hen continuous localisation is overkill

Continuous localisation adds infrastructure and process. For some products and some situations, that overhead isn’t worth it.

The question to ask is whether the cost of falling behind (untranslated strings, patchwork UX, user trust erosion) exceeds the cost of setting up and maintaining the pipeline. For SaaS products with weekly releases and five or more supported languages, it almost always does. For everything else, do the maths first.

Common mistakes

These come up repeatedly in teams transitioning to continuous localisation. They’re all avoidable.

Automating the pipeline but not the context

You set up the TMS integration with your repo. Strings flow automatically. But you skip the screenshots, the string descriptions, and the glossary. The pipeline works perfectly at moving text around, and the translations come back fast. They’re also wrong 15% of the time because the translators had no context. Automation without context is speed without accuracy.

Using a rotating pool of translators

Continuous localisation relies on translators who know the product. Every time you swap in a new translator, they need to learn the terminology, the tone, the product logic. That learning period produces inconsistent translations. A pool of five translators rotating through your project will produce five slightly different voices in the same language. Stick with one or two translators per language and build a long-term relationship.

Skipping linguistic QA because the pipeline is fast

The speed of continuous localisation can create a false sense of confidence. Strings go out, translations come back, they’re in the build. But nobody checked whether the translated string actually makes sense on the screen where it appears. Visual QA (checking that translations render correctly in the UI) and linguistic QA (checking that translations read correctly in context) still need to happen. They can happen faster in a continuous workflow, but they can’t be skipped.

Treating every string as equally urgent

In a continuous pipeline, every new string gets sent for translation at the same priority. But a tooltip deep in the settings menu and a headline on the onboarding screen don’t have the same urgency. Tagging strings with priority levels lets translators know which ones need to be done before the next release and which ones can wait for the next cycle.

Not having a glossary

Without a glossary, the same translator (or different translators on different days) will translate the same term multiple ways. In a batch workflow, this gets caught during review. In a continuous workflow, the inconsistency accumulates across weeks and months until someone notices that “workspace” has been translated as “espacio de trabajo” in half the screens and “área de trabajo” in the other half. The glossary prevents this. Build it before you start.

Moving from batch to continuous

If you’re currently doing batch localisation and want to transition, here’s a sequence that works. It typically takes two to three months for a team supporting three to five languages, longer if you’re starting without a TMS or without internationalised code.

Phase 1: Foundation (weeks 1-2)

• Move to a TMS if you’re managing translations in spreadsheets
• Build your glossary (start with 50-100 key terms per language)
• Create your style guide for each target language
• Audit your codebase for hardcoded strings and string concatenation

Phase 2: Pilot (weeks 3-6)

• Connect the TMS to your repo for one language only
• Let the strings flow automatically for two to three sprints while you watch for issues
• Are the right strings being picked up? Are context screenshots working? Is the translator getting enough information?
• Run parallel workflows: use the continuous pipeline alongside your existing batch process, and compare output quality

Phase 3: Expand (weeks 7-10)

• Add languages one at a time, fixing language-specific issues as you go
• Each language might have different needs: different translators, different glossary challenges, different character expansion issues
• Set up priority tagging so translators know which strings are release-critical

Phase 4: Refine (ongoing)

• Revisit the glossary and style guide after the first month; terms that seemed obvious will have caused confusion
• Start tracking metrics (translation turnaround time, coverage, QA defect rate)
• Review translator feedback and adjust the workflow based on what’s working and what isn’t
• Consider adding Figma integration if context is still a pain point

The investment pays back quickly once the pipeline is running, because every future release ships fully localised without manual intervention.

If you’re evaluating whether continuous localisation makes sense for your product, or if you need help setting up the workflow, we’d be happy to talk through your specific situation.

Frequently asked questions about continuous localisation

What is continuous localisation? Continuous localisation is a workflow where software content is ready for release in all supported languages at all times during development. As new strings are created or changed, they go immediately to translators and back into the build, rather than accumulating in a batch for a periodic translation sprint. It is a subset of agile localisation, where localisation runs in parallel with development from the start.

What is the difference between agile localisation and continuous localisation? Agile localisation means working in iterative sprints alongside the development team, localising in 1 or 2-week cycles rather than waiting for a completed product. Continuous localisation takes this further: the emphasis is on keeping the product localised at all times, with no deliberate pause to create a “localisation build.” Agile is the broader methodology; continuous is the most integrated form of it.

Why do SaaS teams need continuous localisation? Because SaaS products ship updates frequently, sometimes daily, and every UI change or new feature needs to be localised before it goes live. Teams that treat localisation as a batch process inevitably fall behind their release cycle. The result is a patchwork product where some screens are in the local language and others revert to English because the localisation queue didn’t keep up. Users notice, and the trust damage compounds over time.

What does a continuous localisation workflow involve? Planning sets up language-specific workflows and automation. Design establishes an internationalisation framework that can support multiple languages. Development creates localisable strings from the start. Localisation runs in parallel, with translators and developers communicating directly. Delivery prepares the localised content for release with QA checks. Maintenance monitors performance and updates translations as needed. Then the cycle repeats.

What technical requirements does continuous localisation need? Internationalised code is the foundation: strings need to be externalised into resource files rather than hardcoded. A translation management system (TMS) integrated with the repository handles automatic string handoff and return. Translators need enough product context to work efficiently without seeing the full page each time, which is why TMS tools with design tool integration (such as Phrase connected to Figma) make a significant difference. QA needs to be built into the sprint cycle rather than saved for after release.

Is continuous localisation always the right approach? For SaaS products with frequent releases and multiple supported languages, it is essentially the only viable approach. For desktop software that ships major versions once or twice a year, a batch approach still works fine. Mobile apps sit somewhere between the two, so a hybrid can work: continuous for core UI strings, batched for marketing content and help articles that change less often.

What does continuous localisation require from translators? Translators in a continuous workflow need quick turnaround times, a strong understanding of the product (since strings often arrive without full context), the ability to work with automation tools and TMS platforms, and enough technical knowledge to handle software-specific conventions like placeholder syntax and character limits. The collaboration between translators and developers is ongoing rather than a handoff at the end of a project.

---

Author: Maria Scheibengraf

Maria Scheibengraf is an award-winning marketer, multilingual SEO specialist, and English-to-Spanish translator specialised in software, including SaaS, martech, and fintech. She is the co-founder and Operations Manager of Crisol Translation Services and the author of The SEO Translation Bible.