Machine translation vs human translation

The argument usually gets framed as a quality question, which is why it never resolves. The productive framing is per content type: some strings should never be machine translated, some should never be human translated because nobody will ever read them, and most of the volume sits in between where the right answer is machine translation with human review.

What each is actually good at#

Machine translation is fast, effectively free at the margin, available in a hundred languages instantly, and completely consistent — it will make the same mistake every time, which at least makes it findable. It handles long-form prose with internal context well.

Human translation understands context, register and intent. It knows that your product’s “workspace” is a specific noun and not a description of a desk. It can decide that a literal translation of a marketing headline is technically correct and commercially useless. It asks questions when a string is ambiguous — which is worth more than it sounds, because that question usually reveals a source-copy problem affecting every language.

Where machine translation fails in software specifically#

Generic MT criticism talks about nuance and idiom. In software localization the failures are more specific and more mechanical.

Short strings have no context. This is the big one. Open, Close, Save, Back, Share — a model sees one word and has to guess whether it is a verb on a button or an adjective describing state. In most target languages those are different words, and it will pick one at random. Interface strings are overwhelmingly short.

Placeholders get mangled. %{count} becomes %{compte}, {{name}} gets spaces inserted, %1$s loses its index. See the placeholder formats cheat sheet for the syntaxes at risk.

Plural structure is not preserved. A traditional engine translates a string, not a set of forms. Feed it English one/other and you get two translated strings, which is wrong for Polish and badly wrong for Arabic.

Terminology drifts. Nothing constrains the model to your glossary, so your product’s core noun gets translated three different ways across one screen.

Gender and formality are guessed. Languages with formal and informal address force a choice on every sentence. A model with no instruction picks inconsistently, and the interface reads as though written by several people who had not met.

Where it works well#

Being fair about this matters, because blanket refusal wastes real money:

• Long-form content — documentation, help centre articles, release notes. Enough surrounding context for the model to disambiguate, and low cost of a slightly awkward sentence.
• High-volume, low-value content — user-generated content, product catalogues with thousands of near-identical descriptions, archived material.
• Languages you would otherwise not support at all. Imperfect Vietnamese is better than no Vietnamese for a user who currently gets English.
• First-pass drafts for post-editing. The largest practical use. A human editing decent machine output is meaningfully faster than a human translating from nothing.
• Internal-facing text that needs to be understood rather than polished.

A decision table#

The pattern: inverse to how short and how prominent the string is. A four-word button seen by every user on every session deserves a human. A 2,000-word support article seen by 40 people a month does not.

AI models changed the calculation, in one specific way#

Newer AI-based engines are not dramatically more fluent than good neural MT for mainstream language pairs. Where they differ, for software specifically, is that they can be told about structure and instructed about intent.

Concretely, WebTranslateIt’s Gemini and Mistral integrations:

• Translate every plural form at once and expand the set to the target language’s CLDR rules — English one/other becomes Polish one/few/many/other.
• Understand ICU MessageFormat, translating only the human-readable text while leaving variable names, keywords and brace structure intact.
• Read developer comments attached to the segment, which is the mechanism for solving the Open-the-verb problem — if the comment says “button label”, the model has what a human would have needed too.
• Use your term base, so glossary terms come out consistent.
• Accept project-level and locale-level instructions setting tone, register and formality once rather than per string.

That list is the actual difference. It moves MT from “generates plausible text that breaks the build” to “generates structurally valid text that needs reviewing for meaning” — which is a much better starting point for a human.

Translation memory sits above both#

Worth stating clearly because it is often left out of the comparison: translation memory beats both when it hits. A 100% match is a translation a human already wrote and approved for your product. It is more reliable than MT and free compared to new human translation.

The sensible ranking for any segment:

1. Exact match from your own memory — reuse it.
2. Fuzzy match — edit it.
3. Machine translation — post-edit it, if the content type warrants it.
4. Human from scratch — for everything above the line in the table.

Most platforms, WebTranslateIt included, present suggestions in roughly this order for exactly this reason.

What post-editing actually means#

The middle ground has a name and two recognised levels, and agreeing which one you are asking for prevents a lot of disappointment.

Light post-editing fixes only what affects meaning: mistranslations, omissions, mangled placeholders, wrong terminology. Awkward phrasing is left alone. The output is accurate and reads like a machine wrote it. Appropriate for documentation and help content where the reader wants the answer rather than the prose.

Full post-editing brings the text to the standard a human translator would have produced — accurate, natural, consistent in register. Slower, and for most content types the cost approaches translating from scratch, which is precisely why the content-type decision matters more than the MT quality does.

The mistake is asking for “post-editing” without specifying which, then being surprised by either the bill or the quality.

Practical advice#

Decide per content type, in advance, and write it down. The decision is a policy question, not a per-string judgement, and making it once stops it being relitigated every sprint.

Never ship raw MT for interface strings. If the budget does not stretch to human translation of your UI, translate fewer languages properly rather than more languages badly.

Give the machine what you would give a human. Developer comments, screenshots, a term base, tone instructions. Models are limited by context, and most teams supply none.

Measure post-editing effort, not MT quality. How much of the output survives review is the number that maps to cost. Automated quality scores do not.

Watch for the compounding error. Machine output that gets approved enters your translation memory, and is then offered as a “previous human translation” forever. Keep post-edited and raw MT distinguishable, and do not let unreviewed output into the memory.