Can software localization ever be fully automated?

The question is asked about the wrong step

The question usually arrives pointed at the model. Can a machine translate a product interface well enough that no person has to look at the result? That is a real question about models, and it is the wrong question about localization, because the translation step is not where automated pipelines actually stop.

Everything around the string was automated years ago, and the parts that have not are not waiting on a better model. What is left is a small set of strings where nobody, human or machine, can produce a correct output from the file in front of them, because the file does not contain enough to determine one.

Those strings are not hard. They are underdetermined. The difference matters, because it decides whether a better model fixes them, and it decides who has to do something about them.

The part that is already zero-touch

Start by conceding the whole of the automated case, because it is stronger than the sceptical version of this argument usually allows.

A commit lands. A webhook fires. Changed keys are extracted and diffed against what the platform already holds. Exact matches are recalled from memory at no cost. What is left goes to an engine with whatever context exists, attached. The output is scored. Segments above a threshold merge, segments below it are queued for a human. Target files return as a pull request or stream to an edge cache, and the release that carried the string ships in the same window as the release that would have shipped it in English alone.

There is no Human-in-the-loop (HITL) anywhere in that sequence, and no reason there needs to be one. Every step is a program calling another program. The email attachments and the spreadsheets and the two-week integration window are gone, and nothing about them is coming back.

So if the question means “can the process run without a person driving it”, the answer has been yes for a while, and the remaining work is plumbing. The interesting question is the one underneath: which strings still cannot be resolved by anything in the pipeline, and why not.

The strings that remain are underdetermined

A translation system, human or otherwise, takes an input and produces an output. When two different outputs are both correct with respect to the same input, no amount of capability lets a system prefer the right one for a reason. It can only guess. And it will guess with exactly the confidence it applies to everything else, because nothing in the input told it this case was different.

That is the class of failure that survives automation. Not “difficult text”, which models keep getting better at, but text whose correct rendering is decided by a fact that is not in the artifact. Sort the pipeline’s decisions by where the deciding fact actually lives and the shape of the problem stops being a matter of opinion.

The last column in itself is self-sustaining. The bottom two rows are checkable by a program with no judgement in it, at all. The top four are not checkable by anything, at any price, until somebody supplies the missing fact. That is the whole argument, and the rest of this post is four worked examples of it.

A two-branch source cannot describe a four-branch target

CLDR defines six plural categories: zero, one, two, few, many and other. Only other is required. Every language uses some subset, and which subset is a property of that language rather than a choice anyone gets to make ¹. English uses two, one and other. Polish and Russian use four. Arabic uses all six. Japanese uses one, because it does not grammatically mark plurality at all².

Now put an English string into a pipeline whose target is Polish.

en.json  the source, complete and correct  "one":   "{count} file selected"  "other": "{count} files selected"​pl.json  the target, complete and correct  "one":   "Wybrano {count} plik"  "few":   "Wybrano {count} pliki"  "many":  "Wybrano {count} plików"  "other": "Wybrano {count} pliku"

The English string is not an incomplete description of the Polish string. It is a complete description of a different thing. There is no English few branch that got lost on the way in, so there is nothing to translate into the Polish one. A system filling that branch is not translating; it is writing new source content, and it has no way to be told whether the version it invented is the version you meant.

It will usually be right. Polish plural morphology is regular enough that a model with good Polish produces good Polish. But notice what it is being right about: it is guessing at content, correctly, and “correct guess” and “derived from the input” are different things that look identical in a diff. When a twenty-seven locale pipeline runs continuously, the difference is a rate, and a rate is a schedule.

The syntax around the branches has its own failure mode, and this one is documented rather than statistical. In ICU message syntax an ASCII apostrophe begins quoted text when it sits immediately before a character that needs quoting ³. French puts an apostrophe immediately before a great many things.

source, English  {count, plural, one {# item} other {# items}}​target, French, written by a translator who knows French  {count, plural, one {l'{count} article} other {les {count} articles}}​what the parser does with it  the apostrophe sits immediately before a brace, so it opens  quoted text, and the placeholder is emitted as the literal  characters {count} instead of a number.

The ICU guide also recommends putting select arguments outside and plural arguments inside when the two are nested, which is a structural constraint on the message that no part of the linguistic task knows about ³.

This half of the problem is the good half, because it is decidable. A parser either accepts the string or it does not, the answer is the same every time, and it costs nothing. Which is exactly why it belongs in something that fails a build rather than in a reviewer’s attention. We have written about this at length: a translation is a code change, and fluency is necessary and not sufficient.

The file does not know how wide the button is

The number everyone quotes for text expansion is thirty percent. It is a real number and it is for long text. The table the W3C reproduces from IBM’s design guidelines is sorted by source length, and the thirty percent figure sits at the bottom of it, for strings over seventy characters. At the top of the table, for source strings up to ten characters, average expansion is two hundred to three hundred percent ⁴.

Software interfaces are made almost entirely of strings from the top of that table. Buttons, tabs, menu items, column headers, form labels, empty-state lines. The industry took its planning figure from the row that describes documentation and applied it to the row that describes buttons, which is how a layout that was budgeted for a third more text meets a label that tripled.

A pipeline cannot see any of this, and not because of an oversight anyone could fix. A resource file is a map of keys to strings. Width is a property of a rendered component, at a font size, in a viewport, with that locale’s font fallback, in a state the user has to reach. None of those five things are in the file, and four of them do not exist until the application runs.

Direction is worse, because it is not a text property at all. Making an interface work in Arabic or Hebrew means mirroring navigation, progress, form flow and iconography across the vertical axis. On the web that is a CSS problem, and the modern answer is to write the layout in flow-relative terms in the first place, so that inline-start means the start of the line rather than the left of the screen ⁵.

Note who does that. It is a change to the component, made by whoever owns the component, before any string exists. No translation step can perform it, no quality score can detect that it was skipped, and a screenshot test only catches it in the states somebody thought to screenshot. Multiply locales by viewports by application states and the matrix stops being enumerable long before it stops being relevant.

Save, Book, Run

The shortest strings are the most ambiguous, which is an unhelpful property for a medium made of short strings.

Book is a noun and a verb. Run is a command, a noun for an execution, and a thing you do with legs. Clear is an adjective and a destructive action. Save is a file operation and a discount. A sentence carries enough syntax to settle which one it is. A four-character button label carries none, and the key name beside it is written for a compiler rather than for a reader, so btn.run settles nothing either.

Here is the part that reframes it. The information was never missing. It existed, completely and unambiguously, in the head of the developer who typed the string, at the moment they typed it. It was discarded on the way into the resource file, because the file format has nowhere to put it and nothing in review asks for it.

So the model is not being asked to translate. It is being asked to reconstruct a fact that a person had, and threw away, from evidence that no longer contains it. That is not a translation problem and no translation model solves it. A description on the key solves it. A screenshot solves it. Both are things a human writes once, upstream, for free.

What an automated quality gate is calibrated to see

The strongest argument for full autonomy is the automated quality gate, so it is worth being precise about what one measures. Quality estimation predicts the quality of a translation without access to a reference translation ⁶, and the systems that do it best are trained to predict human judgement at both sentence and word level ⁷. The human judgement they are calibrated against is error annotation in the MQM tradition, produced by professional translators working with full document context, which ranks systems substantially differently from crowdsourced scoring ⁸.

That is a genuinely good instrument, and it is an instrument for a specific thing. It sees what the error taxonomy it was trained on sees: mistranslation, omission, addition, register, terminology, fluency. Route on it and you will catch bad translations, reliably, cheaply, at a volume no review team could match.

It is not calibrated on whether the message parses, whether the label fits its container, or whether the screen mirrors. Those are not translation errors and they are not in the taxonomy, so a string can score at the top of the band and still take the screen down. A high score is evidence about the language and silence about everything else.

The residual failure rate is real too, and it has been measured properly rather than asserted. A study of hallucination in neural translation on natural in-domain data, with over three thousand four hundred annotated sentences, found that sequence log-probability detects hallucinations about as well as reference-based methods, and proposed a test-time method that significantly reduces the rate⁹, reduces. Under continuous deployment a per-segment rate that is small and nonzero is not a risk you are exposed to, it is an event you have scheduled.

Which gives the ordering. The deterministic checks are free, total and certain: parse the message, count the placeholders, confirm every CLDR branch the target requires is present, match against the termbase. Run all of them before the paid probabilistic one, because calling a model on a string you are going to reject on syntax is buying an answer to a question you already had.

Automation moves the human to the front of the pipeline

Put the four examples together and they say the same thing. The pipeline fails exactly where the artifact underdetermines the answer, and the fix in every case is that somebody records the missing fact.

Every entry in that middle column is authored at commit time by the person who created the string. That is the actual transformation automation performs. It does not remove the human from localization. It moves them from the end of the pipeline to the front of it, and changes the job from editing output to specifying input.

The arithmetic strongly favours the front. At the end, a person resolves the same ambiguity once per locale, every time the string changes; at twenty-seven locales that is twenty-seven resolutions of one question. At the front it is resolved once and every locale inherits it, including the locales you have not added yet.

The answer, and why the number is yours to move

So: can software localization ever be fully automated? The process, sure, and mostly already is. The overall pipeline, no, in precisely the cases where the artifact does not determine it, and model progress does not move that boundary because the boundary is not a capability gap. A system cannot recover information that was never written down. That is a fact about information, not about machine learning, and it will still be true about whatever replaces the current generation of models.

Which leaves the number, and the number deserves a closer read than it usually gets, because the published figures are not measuring the same thing. One platform states that teams using automated scoring review only about twenty to thirty percent of their content, the rest having passed the check ¹⁰. Another advertises ninety-five percent quality, which sounds adjacent and is not: it describes how good the output is, in a workflow it describes as combining AI translation, scoring and human review¹¹. A published engineering account of one large deployment reports about ninety-nine percent of user-facing content moving through the batch pipeline, and about ninety-five percent of translations passing human review with minimal changes ¹².

Read that last one twice, because it is the figure most likely to be quoted as evidence of autonomy and it is evidence of the opposite. Ninety-five percent passing review is not ninety-five percent that skipped review. A person looked at all of it and mostly agreed. Of the three numbers, only the first counts strings that nobody touched, and it is the smallest.

So treat any straight-through rate as a claim about a catalog rather than a property of a platform. Two teams on the same platform, running the same model against the same languages, will get different numbers, and the whole of the difference is how much they wrote down before the pipeline ran.

If your automated rate is stuck, the lever is not the model and it is not the vendor. Go and look at what the strings that failed had in common, and you might find they were the ones nobody described.

Full automation is available. It is priced in specification, and you pay for it at commit time or you pay for it forever.

References

1. 1.Unicode CLDR Plural Rules cldr.unicode.org, CLDR specification
2. 2.Unicode CLDR Language Plural Rules unicode.org, CLDR supplemental charts
3. 3.ICU User Guide Formatting Messages unicode-org.github.io/icu
4. 4.W3C Internationalization Text size in translation w3.org, i18n articles
5. 5.MDN Web Docs CSS logical properties and values developer.mozilla.org
6. 6.Zerva, Blain, Rei, Lertvittayakumjorn and others, 2022 Findings of the WMT 2022 Shared Task on Quality Estimation WMT 2022
7. 7.Rei, Treviso, Guerreiro, Zerva and others, 2022 CometKiwi: IST-Unbabel 2022 Submission for the Quality Estimation Shared Task WMT 2022
8. 8.Freitag, Foster, Grangier, Ratnakar, Tan and Macherey, 2021 Experts, Errors, and Context: A Large-Scale Study of Human Evaluation for Machine Translation TACL 2021
9. 9.Guerreiro, Voita and Martins, 2023 Looking for a Needle in a Haystack: A Comprehensive Study of Hallucinations in Neural Machine Translation EACL 2023
10. 10.Lokalise AI translation scoring for quality assurance lokalise.com, product pages
11. 11.Smartcat Software Localization Platform for Product Teams smartcat.com
12. 12.Kumili, 2026 Lyft Scales Global Localization Using AI and Human-in-the-Loop Review InfoQ, April 2026