Localization breaks release deadlines: where strings get lost
"Save" is hardcoded directly into the screen markup, the string has no key, and it does not appear in the dictionary.
A month later the wording is changed, the edit goes into the code, but the translation remains from the old version — when adding a language, this string is simply not found.
The loss is silent: the interface is already in testing, while some screens in the new language remain as before.
Then keys diverge. The same meaning lives under three names, translators receive them as different strings and translate them differently — for one button in the interface, "Delete", "Erase", and "Remove" appear.
UI localization turns into manual reconciliation: no one knows how many strings actually exist in the product and which of them are no longer used.
Release of a version starts to depend on an external translation cycle. Strings are sent after code freeze, returned in parts, and edits do not make it by the date.
Losing strings at release becomes the norm: something ships untranslated, something is translated for an old version of the text and diverges from the screen logic.
The timelines for launching a new language are then measured not in days of translator work, but in weeks of approvals and searching for hardcoded places.
We start with an i18n audit: we inventory strings, extract hardcoded text, consolidate duplicate keys, and configure the build so that a missed translation stops the release rather than surfacing in prod.
After moving text into resources, a new language is a set of dictionaries and checks, not edits in code. We'll break down how this is closed.
What a controlled translation loop delivers: effect in metrics
The translation loop is measured not by the number of languages in the switcher, but by the time to release of the localized version and the share of strings that passed without manual editing. Below is what changes in metrics when strings, translation memory, and checks work in one process.
Time to release a version in a new language
Strings go to translation when a branch is merged: export, matching against translation memory, and return of completed segments happen without manual file assembly.
A new language is set up without a separate release cycle — the version ships in days instead of weeks, and a release in an already set-up language goes together with the main build.
Share of automated translation
Translation memory accumulates confirmed segments, so from release to release the share of strings closed without a translator grows: exact matches — fully, fuzzy matches — with edits to a couple of words.
On a mature project, 80–90% of the volume is closed automatically; new sections and legal texts remain manual.
Classes of localization defects
Localization errors are more often structural than semantic: truncated UI, string concatenation, incorrect plural and date forms, untranslated placeholders.
We take inflection rules and formats from the Unicode CLDR standard, truncation is caught by an automated test on the longest string in the language, and placeholders are blocked at build time.
Volume of manual edits
The share of segments that an editor edits after machine translation falls from a third to single-digit percentages: disputed places are collected into a review queue by confidence threshold, rather than spread across the entire text. The glossary fixes terms, and the same edits do not return from release to release.
Localization modes: manual, automatic, hybrid
The localization mode is a consequence of three parameters: text volume, frequency of edits, and cost of an error in terminology. If strings change every release and there are several languages, a manual pass over the entire corpus does not pay off — only the delta is translated.
| Option | When it fits | Limitations |
|---|---|---|
| Manual | Regulatory and legal texts, marketing where tone matters | Scales poorly with frequent releases |
| Automatic with post-editing | Large volumes of similar UI strings, reference materials | Without a glossary it loses consistency; native-speaker review is needed |
| Hybrid | Product UI, documentation, frequent multilingual releases | Requires configured translation memory and quality control |
What it looks like in a project
The hybrid mode is built around translation memory: matched strings are inserted automatically, new ones go to machine translation with editing.
The terminology glossary fixes product names and prohibited variants, so "personal account" does not turn into three different terms on three screens.
Before that, we do an i18n audit: we look for strings concatenated from fragments, hardcoded word order, and places where translation length breaks layout. A fix at the code level takes minutes; a fix after release takes weeks of review across all languages.
Translation post-editing is divided into light and full: service labels only need terminology and placeholder checks, while user scenarios should read as finished text.
The metric is one — the share of strings returned from machine translation with edits; as translation memory fills up, it falls.
Implementation stages: from i18n audit to release acceptance
Localization breaks not at translation, but earlier — at strings hardcoded directly in code, concatenations like "file + number + ending", and markup inside templates.
Until it is clear how much text lives in the interface, emails, mobile notifications, and tooltips, any automation multiplies chaos. Below is the work route after which translation becomes a regular step of the build, not a manual race before release.
-
String inventory. We collect text resources from repositories, templates, screens, system emails, and notifications. The result is a registry: source, screen, state (translated, outdated, duplicate). It also becomes the basis for estimating volume.
-
Localization key scheme. We design namespaces and naming rules: a key is tied to a screen or entity, not to the text itself or a sequence number. Then the source-language wording can be edited without re-releasing translations.
-
Extracting strings from code. We replace literals with keys and break concatenations into templates with placeholders — in another language, word order cannot be assembled otherwise. Separately, we mark up plurals, cases, and genders.
-
Configuring the loop. We connect the translation storage, automatic export at build time, and control that no key without translation goes into the release. The fallback language is set explicitly, rather than left to default settings.
-
Test language and pseudo-locale check. We run the interface on a test language with pseudo-localization: artificially lengthen strings and add diacritics. This catches button overflows, truncated text, and hardcoded block widths before the native speaker sees them.
-
Release acceptance and handover to the team. We fix a checklist: key completeness, absence of untranslated content, correctness of date, number, and currency formats, and search working over localized content.
We hand over schemes, validation scripts, and the update procedure — support remains with your team.
Localization artifacts: what remains with your team
Translation without accompanying documents lives until the next release: strings are edited directly in files, terms diverge, and acceptance turns into a debate about taste.
Therefore we deliver the localization loop as a package that remains in your repository and does not depend on us.
- String map — a table "key → file → screen or scenario → status → owner": it immediately shows what is not yet localized and who closes the gap.
- Glossary — terms with part of speech, case, and prohibited synonyms, connected to translation memory: a disputed term is decided once, not in every release.
- Key policy — naming rules, prohibition on concatenating a phrase from fragments, requirements for placeholders and number agreement.
- Loop settings — extracting strings from code, connecting translation catalogs, automated checks at build time.
- Translation acceptance procedure — what counts as a blocking defect, who accepts and by which checklist returns it for revision.
- Audit report — before and after snapshot: share of untranslated strings, duplicates and "dead" keys, strings hardcoded in code, lost placeholders.
Each artifact is embedded in the build, rather than lying around as a separate document: an untranslated string or a discrepancy with the glossary slows the release until the version ships. After one cycle, your team runs the localization loop on its own.
Case: how manual edits were reduced and version releases accelerated
The product shipped in four languages, and strings for translation were collected manually: developers exported tables, translators returned them, and by that time the keys had already diverged.
At each iteration, 28-30% of strings had to be edited by hand — some lost placeholders, some did not fit in a button, some remained in the source language.
First, we brought order to the catalog itself: a single key, screen context, label length limit, and comment for the translator.
Then string collection became part of the product build — new and changed fragments enter the translation queue on their own, and pre-export checks cut off concatenations, lost placeholders, and unclosed plural forms.
After three cycles, 96% of strings were closed automatically, the share of manual edits fell from 30% to 4%, launching a new language was reduced from 6-8 weeks to five business days, and interface defects per version dropped to single digits instead of forty-plus.
Acceptance stopped being a manual crawl through screens: disputed places arrive as a list indicating the key and screen.
The picture matches the industry: according to CSA Research, the main gain in the speed of language releases comes from automating repetitive operations with text, while quality depends on the glossary, context, and checks embedded in the pipeline before publication.
How does an i18n audit differ from one-off interface localization?
A one-off review edits text in an already released product: the client sees corrected screens, but the source of discrepancies remains.
A release or two later, new strings appear, template concatenations surface again, along with incorrect word order in questions and cases in placeholders — this is localization debt.
An i18n audit starts from code, not text: it finds phrases hardcoded in markup, checks placeholders and their order, plurals, date and number formats, label length allowance in a button, and right-to-left writing direction. What looks like a translator's typo during review is often a defect in the string structure.
| Approach | When it fits | What remains out of scope |
|---|---|---|
| One-off review | One language, need to quickly remove visible discrepancies | Rules do not change: the next batch of strings brings the same errors |
| i18n audit and an ongoing loop | The product is evolving, there are several languages, releases are regular | Requires access to the repository and an agreed glossary |
An ongoing loop means build-time checks, keys with context for the translator, a glossary, and translation memory. A new string passes through them before release, so debt does not accumulate, and interface translation stops being a separate project for every wave of edits.
An already released product is moved to such a loop without stopping releases: first the rules and checks, then a page-by-page review of disputed places.
Frequently asked questions about translation automation and i18n audit
Clients check not automation itself, but its edges: will the meaning drift, who is responsible for terminology, what to do with an already released product. Below are answers to doubts that come up most often.
Machine translation produces "almost correct" output — how do you know the result is suitable?
We evaluate not "beauty", but the share of strings that pass without edits. The model receives the product glossary, translation memory, and screen context — terms and forms of address are not rebuilt from scratch in every release.
The remainder is edited by a native-speaker editor, but that is single-digit percentages of strings, not the entire volume.
Who is responsible for consistent terminology in the interface, emails, and help?
Terminology lives in the glossary: for each concept — one translation, part of speech, prohibition of synonyms. The glossary is connected both to translation and to validation: an unacceptable variant stops the localization build before release. Discrepancies between screens and documentation do not accumulate.
Translated strings break layout — how is this caught in advance?
A label in another language grows, and the button or column falls apart. Before translation, we run pseudo-localization — the interface on lengthened strings, so that bottlenecks are found on the test bench, not by the user. Separate rules — for placeholders, inflections, and number and date formats.
The product is already released. Will the code have to be rewritten?
Strings are extracted from code and templates, disputed places are closed with a wrapper, and then translation follows the same loop as in new sections.
There is also a reverse path: an edit is made in the source, and the loop rebuilds only the affected files without touching the rest.
Where to start: what to prepare before launching the translation loop
Starting a translation loop is not connecting a service, but inventory. Until string sources, segmentation rules, and glossary owners are described, an automated pass produces inconsistent terminology and breaks variables inside interface strings.
- String map: which surfaces are translated (web, mobile builds, emails, help), which remain in the source language, and who owns each.
- Localization readiness audit: string concatenation, date, number, and case formats hardcoded in code, plural forms — everything that hinders the machine pass.
- Glossary and terminology rules: stable terms with prohibited synonyms, separately — product names and legal wording that are not translated.
- Translation memory and segmentation scheme: repeated blocks are not translated again, and the share of matches grows with every release.
- Pilot language: one market with the highest load, on which the loop is fully tested before scaling.
- Acceptance criteria: share of untranslated strings, number of broken variables per release, review time, reproducibility of rollback to the previous version.
- Roles and access: who approves terminology, who accepts the release, who receives a discrepancy notification.
After the pilot, the loop is replicated to other languages without rebuilding the process: only the set of glossaries and rules for a specific market changes.
Describe the task — string volume, current formats, target markets, and timeline constraints — and we will return with an estimate and work plan, including the pilot order and acceptance checklist.
