AI Translation and Localisation Cost: What Machine Output Still Needs
Raw machine translation costs almost nothing. That fact has not made localisation cheap, and the reason is in the published rates.
Post-editing machine output is quoted at roughly $0.03 to $0.08 a word for light editing and $0.08 to $0.15 for full editing, against $0.15 to $0.30 or more for human translation from scratch. Certified legal or medical work with post-editing lands at $0.15 to $0.25, which is to say roughly the price of human translation. One industry analysis puts the discount achievable from light post-editing at 35% to 40% off the normal word rate.
So the saving is real and it is a discount, not an elimination. Anyone budgeting on the assumption that machine translation removes the human cost has mispriced the project by a factor of several.
The number that decides your bill is not the per-word rate. It is how much of your content needs which level of editing, and that is a content decision rather than a technology one. Interface strings, legal terms, marketing copy and help documentation sit at four different points on that scale, and treating them as one bucket is the common and expensive mistake.
There is also a quieter cost that no per-word rate covers, which is making the product capable of being localised at all. Text extracted from code, layouts that survive a language running 30% longer, dates and numbers formatted per locale, and a pipeline that does not require a developer every time a string changes.
Three questions set the price. How much of this content carries risk if it is subtly wrong? How often does it change? And is the product engineered for multiple languages, or is the text currently inside the code?
Post-editing machine translation is quoted at roughly $0.03 to $0.08 a word for light editing and $0.08 to $0.15 for full editing, against $0.15 to $0.30 or more for human translation from scratch. Light post-editing saves around 35% to 40% off the normal word rate. It is a discount, not an elimination.
The industry distinguishes levels of post-editing, and choosing deliberately per content type is where the money is saved.
Light post-editing fixes what is wrong, not what is awkward. Errors of meaning, mistranslations, omissions. The result is accurate and reads like a translation. It is appropriate for high-volume, low-stakes, short-lived content where comprehension is the requirement.
Full post-editing produces text that reads as though written in the language. Terminology is consistent, register is right, idiom is natural. It costs roughly twice light editing and is appropriate wherever the reader is a customer making a decision.
No editing at all is a legitimate choice for some content and is routinely used for user-generated material, internal search, and anything where the alternative is no translation. The honest position is to label it as machine translated rather than to hope nobody notices.
Mixing levels within a product is normal and should be planned. Interface strings and legal text get full editing. Help centre articles get light. Thousands of user reviews get none. A single quality level applied to everything is either too expensive or too risky, and usually both in different places.
Machine output quality should be sampled per content type too. The same engine that handles your interface strings well may struggle with your technical documentation, and discovering that after committing to a light-editing budget is the expensive order to find out.
Decide this per content type and write it down, because the decision will otherwise be made implicitly by whoever is under deadline pressure.
Per-word is the most common pricing method in the industry and several practitioners argue it is the wrong unit for post-editing.
The time to post-edit a segment is unrelated to its length. A clean sentence needs a glance. A sentence where the machine has inverted the meaning needs more work than translating it fresh, because the editor must first notice the error.
Which means the quality of the machine output drives the real cost, and that quality varies enormously by language pair and by domain. A widely resourced pair on general prose produces output that needs very little work. A less-resourced pair on technical material produces output where post-editing approaches retranslation.
Experienced post-editors frequently quote hourly for this reason, or compute an effective per-word rate from how many words they can process in an hour. Both are attempts to price the variable that actually matters.
For a buyer, the practical consequence is to pilot before committing. Send a representative sample of your real content in your actual language pairs and measure what it costs to bring to your required quality. A quote given before anyone has seen your content is a guess dressed as a price.
Do not assume the cheapest pair predicts the others. Budgets built by multiplying one language's result across ten are reliably wrong, and wrong in the direction that hurts.
The most expensive localisation projects are the ones where the product was not built for it, and the cost lands in engineering rather than in translation.
Text inside code is the first problem. Strings concatenated in source, hard-coded in templates, embedded in images. Extracting them is a refactor, and until it is done every language is a code change.
Concatenation breaks grammar in ways English hides. Building a sentence by joining fragments works in English and fails in languages where word order, gender or case differ. The fix is full sentences with named placeholders, which is a rewrite of every message the product emits.
Plurals are not a binary. English has two forms. Several languages have more, with rules that do not map, and a system assuming singular and plural cannot express them.
Layout has to survive expansion. Text commonly runs substantially longer in some target languages than in English, and a design laid out to the pixel against English copy breaks. Testing with a long language early is cheaper than redesigning late.
Dates, numbers, currency, addresses, names and sort order are all locale-specific and all routinely hard-coded. None is difficult individually; together they are a sizeable piece of work that nobody scoped.
Teams pick languages by market size and then discover the cost was not proportional to the opportunity.
Support is the hidden commitment. Shipping a language is a promise that somebody can answer a question in it. A product localised into eight languages with support in two creates a worse experience than one localised into two, because the user is invited in and then abandoned at the point of difficulty.
Content volume is not the same as string count. The interface may be five thousand words. The help centre may be two hundred thousand, and it changes every week. Most of the ongoing cost is in the long tail of content, not the product surface everyone counts.
Some languages cost more per word than others, both because machine output is weaker for less-resourced pairs and because the editor pool is smaller. Market size and translation cost are only loosely related, and the cheapest language to add is rarely the most valuable one.
Right-to-left scripts are an engineering project, not a language. Layout mirroring, bidirectional text, icon direction, and a testing pass of their own. Budget it separately from the per-word work or it will surprise the schedule.
Start with two and measure. The second language tells you your real marginal cost, which is the number to multiply, and it is almost never the number anyone estimated from the first.
Localisation arguments go in circles when there is no agreed definition of good, and defining one is cheap.
A style guide per language settles most disputes before they happen. Formal or informal address, how the product name is treated, whether you translate feature names, tone, and the handling of English technical terms that native speakers actually use. Without it, two editors produce two defensible and inconsistent products.
The formal-or-informal decision is the one that matters most and it is a brand decision rather than a linguistic one. Several languages force a choice on every sentence, and reversing it later means re-editing everything.
Reviewer disagreement is normal and must have a resolution path. An in-country reviewer who dislikes a choice is giving an opinion unless it contradicts the style guide. Products where every reviewer comment is actioned drift into inconsistency and cost.
Measure what the users do, where you can. Conversion, task completion and support contact rate per locale say more about translation quality than any internal review, and they catch the case where a technically correct translation is commercially wrong.
Sample rather than review everything. A proportion of output checked properly by someone qualified beats a full review nobody has time to do carefully.
The per-word rate falls over time if you build the right things, and most projects never do.
A glossary of your own terms is the highest-value artefact. Product names, feature names, industry vocabulary, and the words you have decided to use for concepts. Without it, the same term is translated three ways across the product and users notice before you do.
Translation memory makes repeated content nearly free. Where the same or similar segment recurs, it is reused rather than re-translated. For a product with versioned documentation or a large interface, this compounds substantially across releases.
Both assets belong to you, not to your vendor. Make that explicit in the contract. A memory held by an agency you later leave is a switching cost disguised as a service.
Feeding the glossary into the machine translation step improves the raw output, which reduces post-editing effort, which is where the compounding actually happens. This is the mechanism by which localisation gets cheaper with scale, and it only works if somebody owns the glossary.
Review the glossary when the product changes. A new feature with a new name needs a decision in every language before marketing writes about it, not after.
Somebody has to own it. A glossary nobody maintains drifts out of date and becomes an argument rather than a reference.
A product that ships weekly cannot run localisation as a project, and this is the structural change most teams make late.
The batch model breaks immediately. Collect strings, send for translation, wait, receive, integrate, release. Any product shipping faster than that cycle accumulates untranslated content continuously.
Continuous means the pipeline runs on every change. New strings are detected automatically, machine translated immediately, queued for editing at the appropriate level, and merged when ready. The product ships with machine output in place and human quality follows.
That requires a fallback policy. What a user sees when a string has not been edited yet: the machine version, the source language, or a hidden feature. All three are defensible and the decision has to be made rather than defaulted.
It also requires that translation not block release, which is a cultural change as much as a technical one. Teams that gate deployment on complete translation ship slower in every language including their first.
Automate the extraction and the integration, and keep humans only in the editing. Every manual handoff in this pipeline is a place where work waits for days.
Machine translation quality improved enough to change the economics and not enough to change the structure, and conflating those two is where budgets go wrong.
What changed is the starting point. A decade ago machine output on many pairs was a draft you would often discard. Now, on well-resourced pairs and ordinary prose, it is frequently close enough that editing is faster than translating. That is a genuine shift and it is what makes the 35% to 40% discount possible.
What did not change is that somebody competent has to read it for anything that carries consequence. The failure mode of modern machine translation is not gibberish, which is easy to spot. It is fluent, confident, plausible text that says something slightly different from the source, which is harder to catch than a bad translation and more dangerous.
Large language models shifted the shape rather than removing the need. They handle context and tone better than earlier systems and they are more willing to invent. A model that smooths an awkward sentence into a fluent one has sometimes smoothed away a qualification that mattered.
The practical consequence is that review effort moved rather than disappeared. Less time fixing grammar, more time verifying meaning, and the second needs someone who understands the subject rather than only the language.
Do not re-evaluate your vendor every quarter on the strength of a model release. The structure of the work has been stable even as the output improved, and the organisations that got cheaper did it by building glossaries, memory and a pipeline, not by switching engines.
Some content carries consequences that make the saving irrelevant, and the list is shorter and more specific than caution suggests.
Anything legally binding. Terms, contracts, consent language, privacy notices. A subtly wrong translation of an obligation is an obligation you did not intend.
Safety and medical instruction. The error that matters is the one that reads fluently and says the wrong thing, which is exactly what machine translation produces when it fails.
Anything a regulator will read, where the requirement is often not merely accuracy but a specified form of words.
Brand-defining copy. A tagline translated literally is the standard cautionary tale, and the machine has no way to know that this sentence is the one that matters.
Everything else is a judgement about cost and consequence, and the useful discipline is to classify content once, by risk, rather than to argue about it per item. Most of a product's words are not in any of the categories above, which is precisely why the saving is real.
The engineering audit first, before any language is chosen. Extractable strings, no concatenation, plural support, layout tolerance, locale formatting, and a pipeline that does not need a developer in the loop. This is the part that determines whether the second language costs the same as the first or a tenth as much.
One language end to end second, chosen for commercial reasons rather than ease. Shipping one properly surfaces every problem the next nine would have hit.
Glossary and memory from the first word, owned by you, fed into the machine step.
Content classification third: which content gets full editing, which gets light, which gets none. Written down, agreed, and applied by the pipeline rather than by whoever is on deadline.
Then scale languages, where the marginal cost should be visibly lower than the first.
Our rate band is published: $40 to $100 an hour by role, blending to $60 to $70 for a mixed team, and the engineering work above is priced from it. Translation itself is bought per word at the market rates in this post. What we will tell you before any of it is that if your strings are still in your code, translation is not your first invoice.
Published rates put light post-editing at roughly $0.03 to $0.08 a word and full post-editing at $0.08 to $0.15, against $0.15 to $0.30 or more for human translation from scratch. Certified legal or medical content with post-editing runs $0.15 to $0.25, which is close to full human rates. One industry analysis puts the achievable discount from light post-editing at 35% to 40% off the normal word rate. These are vendor-published figures, so get quotes against your own content.
Light post-editing corrects errors of meaning, mistranslations and omissions, producing text that is accurate and reads like a translation. Full post-editing also fixes terminology, register and idiom so the text reads as though written in the language, and costs roughly twice as much. Light suits high-volume, low-stakes, short-lived content; full suits anything a customer reads while making a decision. Most products should use both, assigned per content type.
Because post-editing time is unrelated to segment length. A clean machine sentence needs a glance, while one where the meaning has been inverted takes longer than translating from scratch, since the editor must first notice the error. Output quality varies enormously by language pair and domain, so the per-word rate prices the wrong variable. Several practitioners quote hourly or derive a per-word rate from throughput, both attempts to price the thing that actually varies.
Audit the product's engineering. Strings must be extractable rather than embedded in code, templates or images; sentences must be whole with named placeholders rather than concatenated fragments, which breaks in languages with different word order, gender or case; plural handling must support more than two forms; layouts must tolerate text running substantially longer; and dates, numbers, currency, addresses and sort order must be locale-aware. This work determines whether the tenth language costs the same as the first.
A glossary fixes your product names, feature names and chosen vocabulary so the same term is not translated three different ways, and feeding it into the machine translation step improves raw output, which directly reduces post-editing effort. Translation memory reuses previously translated segments, which compounds heavily for versioned documentation and large interfaces. Both should be contractually yours rather than your vendor's, since a memory you cannot take with you is a switching cost.
Running translation as a pipeline rather than a project. New strings are detected on every change, machine translated immediately, queued for the appropriate level of human editing, and merged when ready, so the product can ship without waiting. It requires an explicit fallback policy for strings not yet edited — show the machine version, the source language, or hide the feature — and it requires that translation not gate release, which is a cultural change as much as a technical one.
Anything legally binding, including terms, contracts, consent language and privacy notices, where a subtly wrong rendering creates an obligation you did not intend. Safety and medical instructions, where the dangerous failure is fluent and wrong. Anything a regulator reads, where a specified form of words may be required. And brand-defining copy such as taglines, which the machine cannot know is the sentence that matters. Most of a product's words fall outside these categories, which is why the saving is real.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
