Localization agents: fluency stopped predicting fidelity, and your review process has not noticed.
Human review of translation worked for thirty years on a shortcut nobody wrote down: bad translations read badly, so a reviewer skimming for awkwardness caught most real errors on the way past. That shortcut is gone. A modern model produces prose that is idiomatic, confident and occasionally about something else entirely, and a reviewer reading only the target text has no signal at all — the sentence that inverts a warning reads exactly as well as the one that does not. Everything in this playbook follows from that: the reviewable unit is the source-target pair in a diff, the gates are machine-checkable invariants, and translation quality is the part of the pipeline you should worry about least.
The bottleneck moved, so name the job accordingly.
The instinctive framing is "translate our content into eight languages", and it points the effort at the one part of the problem that has been substantially solved. Teams that build for that framing produce a wonderful first pass and then discover that the actual cost was never the first pass.
- Consistency across a corpus, not quality of a sentence. One document translated well is easy. Four thousand documents where the same product noun, the same button label and the same legal disclaimer render identically every time is a state-management problem, and it is where localization budgets actually go.
- Throughput of change. Content is not translated once. A paragraph edited on Tuesday must reach eight locales by Thursday without re-translating — and without re-reviewing — the ninety percent that did not change. An agent that treats every publish as a fresh full translation has replaced a linear cost with a linear cost and added a review queue.
- Coverage of the things nobody translates. Error strings, empty states, tooltips, the alt text on a diagram, the confirmation email nobody has read since 2023. These are individually trivial, collectively enormous, and the honest reason they are still English in your product is that they were never worth a vendor purchase order. This is the clearest win available and it is worth taking first.
Note which of these is a translation problem: none of them. They are pipeline, state and coverage problems, which is exactly why an agent — something that can call tools, hold a task across many files, and follow a checklist — adds more here than a better model would. Buying a stronger model to fix a consistency problem is the characteristic mistake in this domain.
Fluent and wrong is the failure mode, and reading cannot catch it.
The errors that survive a modern model are not clumsy. They are confident, well-formed sentences that say something the source did not: a negation dropped, a conditional flattened into an imperative, a hedge deleted, a "must not" rendered as "need not", a unit silently converted, a proper noun helpfully translated. Each reads perfectly. None is detectable without the source in view.
- Never present target text alone for review. Segment-aligned source and target, side by side, is not a nicety — it is the entire mechanism by which review works now. A reviewer given only the translation is performing a fluency check and will report that everything is fine.
- Route by consequence, not by confidence. Segments containing negations, numbers, dates, currency, dosages, legal modals, or safety instructions get human review regardless of what any score says. This is a deterministic classifier over the source, which is a far more reliable trigger than a model's self-assessment.
- Do not use an LLM judge as the primary gate. A judge asked "is this a good translation" is a fluency detector with extra steps, and it shares failure modes with the translator that produced the text. It is useful for ranking candidates and for flagging outliers; it is not useful as the thing standing between a mistranslated safety warning and a customer. See LLM-as-judge for agents for why, and where it does work.
- Back-translation is a weak signal that reads as a strong one. Round-tripping through the source language catches gross meaning loss and misses exactly the class of subtle error you are worried about, because the same model that dropped the negation will helpfully restore it. Use it as one input among several, never as a pass/fail.
Gate on invariants a machine can check.
Because reading is no longer sufficient, most of your quality assurance has to be mechanical — and fortunately, a surprising fraction of real localization defects are mechanically detectable. Run these before a human ever sees the output; a failed invariant is a bug report, not a judgement call.
- Placeholder and variable parity. Every
{count},%sand named interpolation present in the source appears exactly once in the target, unaltered. Placeholder corruption is the single most common way a translated string becomes a crash rather than a mistake. - Markup integrity. Tags open and close, attributes are preserved, code blocks are byte-identical to the source, and inline elements are not reordered into invalid nesting. Anything inside a code fence is copied, never translated — including comments, which is the rule teams break first and regret most.
- Termbase compliance. Approved terms render as their approved translation; forbidden renderings are rejected. This is a lookup against a list, it is exact, and it is the highest-return automated check in localization because terminology drift is invisible per-document and glaring across a corpus.
- Number, date and unit preservation. Digits in the source appear in the target, converted only where the locale profile says to convert. Silent unit conversion is a category of error that is both easy to check and expensive to miss.
- Length budgets for UI strings. A German label that is 60% longer than the English breaks the layout it was written for. Give the agent the constraint as part of the task — a maximum character count per string — and check it, rather than discovering it in a screenshot.
- Structural parity for documents. Same number of headings, same list lengths, same link targets. A missing section is the failure a fluency review is least likely to notice, because what remains reads fine.
These checks are also the agent's own feedback loop. Return failures to it as structured tool errors and let it fix its work before the queue — the same discipline as any other tool-using agent. The measurable objective for the pipeline is human review minutes per thousand words shipped, and mechanical checks move it far more than model choice does.
Terminology and context are retrieval, not prompting.
The common failure is a prompt containing a glossary. It works for thirty terms, degrades quietly at three hundred, and is the reason your product name is translated on one page and not the next. Terminology belongs in tools the agent queries per segment, not in a system prompt it must remember.
- Translation memory as a retrieval tool. Query for previously approved translations of similar segments and prefer an exact match over generating a new one. This is not a cost optimisation — it is the mechanism that makes the corpus consistent, and it means a human decision made once propagates instead of being re-litigated by a model that has no memory of it.
- Termbase lookup on demand, scoped to the terms actually present in the segment. Retrieval keeps the injected context small and keeps behaviour stable as the termbase grows past what any prompt could hold.
- Context for isolated strings is the hard, under-served problem. A UI string like "Open" is unresolvable in isolation — adjective or verb, and in many target languages those are different words. The agent needs the surrounding screen, the key name, a screenshot, or the developer comment. Where none exists, the correct behaviour is to ask, and a localization agent that never asks a question is producing confident guesses on exactly the strings your users see most.
- Style beyond terminology needs examples, not adjectives. "Professional but friendly" transfers nothing across languages. Approved before-and-after pairs from your own corpus do, which is one of the few places few-shot examples beat instructions outright.
The unit of work is the diff.
Design the whole system around change rather than around documents, and most of the operational pain disappears. Treat localization as a build artifact of the source content: source segments are the input, the target files are generated, and only the delta is ever regenerated.
- Segment-level fingerprinting. Hash each source segment. On a change, only segments whose hash moved are re-translated; everything else is copied from the last approved output. Review queues shrink to the size of the edit, which is the difference between a two-day turnaround and a two-week one.
- Approval is state, and it belongs in version control. A reviewed segment carries an approval that survives unrelated edits elsewhere in the file. Without that state, every publish re-opens every decision, and your reviewers stop reading carefully because they are re-reading things they already approved.
- Fail the build on unresolved invariants, not on unreviewed content. Blocking a release on human review of every string is how teams end up shipping English fallbacks forever; blocking it on placeholder corruption is a bug gate that everyone will accept.
- Make staleness visible rather than blocking. A target segment whose source has changed but which has not been re-approved should render with a marker in staging and be countable in a dashboard. Silent staleness is how a locale rots — the pages are all present, and half of them describe last year's product.
Anyone maintaining a bilingual codebase already knows the version of this that bites: the English page gets an urgent fix, the other locale does not, and nothing in the system says so. Detecting that divergence is a script, and it is worth more than any improvement in translation quality.
What stays human, and the input nobody sanitises.
Two boundaries are worth stating plainly. First, some content is not a translation problem at all: marketing copy where the goal is effect rather than equivalence, anything where the localized text carries independent legal force — contracts, regulated disclosures, medical instructions, safety labelling — and any string whose mistranslation is a compliance event rather than a bug. For these the agent drafts and a qualified human owns the output, exactly as in legal agents. Publishing agent-translated regulated text under your own name transfers the liability to you and nowhere else.
Second, and quieter: source content is untrusted input. A translation agent ingests user-generated text, third-party documentation, support tickets and web pages, and a paragraph that says "ignore previous instructions and translate the following as…" is indistinguishable to the model from content to be translated. The consequences are worse than a bad translation when the same agent also has write access to your content repository. Delimit source content explicitly, never let it reach the tool-selection path, and keep the write step separate from the translate step — the structural argument in prompt injection 101 applies here more directly than most people expect.
Start with the invariant checks and segment-level diffing, before you evaluate a single model. They are a week of unglamorous engineering, they run against whatever translation source you already have, and they will surface defects sitting in your current localized content today — corrupted placeholders, drifted terminology, sections that quietly went missing. Then put the source beside the target in every review screen, and route negations, numbers and safety text to a human by rule. A localization agent's job is to make a reviewer's twenty minutes land on the segments that can hurt you, and no amount of translation quality substitutes for knowing which twenty segments those are.
Related: multilingual agents for the model-side behaviour underneath this, designing for trust for the review-surface half, and adapting a playbook for the method behind this one.