smart_toy Artificial Intelligence › Article

AI Localization and Translation: Context Before Speed

An LLM translates interface text fast, but without context, a glossary or a space limit it fails. How to prepare it, what to check and when not to use it.

info Quick Definition

AI localization is the use of language models to translate and adapt a product’s text for other languages and markets. It works well when the model receives context, a glossary and space limits. Without them, it produces translations that are correct on their own but don’t fit the interface.

How is translating different from localizing?

Translating means moving a text from one language to another. Localizing means adapting it to a market: dates, currency, tone, examples and even the level of formality. Choosing between a formal and an informal “you” isn’t a translation error. It’s a localization decision.

In an interface, text also lives inside a space. The W3C reproduces IBM figures on how much text grows when English is translated into other European languages, and the shorter the original, the bigger the growth. For strings of 21 to 30 characters the average is 160% to 180% of the original; for 31 to 50 characters, 140% to 160%; above 70 characters, 130%. Interface text is exactly the short kind, so a screen that fits in English can break in another language even when the meaning is perfect. The W3C recommends flexible layouts and avoiding small fixed-width containers.

What problems does an LLM have with interface text?

Interface strings are very short. That format is the hardest for any translator, human or automatic, because the same word can mean different things. “Save” can be a button, a verb in an instruction or the name of a section.

The model doesn’t know where the text appears, so it answers with a guess. Adding context per string is the most direct fix.

There is a second problem: consistency. An LLM doesn’t guarantee that a new string is translated the same way as the existing ones. If “card” becomes “card” on one screen and “payment method” on another, users notice, even when neither translation is wrong on its own.

And a third: the grammar of quantity. Languages don’t pluralize the same way. According to Android’s documentation, its plural categories are zero, one, two, few, many and other; Chinese and Korean only use other, and in Lithuanian the singular form is used for both 1 and 101. If the code builds the sentence by gluing pieces together, no model can fix that.

How do you prepare the work before translating?

Before asking the model for anything, prepare four things:

Context per string. For each text, write where it appears and what it does. Android documents this pattern with comments for translators above each string, for example: “The action for submitting a form. This text is on a button that can fit 30 chars.” Saying it is a button matters, because translations are less flexible in buttons than in text boxes.
Space limits. State the maximum number of characters per element. Phrase notes that putting metadata such as character limits or style guides in the prompt steers the model toward translations that respect those constraints from the start.
Glossary and translation memory. List the brand terms with their approved translations, and reuse translations that were already approved. Some machine translation engines support this natively: DeepL, for example, lets you create glossaries of source and target terms for a language pair and apply them with the glossary_id parameter on each request. With an LLM, the glossary goes in the prompt.
Protected variables. Mark names, placeholders, figures and URLs that must not be translated. Android asks you to wrap text that isn’t translated in <xliff:g> tags with an id attribute that explains its purpose, and to write variables as positional placeholders (%1$s, %2$d) inside a single string, not as pieces glued together in code.

What you provide	What it prevents	Example
Location and function	Ambiguity of isolated words	“Button that submits the payment form”
Character limit	Cut-off text	“Maximum 40 characters”
Glossary	Different synonyms on each screen	“fees = Gebühren”
Marked variables	Placeholders and names translated by mistake	`%1$s` stays intact

With that preparation, the LLM makes the first version and a person reviews it. According to Phrase’s trends article (updated March 12, 2026), AI doesn’t eliminate human roles but reshapes them: people keep the tasks that require empathy, cultural understanding and editorial judgment. The same article reports that Motorola uses AI to assess translations before human review, including whether they fit the space limits.

How do you check the result before publishing?

Checking the meaning isn’t enough. Do three checks:

Pseudolocalization. Android offers pseudolocales that simulate the typical problems of a translation: one adds accents, stretches the original text and wraps each message in brackets, and another reverses the text direction to test right-to-left languages. They help you find layouts that break, strings hardcoded in the code (they show up without accents) and concatenations. You use them before you have a single real translation.
Review on the real screen. Look at the string inside the component, not in a spreadsheet: line breaks, overflowing buttons, word order with variables.
Review by a speaker of the language and the market. A native speaker validates tone, formality and industry terms. If the model invents a technical or legal term, this person is the one who can catch it; see hallucinations.

For the style of the source text, which sets the quality of every translation, see UX writing with AI and microcopy with AI.

When should you NOT use an LLM?

In legal or medical text, in marketing copy built on wordplay, and in languages with thin training coverage where the model’s quality isn’t enough for the audience. In those cases a professional translator remains the safe choice, and the model can help by comparing options.

It also doesn’t pay off if nobody can read the result: a language nobody on the team masters is a language you can’t review.

Example

Illustrative example: a payments app has a 40-character banner that reads “Pay in 3 installments, no hidden fees” (37 characters). Without context, the model translates it into German as “Zahlen Sie in 3 Raten, ohne versteckte Gebühren” (47 characters) and the text gets cut. With context (“informational banner, maximum 40 characters, calm tone, informal address”) and a glossary (“fees” is always “Gebühren”), the proposal becomes “In 3 Raten zahlen, ohne versteckte Gebühren” (43 characters). It still overflows by three characters, so the reviewer decides: shorten it to “Ohne versteckte Gebühren” or widen the banner. That design decision is theirs, not the model’s. They also confirm that “Gebühren” matches the rest of the product.

Common mistakes

Translating isolated strings without saying where they appear.
Concatenating sentences in code (“You have " + number + " messages”), which stops translators from reordering the words.
Letting the model translate brand names, variables or legal terms.
Reviewing meaning only, not length on screen.
Machine-translating and publishing without a review pass per language.
Assuming Spanish for one market works for every Spanish-speaking country without checking tone.

Sources

Frequently asked questions

Can I translate an interface with an LLM without human review?

It isn’t advisable. Short strings carry little context, translated text often takes more space, and terminology can drift from one screen to another. A person who knows the language should review the result in the real interface.

What should I give an LLM to translate an interface better?

Where each text appears, its character limit, the style guide, the brand glossary and the variables that must not be translated. Phrase notes that putting metadata such as character limits or style guides in the prompt steers the model.

Why are short UI strings hard to translate?

They carry little context and are often ambiguous: ‘Send’ can be a button, a verb or an email action. Without knowing where it appears, the translator guesses.

What is a glossary in localization?

A list of official terms with their approved translations, for example how ‘workspace’ or ‘card’ is written in each language. It keeps the same word across the whole product.

How do I find length problems before the translations exist?

With pseudolocalization. Android includes pseudolocales that stretch the original text and wrap it in brackets, so you can see which screens break and which texts are hardcoded in the code.