When coding agents translate your app: what breaks, what to keep

Agent-assisted translation is the practice of letting an AI coding agent, the assistant that already reads and edits your codebase, add translation keys and draft the translated strings as part of a code change, instead of handing the strings to a separate translation step afterwards. It is fast, cheap, and for a single pull request often good. The problems are not in that pull request. They are in the twelfth one.

This post is a category piece, not a comparison. It is about what agents genuinely do well, what does not carry from one release to the next, and the pattern that keeps the speed without losing the record.

What agents are actually good at

The honest version starts with the strengths, because they are real. A coding agent asked to add a settings screen in six languages has, at the moment it writes the German label, more context than a translator receiving a spreadsheet: it knows the component is a button, that {{count}} is a number and not a name, what the neighbouring strings say, what the previous developer named similar keys, and whether the value is interpolated into a sentence. It writes the key, the default value and the translations in one pass, with no handoff, no export and no waiting.

It is also good at the plumbing that used to block localization entirely. Agents wire up an i18n library, wrap hardcoded strings, extract keys and run the sync command, and they do it for the side feature that no team would have budgeted a translation round for. Features that used to ship English-only now ship in every language the project has. That is not a small thing, and no critique of agent translation should pretend it is.

What breaks over time

Everything below is invisible in a single pull request. It shows up across pull requests, which is why teams discover it late.

Consistency across releases

Each agent run starts from an empty context. Nothing in the session remembers that the product name stays untranslated, that "subscription" became "Abo" and not "Abonnement" in German three releases ago, or that the Spanish uses "tú" and not "usted". The agent picks a rendering that is defensible in isolation, and a different defensible rendering next month. Formality is the nastiest case: in languages where the distinction is grammatical, one screen addressing the user formally and the next one casually reads as broken, not as a style choice.

Review and provenance

When a customer, a lawyer or an auditor asks why the app said what it said in Italian, a pipeline of agent-edited files has one answer: a commit by a bot, approved by a reviewer who could not read Italian and checked the diff for syntax. There is no reviewer of record, no decision trail per string, and no way to tell an agent's guess from a translator's choice once both sit in the same file. Since August 2, 2026 this is also a regulatory question: Article 50 of the EU AI Act applies, and under the Commission's final guidelines a faithful AI translation is exempt from machine-readable marking, while text that informs the public on matters of public interest needs a visible disclosure unless it went through documented human review with a person holding editorial responsibility. The legal detail is in the Article 50 explainer; the practical consequence is that "reviewed" has to be something you can show, per segment, and a review workflow is what produces that evidence. None of this is legal advice.

Terminology governance

The glossary exists, usually as a document. The agent may or may not read it, may read it in one session and not the next, and cannot know that a term was added after its last run. Forbidden terms come back. Product names get translated. The fix that gets suggested, "put the glossary in the agent's instructions", works until the glossary has four hundred entries and the instructions have to cover everything else as well. Terminology is a data problem, and data that has to be remembered by a stateless process is not governed, it is hoped for. The glossary belongs in a system the agent can query, not in a prompt.

QA over the corpus, not the diff

An agent checks the strings it touched. The defects that actually reach production are cross-key: the same source value translated three different ways across namespaces, a placeholder present in eleven languages and dropped in the twelfth, a number that changed on the way. Those are found by comparing every value of a language against its source and against the rest of that language, on every save, which no pull request review does. The taxonomy and how automated checks catch it is in what actually breaks in translations.

Plurals, placeholders and the strings that carry risk

Languages with more than two plural forms (Polish, Arabic, Russian) need forms the English source does not have. Agents produce them correctly in isolation and inconsistently in bulk, and a wrong _few key is a runtime bug, not a style issue. Then there are the strings where "the model is usually right" is not an acceptable bar: legal notices, pricing terms, medical and safety wording, accessibility labels. An agent treats them like any other string, because in the diff they look like any other string.

How teams handle coding-agent translation today

Four setups cover most of what we see, and the honest note is that the first one is right for some teams.

• The agent edits the locale files in the pull request. Fastest, cheapest, and fine while the people on the team can read every language and nothing depends on the copy. The drift described above starts on day one and becomes visible around the tenth release.
• The agent plus an LLM-in-CI step. The agent adds the keys, a workflow on push machine-translates the missing values. Removes the manual part entirely, and reproduces the same failure modes at pipeline speed: unreviewed output, no memory between runs, no terminology enforcement. The graduation path out of that setup is in when AI translations break.
• The agent drafts, a person reviews the diff. Better in spirit, weak in practice: a pull request reviewer sees twelve language files and can judge one or two of them. The review is real for the languages the reviewer reads and theatre for the rest.
• The agent drafts through a translation management system. The agent keeps doing the drafting, but the terminology, the memory of past decisions, the review queue and the history live in the system, and the agent reads from and writes to it. This is the pattern the rest of this post describes.

The agent-in-the-loop pattern: what to keep

Whatever tooling you use, the pattern has five rules.

1. Terminology and voice come from the system, not the prompt. Before the agent drafts a string, it fetches the project's glossary (preferred, allowed and forbidden terms per language) and the style guide (tone, formality, audience). The instructions say "look these up", not "here are four hundred terms".
2. Reuse before invention. A translation memory lookup for similar source strings comes first. A high-score match is reused, which is how the twelfth release stays consistent with the first one.
3. Provenance is declared, not inferred. The agent's output is pushed as AI output, which puts it in the review queue instead of in production. A person's edit is pushed as a person's edit. Once both are in the same file with no marker, the distinction is gone for good.
4. Review is per segment, by someone who reads the language, and recorded. Not a pull-request approval, not a spot check of two languages: a reviewer confirms or edits each value in an editor that shows the source, the context and the glossary, and the decision is written to the history with their name and the time.
5. Checks run over the corpus after the merge, not only over the diff before it. Consistency, placeholders, numbers, tags: the checks that compare against the whole language have to run where the whole language is.

What this does not solve

• Someone still has to read Polish. The pattern makes review cheap and targeted; it does not make it disappear. Quality estimation can route the confident drafts through and hold the doubtful ones, but the decision on a doubtful string is human work.
• The source text is agent-written too. Agents write the English as well as the German, and English strings drift in terminology exactly like translations do. A forbidden-term lint on new source strings catches part of it; a writer catches the rest.
• Risk strings are still a policy question. Which strings need a person regardless of confidence, which content falls under public-interest disclosure, and who holds editorial responsibility for a publication are decisions a tool records but does not make.
• Small projects can skip all of it. Two languages the team reads, no revenue or compliance on the copy: let the agent edit the files. The signal to change is the first language nobody on the team reads.

How this works in Locize

Locize exposes the system side of the pattern to agents through its MCP server, reachable at https://mcp.locize.app from Claude, Cursor, GitHub Copilot and other MCP clients, with 26 tools in total. Agent-driven translate loops (find the missing keys, fetch the source, push drafts, read the review queue) are a visible and steadily growing share of the traffic on that server.

• Context before drafting. get_glossary returns preferred, allowed and forbidden terms per language; get_styleguide returns tone, formality, audience and usage rules; search_translation_memory finds prior translations of similar source strings, exact and fuzzy; get_screenshot_context shows where an ambiguous key appears. All four are read-only, and the context tools post walks through them.
• Drafts land in review, not in production. report_missing_keys creates new keys without overwriting existing ones (and triggers automatic translation where it is enabled). update_translations takes a quality of AI for texts the agent generated or HT for a person's text; AI values are marked as needing review according to the project's rule (always, or only when the quality estimation score is below the threshold), and find_missing_translations and get_translations with needsReviewOnly let the agent read the queue it just filled.
• A person decides, and the history says who. Reviewers confirm, edit or decline in the editor; the review workflow records every decision, and the provenance export described in the Article 50 workflow guide packages it as CSV and JSON.

The needs-review queue in the Locize editor: marked values and pending proposals, confirmed per value by a reviewer

• Defaults, so nobody has to remember the rules. The public locize-agents repository holds convention files (CLAUDE.md, AGENTS.md, .cursorrules) that make an agent fetch glossary, style guide and memory before translating and lint pull requests for forbidden terms. For projects that are not connected yet, npx i18next-cli init --agent-note (i18next-cli 1.73 or newer) appends a short internationalization note to AGENTS.md, so the next agent session knows where the locale files live, which commands to run, and that it should ask before wiring up a translation service.

The agent keeps its speed. What changes is that its drafts arrive somewhere with a memory, a reviewer and a record. If your agent is already translating, create a project, connect the MCP server, and let the next pull request draft through it; the review queue will show you what the previous ones would have shipped.

Frequently asked questions

Can AI coding agents translate an app? Yes, and for a single change they often do it well: with the codebase in context an agent sees the component, the placeholder types, the adjacent copy and the git history. What it does not carry over time is consistency across releases, a record of who approved what, terminology decided outside the current session, and quality checks over the whole corpus. The agent is a good drafter; the drafts need a system behind them.

What breaks when a coding agent edits translation files directly? Nothing visible in the pull request. Across pull requests, the same concept is rendered differently, formality flips between screens, plural forms for languages with more than two forms are guessed inconsistently, and the only record of any decision is a commit by a bot. Checks that compare a translation with its source and with the rest of the language are not run on a diff, so defects accumulate unnoticed.

What is the agent-in-the-loop pattern for translation? The agent stays the drafter but drafts through the translation management system: it fetches the glossary, the style guide and matching translation memory entries before writing, reports new keys and pushes its translations declared as AI output, which places them in the review queue; a person who reads the language confirms or edits each value, and the decision is recorded.

Does the EU AI Act apply to translations drafted by a coding agent? Article 50 applies since August 2, 2026. Under the Commission's final guidelines of July 20, 2026, a faithful AI translation is exempt from machine-readable marking; the visible disclosure duty only covers text published to inform the public on matters of public interest and falls away with documented human review under a person holding editorial responsibility. A recorded review step is the exemption path. This is not legal advice.

How do I make my coding agent use the glossary and style guide? Give it tools instead of documents: over the Locize MCP server it calls get_glossary, get_styleguide and search_translation_memory before drafting, and get_screenshot_context for ambiguous strings; the convention files in the locize-agents repository make that the default. For projects not connected yet, i18next-cli init --agent-note leaves a note in AGENTS.md so the next agent session knows the setup and asks before wiring anything.