AI system for automatic interface localization with context

Why machine translation breaks AI localization of interfaces

Classic machine translation treats a string as an isolated unit of text.

In an interface, a string almost never carries full meaning: the short “Save” lives in a modal window in one scenario, while “Save as draft” lives in the menu of another, and without screen context the engine chooses the wrong gender, case, and term.

The difference is visible not in the beauty of the wording, but in the number of defects caught by acceptance.

A separate problem is variables and substitutions inside a phrase. The engine can reorder them, merge them with a neighboring word, or change their order, and the string either fails formatting or shows the user a raw template instead of a value.

Abbreviations in the interface make the picture worse: “Set.”, “Qty”, and “Ed.” have no stable dictionary correspondence, and the model inserts a random synonym, breaking consistency across the entire product.

Then terminology inconsistency begins. When each string is translated separately, the same concept sounds different in neighboring screens, and sometimes there are three variants on a single screen.

The user loses orientation: it is unclear whether “Profile,” “Account,” and “User account” lead to the same section.

The cycle of manual edits after the build closes it all. They are made directly in the finished localization files, they do not return to translation memory and the glossary, and the next build overwrites the fixes or brings new errors on the same strings.

Let us break down how this is closed in AI localization, which sees the whole screen context rather than a separate string.

What contextual AI localization of an interface provides

Automatic interface localization works not with individual strings, but with segments: each string goes for translation together with its key, screen name, length limit, and a snapshot of where it is displayed.

The model sees that “Save” is a button in a modal window, not a menu item, and selects the form by gender, number, and case. Variables inside strings, plural forms, and nested links are checked before the build, so a broken substitution does not survive to the test environment.

Unified terminology is maintained by the glossary and translation memory. The glossary fixes mandatory terms and forbidden variants, and memory returns a previously approved segment if the source text has not changed.

When the product is edited, only the affected segments are rebuilt, while the rest are taken from the accumulated base — that is why a new language version ships incrementally rather than being assembled from scratch.

In practice, the share of strings reaching manual proofreading falls from the majority to single-digit percentages, and disputed places return to the editor with a note explaining why this variant was chosen.

Segments are exchanged in the industry format XLIFF, so the work is not locked into one tool and can be transferred between editors and product versions.

The release time for a language version is determined no longer by text volume, but by the time needed to review disputed segments — typically days instead of weeks.

Terminology does not sprawl: at each release, it is checked that new text uses the same terms, and discrepancies go into a report for the editor rather than into the interface.

Translation formats: phrase-by-phrase, contextual, with glossary

The options differ not in translation quality as such, but in how much information about the product we feed into the input.

Phrase-by-phrase translation takes a string in isolation, contextual translation takes it together with the screen, neighboring elements, and substitution data, while the project glossary and style rules fix terminology and tone on top of either mode. This determines where the system makes mistakes and how much manual review remains at the output.

In practice, the modes do not compete but combine: phrase-by-phrase remains for short keys, contextual turns on where a string depends on its environment, and the glossary and style rules work on top of both.

Disputed cases go to manual review by a formal criterion — discrepancy with the glossary, length, placeholder break — not by the performer's taste. The next question is how strings enter the system and what happens to them when the product updates.

How we implement contextual translation of interfaces

Localization breaks not on translation, but on context: the string “Cancel” on a button and in a system message requires a different gender and length, and without notes the translator chooses at random.

That is why we run the work as an engineering process — from string audit to a policy by which new texts do not break already assembled screens.

1. Interface string audit. We export strings from resource files and templates, mark duplicates used in different places, and separate what is edited manually for legal requirements.
2. Context markup. A string receives its screen, element role, length limit, gender and number, and a list of substitution variables — by these the model distinguishes a heading from a button label.
3. Translation rule setup. A glossary of terms, a “do not translate” list (keys, proper names, error codes), and a unified address to the user, so wording does not diverge between screens.
4. Test loop. We build a copy of the product and inspect real screens: text clipping, line breaks, variable substitution, and right-to-left text where needed.
5. Translation acceptance. A native speaker reviews disputed places — idioms, abbreviations, forms of address — and returns edits together with the reason, so the rule goes into the glossary rather than into one string.
6. Update policy. Without context, a string does not pass into the build, and a changed glossary highlights already translated places for re-review.

After acceptance, the team receives a string map, glossary, and rules: interface updates go through the same loop and do not turn into manual screen reconciliation.

Project artifacts: glossaries, rules, control dashboards

An interface localization project lives longer than the implementation lasts: terms appear, screens change, languages are added. Therefore, along with the working system, we hand over artifacts that the customer's team edits itself, without contacting us.

• Term glossary — product and technical concepts with forbidden synonyms and a “do not translate” mark; the system takes them from the dictionary, so one term sounds the same across all screens and languages.
• Style rules for each language — address to the user, capitalization, length of buttons and labels, number and date format; the rules file is edited without rebuilding the system.
• Quality control dashboard — the share of strings that passed review, the queue of disputed segments, and discrepancies with the glossary: it shows where the system is confident and where a human is needed.
• Translation documentation — a description of the process, roles, and checkpoints; a new engineer gets up to speed from it, not from chat.
• Dictionary update policy — who and how adds a term, how many examples are needed to accept an edit, and how to roll back an unsuccessful rule.
• Set of test strings with a reference answer — run automatically after each edit, so regression is visible before release.
• Decision log — disputed cases with the rationale for the choice, so that in six months no one reinvents what has already been decided.

All of this is stored in your repository and versioned together with the code: an edit passes review, and rollback is possible to any previous dictionary version. Support does not require us — we remain for development, not for routine edits.

Case: launching a product in eight languages without manual proofreading

What was before

The customer's product was a network infrastructure management panel with eight interface languages.

Strings lived in tables like “key — text”: the translator received a file without context and did not see where the string would appear, what gender it had, or how much space was allocated to it on the screen.

The editor returned about 32% of strings for revision, terms diverged between languages, and launching one new language took six weeks.

What changed

Strings and the glossary were consolidated in Phrase, and context is automatically linked to each string: a screenshot, neighboring labels, length limit, and declinability flag.

The glossary fixed terms with a ban on synonyms, and translation memory inserts approved wording instead of retranslating.

The release build runs checks: unclosed placeholder tags, length overflow, terms outside the glossary. If a check fails, the language does not make it into the release rather than surfacing in the user's interface.

What became

The share of manual edits after the editor fell from 32% to 4% — the edits concern style, not meaning and terminology. Disputed terms in the interface decreased from 180 to 12, and all are closed by glossary decisions.

Launching a language takes nine days instead of six weeks: translation runs in parallel with development, and checks are performed on each build rather than at the end.

Adding a ninth language came down to connecting a set of strings — the harness, checks, and glossary already work.

How does contextual translation differ from phrase-by-phrase?

Phrase-by-phrase translation cuts the interface into segments and processes each one separately: the input is one string without neighboring keys, screen, or user role.

It works quickly and predictably, but the system guesses homonymy, gender, and word order by frequency — “Open” in a menu item and in a confirmation dialog get the same variant.

The contextual approach feeds in a group: neighboring keys, element type (button, label, error text), length limit, and approved product terminology.

The system sees that it is a three-word section heading, not part of a sentence, and selects the form by language rules rather than statistics.

The limitations of phrase-by-phrase translation are not cured by model size: if the meaning is not passed to the input, there is nothing to restore it from.

The difference is especially noticeable on forms, validation errors, and tooltips, where a string depends on the screen state.

We fix context in the exchange format XLIFF: the key, source text, notes, and links to neighboring units travel with the segment, so the environment is not lost during export and rebuild. Manual review still remains — terminology and legally significant wording are checked by a human.

Common technical concerns before starting a project

Before the start, engineers and department heads ask similar questions: how to make sure the translation will not drift in the interface, what to do with ready translations, and how to connect the glossary so terms remain consistent. Below are short answers that usually remove doubts before the work estimate.

All of them are about mechanics: what we check against, how we transfer existing strings, and what serves as the rollback point. If your question is not here — we will address it separately and include it in the plan.

We have ready translations — do we have to redo everything?

No. We transfer existing files, match keys, and show conflicts: where the old translation diverges from the glossary or screen context. The decision on each string remains yours.

How is the glossary connected?

As a file with “term — translation” pairs and priority above the model: it overrides the system's choice. New terms are added along the way, and changes take effect from the next build.

What if the wording does not satisfy after release?

Translation sets are versioned. An unsuccessful release rolls back to the previous set entirely, and editing a single string does not require rebuilding the rest of the interface.

Let's discuss the interface translation task and come back with a plan

To base the estimate on facts rather than feelings, we need a short review of your interface: what it is built from, how it updates, and which language versions are needed first. Describe the task — we will come back with a work plan, timelines by stage, and team composition.

During the review we clarify:

• scope: how many screens and strings, where texts live in code and where in the translation management system;
• context: what data the model needs to distinguish user role, screen state, and the meaning of identical strings in different places;
• languages and priorities: which versions launch first, whether right-to-left writing, declensions, and different wording lengths are needed;
• glossary: how we fix product names, terms, units of measurement, date and number formats;
• integration: where we connect translation — in the build pipeline, in the content editor, or both;
• update policy: how new strings enter translation and how editor edits return to the product without loss;
• access and acceptance: who on the customer side confirms quality and by what criteria we consider a stage closed.

Based on the results, you receive a string map, glossary, context handling rules, an integration scheme into your build process, and a plan for the first launch in one language version. Then we expand to the others without redoing the foundation.

Write what the interface is and which languages are a priority — we will come back with an estimate and work plan.