SaaS Localization for Continuous Releases: Keeping Every Language in Step with Your Sprints
SaaS localization works with weekly releases when translation becomes part of the delivery pipeline: new and changed strings flow to translators as soon as they are stable, come back through the same repository, are tested in context and ship with the source. One translation memory and glossary keep every release consistent. DEMA Solutions localizes apps, help content and release notes for European software teams.
Who this guide is for
This guide is for the people who carry localization inside a product company that never stops shipping: product managers who promise features in several markets at once, engineering leads who own the build and the string files, and localization managers who sit between the two and a translation provider. It assumes you already know the basics of the software localization process, such as externalized strings and resource files, and focuses on what changes when the product releases every week or every sprint.
The questions here are operational: freeze or flow, how files travel, how to test what you cannot read, and what a release should cost. If your product is machine software, such as an HMI panel or a controller interface shipped with equipment, our guide to UI translation for HMI and machine software covers that case, which has its own constraints.
What SaaS localization means when you ship every week
In a traditional project, localization starts when the content is finished. A SaaS product is never finished: the interface changes in small increments, features are switched on for some customers first, onboarding flows are tested in variants and the help centre grows with every release.
Localization for SaaS therefore has a different unit of work. It is not a document but a change set: the strings added or modified since the last delivery, plus the help articles, notifications and release notes that describe them. That shift has three consequences. Speed comes from flow, not heroics: stable strings sent per sprint come back within the sprint, while a quarterly batch always ships late. Consistency depends on shared assets, because today’s translator may not be last month’s. And cost per release becomes the number that matters, because the budget is spent continuously.
String freeze or continuous flow: choosing a release model
There are two basic ways to fit translation into a release cycle, and most mature teams end up with a mix.
A string freeze sets a date before each release after which no user-facing text may change. Everything frozen goes to translation, comes back, is tested and ships. The model is simple, predictable and easy to budget. It suits products with monthly or quarterly releases, regulated content where every wording needs approval, and teams that are localizing for the first time. Its weakness is the gap it creates: if the freeze is three days before release and translation, review and testing need five, either languages ship late or the freeze moves earlier and developers lose flexibility.
Continuous localization removes the freeze as a single event. Strings are sent for translation as soon as they are marked ready, usually when a feature branch is merged or a pull request is approved, and translations flow back in the same rhythm. By release day, most of the text has already been translated and reviewed, and only last-minute changes remain. This is what agile localization means in practice: translation runs alongside development instead of after it.
Continuous flow needs more discipline than a freeze, not less. Strings must be genuinely stable before they leave the repository, otherwise the same sentence is translated three times while the wording settles. A “ready for translation” flag or a short waiting period after merge solves most of this.
The choice depends on how often you release, how much text changes, how quickly someone on your side answers translator questions and how much risk a missing translation carries. A useful compromise is continuous flow for interface strings and help content, with a short freeze for release notes and app store text, which are written last and read first.
Connecting your repository to the translation workflow
The most common bottleneck in continuous localization is not translation speed but file handling. When a developer exports strings by hand, emails them, waits, and copies the returned file back into the right folder, every release adds a day and a chance of overwriting something. The goal is that strings travel between your code repository and the translation environment without manual steps.
In the simplest pattern, a scheduled job exports new and changed strings from the main branch to a shared location, and translated files are returned there for the build to pick up. In a tighter setup, the translation environment is connected directly to the repository: it detects changes in the source language files, creates translation tasks and, when a language is complete, opens a pull request that your developers review and merge like any other change.
Whichever pattern you choose, three rules keep it safe. Target language files should be written only by the translation workflow, so that manual edits do not vanish in the next sync. Keys must be stable, because a renamed key looks like a deleted string plus a new one, and the existing translation is lost. Branch strategy should be agreed in advance: translating every feature branch wastes effort on features that never ship, while translating only the release branch leaves too little time, so many teams translate from the main branch after merge.
Ask your provider exactly how files reach them and how they return. Native handling of JSON, XML and platform string files, returned without broken keys or encoding changes, removes a whole class of build failures.
Translation memory and glossary across releases
A product that releases fifty times a year produces fifty small translation deliveries. Without one translation memory behind them, the product slowly accumulates three versions of “workspace”, two ways of addressing the user and inconsistent button verbs.
The translation memory is what makes continuous localization economical and consistent. Every approved translation is stored with its source, so when a string reappears, unchanged or slightly edited, the approved wording is reused and only the difference is translated. It should belong to you, not to the provider, and be exportable at any time in a portable format, which is why owning your translation memory matters more for SaaS products than for almost any other content.
The glossary does the same job for terms. A SaaS product has a small, intensely used vocabulary: feature names, plan names, object types, actions. Each needs one approved translation per language, plus a decision about which names stay in English. Product marketing often renames features, so the glossary needs an owner who updates it before new strings go out, not after users have seen the old term. Our article on keeping terminology consistent across translators and suppliers explains how to build and maintain such a glossary.
Style decisions belong alongside the glossary. Do you address users formally or informally in German, Italian and Spanish? Are buttons verbs or nouns? How are errors phrased? A short translation style guide per language answers these questions once, so that every translator and reviewer applies the same rules release after release.
Context, in-context review and localization testing
Interface strings are short and ambiguous. “Archive” may be a verb or a noun, and “Free” may refer to price or availability. In continuous localization the risk grows, because translators see a handful of strings per batch rather than a whole product. Context should travel with every change set: a comment on any ambiguous key, a note on what each placeholder contains, the maximum length where space is fixed and, ideally, a screenshot or a staging link.
Localization testing is the step that turns correct translations into a correct product. It has two parts. Functional checks confirm that the localized build works: no hard-coded English text, no truncated labels, no broken placeholders, correct date, number and currency formats, and no characters that fail to render. Many of these checks can be automated and run on every build. Linguistic testing, sometimes called in-context review, is done by a person who reads the language: they walk through the main user journeys on a staging environment and check that each translation fits its context, that terminology is consistent from screen to screen and that nothing reads like a fragment.
You do not need a full linguistic test of every language every week. A practical rhythm is automated checks on every build, in-context review of new features, and a full pass at major releases or new language launches. Every fix must go back into the translation memory, not only into the build, or the error returns with the next sync. Our guide on how to check a supplier’s translation quality describes how to set up a review step that produces usable feedback rather than personal preferences.
Mobile UI constraints: length, plurals, gender and right-to-left scripts
Mobile app localization adds constraints that web interfaces can often absorb: little room on screen, tab bar labels and dynamic text sizes.
Length. Translated text is often longer than English, and short strings expand the most proportionally: a two-word button may double in length in German or Finnish. Set character limits for strings in fixed spaces, test with the longest language early, and allow translators to propose a shorter wording rather than forcing an abbreviation nobody understands.
Plurals. English needs two forms (“1 file”, “2 files”). Many languages need more: Polish distinguishes one, few and many; Arabic uses up to six categories. Both major mobile platforms and the common message formats support plural categories, but only if developers use them instead of concatenating a number and a word.
Gender and agreement. In Romance and Slavic languages, and in German, adjectives, participles and sometimes verbs agree with the gender of the noun or the person. A string such as “{name} has been invited” may need different forms depending on who is invited. Where the product knows the relevant gender or object type, separate strings or select-style message formats let translators write correct sentences; where it does not, translators need to know so they can find a neutral wording.
Right-to-left scripts. Arabic and Hebrew mirror the layout: navigation, icons with direction and progress indicators flip, while numbers and embedded Latin text still run left to right. Right-to-left support is an engineering task that must be tested on real devices before translation can be judged.
App store listings, release notes and the help centre
The interface is only part of what users read. For a mobile app, the store listing is the first localized text a customer sees: the title, subtitle, short and long descriptions, keywords and screenshot captions. Each store sets its own character limits, and the listing is marketing copy, not interface text, so it needs a translator who writes persuasively within those limits and checks how people in each market search for apps like yours. Screenshot captions are easy to forget, because they live in image files rather than string files.
Release notes are written at the last minute and read by your most engaged users. Give them a short fixed translation window and reuse the interface terminology, so the feature named in the notes is the one users find in the app.
The help centre usually grows faster than the interface. Its articles are long, repetitive and updated often, which makes them a good candidate for machine translation post-edited by a qualified linguist, provided the engine works with your approved glossary and memory. Our machine translation post-editing services page explains how that decision is made per content type. Interface strings are a different case: they are short, ambiguous and visible on every screen, so they generally need a human translator from the start. Your marketing website follows yet another logic, which our analysis of website translation cost and options explores.
Measuring leverage and cost per release
In continuous localization, the per-word rate explains less of the budget than the composition of each release. Every change set contains some genuinely new text, some text that is similar to something already translated, and some text that is identical to an approved translation, for example a string moved to a new screen. The share of reused text is called leverage, and it is the single most useful number for understanding cost.
An illustrative example: a sprint changes 1,500 words of interface and help text. Of these, 700 are new, 500 are partial matches with existing translations and 300 are exact repetitions. Across six languages that is 4,200 new words to translate, 3,000 to adjust and 1,800 to verify, rather than 9,000 words translated from scratch. If the provider reports this split for every delivery, you can see why one sprint cost more than another, and you can spot problems early: a sudden drop in leverage often means keys were renamed or files were restructured, and the memory is no longer recognising text it already holds.
Three other factors move cost per release. Batch size: each delivery carries fixed effort for file handling and checks, so strings sent one at a time are expensive. Churn: text rewritten after translation is paid for twice. Testing scope: in-context review should be planned per release, not discovered after a complaint. Over a few months, per-release reports give product management a reliable basis for budgeting new languages and features.
The app localization process for one sprint, step by step
Here is how the app localization process typically runs inside a two-week sprint once the setup is in place.
At the start of the sprint, product and design agree which features will ship and which markets receive them. New terms, such as a feature name, are added to the glossary with their translations before any string is written.
During development, developers create keys with comments and character limits. When a feature branch is merged, the new and changed source strings are picked up automatically and translation starts. Questions from translators reach a named person on your team, who answers within a day.
Mid-sprint, translations return through the repository as a pull request or as files in the agreed location. Automated checks run on the build: placeholders, length, encoding and missing translations.
Before release, a reviewer walks through the new features in each language on the staging environment. Release notes, store texts and help articles are translated in a short fixed window. Any corrections are made in the translation environment so they are stored in the memory.
After release, the provider reports leverage per language, and recurring problems, such as missing context, are fixed for the next sprint.
Common pitfalls in continuous localization
Editing target files by hand. A developer fixes a typo directly in the German file; the next sync overwrites it, or worse, the fix never reaches the memory and the error returns in the next release.
Renaming keys during refactoring. To a translation system, a renamed key is a new string. Leverage drops, translations are redone, and approved wording may change without anyone deciding it should.
Letting each team or supplier keep its own memory. When the app, the help centre and the marketing site are translated separately, terminology diverges, and changing provider later means losing years of approved translations. If you are considering a move, our guide to changing translation supplier without losing your translation memory explains what to secure first.
Choosing a SaaS localization provider
The right provider for a continuous release cycle is the one whose way of working fits your pipeline, not simply the cheapest per word. These questions reveal most of what you need to know:
- How do files reach you and come back, and can you process our resource formats natively without breaking keys or placeholders?
- What turnaround can you commit to for a typical sprint batch, and how do you handle urgent strings?
- Which automated checks run before delivery, and is every translation revised by a second qualified linguist?
- Can our engineers or product managers review translations in context, and do their corrections update the memory?
- Who owns the translation memory and glossary, and can we export them at any time in a standard format?
- Do you report new, partially matched and reused text per release and per language?
The answers matter more than any certificate on a website, although a certified process such as ISO 17100 tells you revision by a second linguist is standard practice rather than an optional extra.
How DEMA Solutions supports SaaS and app teams
Our software and app localization services are designed for product teams that release continuously. New and changed strings are picked up and translated per release, matched to your sprint cadence rather than batched into occasional large projects. JSON, XML and other resource files are processed and returned in their original structure, without a manual extraction step and without broken keys. Automated checks look for broken variables, truncated interface strings and formatting errors before anything reaches a release build.
Translators are native technical linguists who work with software and developer terminology. Your engineers and product managers can review directly in the translation environment rather than in exported spreadsheets, so terminology fixes land in the memory immediately. The process is ISO 17100 certified, with a second qualified linguist revising every translation, as described on our quality page.
The translation memory, glossaries and term bases are built from your product’s own terminology and remain yours, exportable on request at any time in portable formats such as TMX and TBX. Leverage reporting shows how much of each release was reused. Beyond the interface, our teams in Italy, Serbia and Spain translate help centres and knowledge bases, API and developer documentation, release notes and changelogs, so the product and everything around it share one terminology.
Where TUBE fits
TUBE is our solution for products that release continuously, where every sprint means another localization cycle. Your glossary and translation memory control machine translation, every approved translation goes into a memory you own and can export, and leverage reporting shows how much of each update comes from text you have already approved.
Frequently asked questions
SaaS localization is the adaptation of a cloud software product, including its interface, onboarding, notifications, help centre and release notes, for users in other languages and markets. Because the product changes continuously, it is organized as a recurring flow of small updates rather than a one-off translation project.
Continuous localization sends new and changed strings for translation as soon as they are stable, instead of collecting them for a string freeze before each release. Translations return in the same rhythm, so every language can ship with the source language rather than weeks later.
Not necessarily for the whole product. Many teams let interface strings and help content flow continuously and keep a short freeze for the most visible or last-minute texts, such as release notes, pricing pages and store listings.
Functional checks confirm that the localized build works: no hard-coded text, truncation, broken placeholders or wrong formats. Linguistic testing checks, on real screens, that each translation fits its context and terminology is consistent.
Use one translation memory and one glossary for all product content, update the glossary before new terms appear in strings, make corrections in the translation environment rather than in target files, and keep string keys stable.
Budget per release rather than per year, based on the volume of new, partially matched and reused text in each language. Leverage reports from previous releases are the most reliable basis for estimating the cost of new features and new languages.
It often works well for help centre articles and documentation when it runs on your approved glossary and memory and a qualified linguist post-edits the output. Short interface strings and store listings usually need a human translator from the start.
Plan localization that keeps up with your releases
If your languages ship later than your source, or each release brings a new round of inconsistencies, tell us about your product, release cadence and target languages. We will look at your resource files and propose a localization flow that fits inside your sprints.
How can we help?
Tell us what you need and we’ll get back to you with the solutions.