Software Localisation Platform Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does rebuilding the translator editor sink so many localisation projects?

The demo that gets a localisation platform funded is almost always the editor. It is the visible part, translators complain about the current one, and it is easy to imagine improving. So the first sprint builds a segment list with a source pane and a target pane, and four months later the team has a mediocre version of a commodity product while missing strings are still shipping every release.

This is specific to localisation because the pain is reported by translators and the cause sits in engineering. Translators say the tool is awkward and they have no context. The awkwardness is real and secondary. The absence of context is a pipeline failure: nobody captures screenshots, nobody validates placeholders before acceptance, and changes arrive after translation is finished.

The fix is a deliberate split written into scope. Own extraction, key validation, message format and placeholder checking, translation memory, the release gate and context capture. Keep your existing vendor's editor in phase one, whether that is Crowdin, Lokalise, Phrase, Transifex or Smartling, and connect to it. The editor is genuinely commoditised. The pipeline is where the value is and it is the part nobody sells you, because it has to live inside your build system and your test suite.

Teams that reverse this order ship an editor, keep the same defects, and conclude that tooling does not help. It was never the tool.

What goes wrong when translation memory and existing keys are migrated?

Translation memory is years of accumulated linguistic work and it exports in a form that looks complete and is not. Segment pairs come across. What frequently does not is the metadata that made them useful: which key each translation belonged to, which product area it came from, who approved it, and which terminology entry governed the choice of a term. A memory without those attributes still gives you fuzzy matches and stops giving you confident reuse, and translators notice within a week.

Key migration has a sharper failure. If your current setup used source strings as keys, there are no stable identifiers to migrate. Generating them mechanically produces keys nobody can read, and generating them by hand across thousands of strings is a project. Either way, the moment you switch, existing translations have to be re-attached to the new keys, and any mistake in that mapping puts the wrong text in front of users in a language your team cannot read.

Sequence it to reduce blast radius. Export the memory with its metadata before you cancel anything, and confirm the export contains attribution and terminology links rather than assuming it does. Migrate one platform first, ideally the one with the smallest catalogue, and hold the old system live in parallel. Validate every migrated key by rendering the target locale and comparing against the previous build rather than by comparing files, because a mapping error is invisible in a diff and obvious on a screen. Then freeze the naming convention in a linted rule so the new keys stay disciplined, since a convention enforced by good intentions lasts about a quarter.

Why do the pipeline and platform integrations break after launch?

Extraction breaks when the codebase changes shape. A team adopts a new component library, moves strings into a different helper, or introduces a framework that composes text at runtime, and the extractor silently stops seeing a whole surface. The catalogue looks smaller, nobody reads a smaller catalogue as a fault, and those strings ship untranslated.

The mobile side breaks on version drift. Once you deliver string bundles over the air, an old client can receive strings referencing screens it does not have, or miss a bundle and fall back to packaged resources that are three releases stale. Both look like translation quality problems to whoever reports them.

Vendor connections break on rate limits and on file format assumptions. A translation platform's export changes a field, an agency starts sending back a slightly different bilingual file, or a bulk sync during a release week hits a quota and half the locale arrives.

Guard all three by measuring, not by hoping. Track the extracted string count per platform per build and alert on an unexplained drop, which catches extraction regressions the same day. Version string bundles against app versions and sign them, with an aggressive cache and a safe fallback to packaged strings. And treat vendor sync as a job with retries, a partial failure state and an owner, rather than a script that runs in continuous integration and prints green when it exits.

What happens when right to left, plurals and approval gates are not covered?

Plurals are the failure that reaches users fastest. Storing a singular and a plural field is an assumption about Western European languages, and it produces wrong output in Polish, Arabic and Russian on the first sentence containing a count. The fix is not a bigger field list, it is ICU MessageFormat with plural categories taken from CLDR, and validation that rejects a translation whose categories do not match what the target language requires.

Placeholders are the failure that crashes things. A translator removes an interpolation, renames it, or reorders positional arguments because the target language demands a different word order, and the string renders wrong or throws. That check has to run before the translation is accepted, not at runtime in a customer's hands.

Right to left is the failure that gets deferred and then blocks a market. Proper support is a design and quality assurance effort as much as a code one: mirrored layouts, icon direction, mixed direction text with numbers and Latin product names inside Arabic or Hebrew sentences. Teams scope it as a flag and discover it is a redesign.

Approval gates matter where copy is legally reviewed. Regulated content needs a recorded approver, a version and an audit trail, and a string that changed after approval must not ship as approved. Build that as a state on the string rather than as a process people follow, because the process is exactly what fails during a release week.

Should you build custom or configure what you already own?

Buy if you ship to six or fewer locales on a monthly cadence from one platform. Crowdin is the most pleasant option at that size and has broad format support, and it will cost less than the engineering time for years. Lokalise and Phrase both have strong editors and sensible developer tooling if your team wants more control over the workflow. Transifex has been around long enough to handle awkward file cases. If translation is handled end to end by an agency who prefer their own tooling, Smartling pairs a platform with managed services and there is nothing to gain from building.

There is also a middle answer people skip. Most of the defects in this article can be fixed inside a bought platform by adding your own extraction discipline, ICU messages, a placeholder validator and a continuous integration check. That is days of work, not a project, and if it removes the pain then you have your answer.

Build when two or more apply. You ship to more than roughly twelve 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 and shows up as people reusing strings that should be separate or avoiding new keys. You run several platforms from one repository and want shared memory and terminology rather than fragmented vendor projects. You need approval gates with audit trails. Or context is your recurring quality problem and you already have test automation that could be capturing it.

How do hidden costs get into the quote?

Format and platform count is the first, and it is quoted as one line far too often. Extracting from iOS, Android, a web application and backend email templates is four paths with four sets of edge cases, and email templates carry markup that breaks naive extraction.

Right to left support is the second. A quote listing it as supported has usually priced the text direction attribute and not the layout mirroring, the icon handling or the quality assurance pass in a language your team does not read.

Context capture from the test suite is the third, and here the hidden cost is in your codebase rather than the developer's. Instrumenting the rendering layer assumes there is a rendering layer to instrument. If string lookup happens in twenty places with no shared path, that refactor is real work and it belongs in the estimate.

Then the quieter ones. Linguistic review of the first automated context run, because the first screenshots always reveal keys nobody knew were user facing. Vendor onboarding per translation supplier, since each has its own file exchange expectations. And the parallel period where the old platform stays live, which is a double subscription month nobody budgets.

What separates a build that works from one that fails here?

Ask a prospective developer 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. Anyone proposing a singular field and a plural field has not localised beyond Western Europe and will discover the gap in production.

Ask what happens when a source string changes by one character. The right answer distinguishes a copy tweak from a meaning change, shows the previous translation with a review flag in the first case, blocks in the second, and lets the person making the change declare which it is with the safe option as the default. A system that silently keeps stale translations is worse than no system, because it is confidently wrong.

Ask how they would attach screenshots to keys without asking anyone to take screenshots. If the answer does not involve your existing end to end tests, they have not understood why context capture always fails. Those runs already walk the product on every build, so recording which keys appeared on which screen and attaching the frame is nearly free, and comparing rendered width against container width flags strings likely to overflow in German or Finnish before a layout bug is filed.

Design the release gate so teams keep it enabled. Scope the check to strings changed in that release rather than the whole catalogue, and tier locales into blocking, warning and best effort. A gate that survives a hotfix is worth more than a stricter one that gets bypassed in month two. Then settle code ownership before kickoff. At Digital Heroes the client owns the code and the translation memory from the first commit, and that memory should never sit somewhere that can charge you to keep it.