Software Localisation and Continuous Translation Platforms: Why Do Missing Strings Still Ship in Every Release?

Why localisation breaks precisely where release engineering meets language

Release week. An engineer renames a settings label and a designer shortens a button. Both are one line changes, both are correct, and both silently orphan a translated string in 18 languages. The localisation manager finds out on Thursday when a German QA tester screenshots a button reading in English inside an otherwise translated screen. Meanwhile a plural in Polish renders wrongly because the source used a two form message and Polish needs more, and an Arabic layout breaks because nobody tested a right to left build since the last redesign.

None of that is a translation quality problem. Your translators did excellent work. It is a pipeline problem: strings are extracted late, context never reaches the person translating, changes arrive after translation is complete, and no gate exists between an incomplete locale and a production build. Every localisation team eventually reaches the same conclusion, which is that the hard part was never the words.

What Lokalise, Phrase, Crowdin, Transifex and Smartling actually leave you doing

These are good products and most teams should start with one. Lokalise and Phrase both have strong editors and sensible developer tooling. Crowdin is the most pleasant for smaller teams and has broad format support. Transifex has been around long enough to handle awkward cases. Smartling pairs a platform with managed translation services and suits companies who want the whole thing handled.

The recurring gaps are three. Context: every one of them will hold a screenshot against a key, and in practice almost nobody captures those screenshots, because it is manual work that competes with shipping. So translators guess whether a four letter string is a noun or a verb, and you find out in a bug report. Gating: they integrate with your repository and can open pull requests, but the enforcement that a release cannot proceed with an incomplete blocking locale sits in your CI, and you build that yourself regardless of which vendor you pay. Economics: pricing is generally driven by hosted keys, words or seats, which means adding a language or shipping more often increases the bill in a way that quietly shapes engineering behaviour. Teams start reusing strings that should be separate, avoid adding new keys, or exclude a platform from the system entirely. When a tool's pricing changes how your engineers write code, the tool has become the problem. Splitting a monorepo into several vendor projects for web, iOS and Android also fragments translation memory and terminology across exactly the products that should be most consistent.

Problem 1: keys, plurals and placeholders decide everything

The foundational decision is whether the key is a stable identifier or the source string itself. Source as key is convenient for a week and then a copy edit to a sentence orphans every translation of it. Stable keys need discipline and a naming convention nobody enjoys, and they are correct.

A build enforces this at extraction. Strings are extracted from source at build time, keys are validated against your convention, duplicates are reported, and orphaned keys are detected as part of the same run. Messages parse as ICU MessageFormat so plural and select forms are structured data rather than prose. Placeholder validation catches the failure that causes production crashes: a translator who removed or renamed an interpolation, or reordered positional arguments in a language whose word order demands it. That check has to run before the translation is accepted, not at runtime in a customer's hands. The plural rules themselves come from CLDR categories rather than from anyone's assumption that every language has singular and plural, which is the assumption that breaks Polish, Arabic and Russian.

Problem 2: context is the whole job, and nobody has time to capture it

A translator seeing the word Post has no way to know if it is a verb on a button, a noun for a piece of content, or a postal reference. Style guides do not solve this. Screenshots do, and manual screenshot capture never survives contact with a release schedule.

What a build does, and this is the strongest argument for owning the platform: harvest context automatically from your existing end to end test suite. Your Playwright or Cypress or XCUITest runs already walk the product on every build. Instrument the rendering layer so each run records which keys appeared on which screen, capture the screenshot, and attach it to those keys automatically. Translators then see the actual screen, with the string highlighted, from the current build, without a human doing anything. Add the rendered width against the container width and you can flag strings likely to overflow in German or Finnish before anyone files a layout bug. No commercial platform can do this for you because it requires being inside your test infrastructure, which is exactly why it is worth building.

Problem 3: late string changes are normal and the pipeline pretends they are not

The idealised flow has a string freeze, then translation, then release. Real products change copy after the freeze because a legal review lands, a name changes, or someone finds a better word on Tuesday.

A build treats change as expected. Every string carries a version and a status per locale, and changing the source moves affected translations to needs review rather than silently keeping the old text or blanking it. The difference between those two behaviours matters: for a minor copy tweak you want the previous translation shown with a review flag, and for a meaning change you want it blocked. Let the person changing the string declare which it is, and default to the safe option. Then give reviewers a queue ordered by release urgency rather than a list of everything, so a late change to a blocking locale is visibly different from a tidy up in a locale that ships next month.

Problem 4: no gate between an incomplete locale and production

Most teams discover missing translations in QA, or in production, or from a user. The fix is unglamorous: a check in the pipeline that fails a build when a locale marked release blocking is below its completeness threshold for the strings changed in that release.

A build makes that check meaningful by scoping it to changed strings rather than to the whole catalogue, because a hard requirement for 100 percent across every locale gets disabled within a month by a team trying to ship a hotfix. Tier your locales: blocking, warning, and best effort. Blocking locales fail the build. Warning locales post a comment on the pull request. Best effort locales report weekly. That distinction is what makes the gate survive, and a gate that survives is worth more than a stricter one that gets bypassed.

Problem 5: mobile makes every string fix a store release

A wrong translation in a web app is a deploy. In a mobile app it is a store review cycle, and a bad string can sit in front of users for days. This is the point where teams start shipping English into a market rather than waiting.

What a build does: deliver string bundles over the air, with the app falling back to bundled resources when no update is available. Version the bundles against app versions so an old client never receives strings referencing screens it does not have, sign them, cache aggressively and fail safe to the packaged copy. It is a genuinely small piece of engineering that removes an entire class of release pressure, and it is available to you precisely because you own the pipeline rather than renting it.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A first release with extraction, key validation, ICU and placeholder checking, translation memory and terminology, the translator interface and the CI gate runs $50,000 to $110,000 and ships in 10 to 14 weeks. Adding automated screenshot context from your test suite, review and approval workflows, over the air delivery for mobile, machine translation pre fill with post editing, and vendor and cost management brings the total to $150,000 to $350,000 across 6 to 11 months.

What drives cost up: the number of distinct string formats and platforms, since iOS, Android, web and backend email templates all extract differently. Right to left support done properly, which is a design and QA effort as much as a code one. Regulated content needing legal approval gates with audit trails. And the number of external translation vendors, because each has its own file exchange expectations and invoicing.

What keeps cost down: starting with one platform and your blocking locales, and keeping your existing vendor's editor for translators in the first phase while you own extraction, validation and the gate. The pipeline is where the value is. The editor is the part that is genuinely commoditised.

Build versus buy, and when buying is right

Buy if you ship to six or fewer locales on a monthly cadence with one platform. Crowdin or Lokalise will cost less than the engineering time for years and you should spend that time on the product. Buy if translation is handled entirely by an agency who prefers their own tooling and your volume is modest.

Build when two or more apply. You ship to more than 12 locales on a weekly or faster cadence. Per key or per word pricing is visibly changing engineering behaviour, which is the clearest signal in this category. You run several platforms from one repository and want shared translation memory and terminology rather than fragmented projects. You need approval gates with audit trails for regulated or legally reviewed copy. Or context is your recurring quality problem and you have test automation that could be capturing it automatically and is not.

How to choose a developer

Ask how they would handle a plural in a language with more than two forms, and expect ICU MessageFormat and CLDR categories in the answer within a sentence. If they suggest a singular and a plural field, they have not localised anything beyond Western European languages.

Ask what happens when a source string changes by one character. Listen for versioned strings with per locale status and a distinction between a copy tweak and a meaning change. A system that silently keeps stale translations is worse than no system.

Ask how they would attach screenshots to keys without asking anyone to take screenshots. If the answer does not involve your existing test automation, they have not thought about why context capture always fails.

Ask who owns the code and settle it before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit. Your translation memory is years of accumulated linguistic work, and it should never sit somewhere that charges you to keep it.