When to Trust Machine Translation and When to Pay a Human

Machine translation got genuinely good. For short, plain interface copy between well-resourced language pairs, current models produce output a native speaker would accept without noticing anything. That's a real change from a few years ago, and it means the default answer to "should I machine-translate this?" is now usually yes.

It also means the remaining failures are harder to spot, because they're surrounded by output that's fine. The useful skill isn't deciding whether to use machine translation — it's knowing which strings need a human to look at them, and what to look for.

The decision rule

Sort your strings by what a mistake costs:

Machine translate, ship without review. Navigation labels, button text, table headers, form labels, status names, generic empty states. Short, unambiguous, high volume, and a small error is a small embarrassment. This is most of your keys — often 80% or more.

Machine translate, then have a human review. Onboarding copy, error messages users act on, transactional emails, anything with a call to action, plural forms in languages with complex rules, tooltips explaining a concept. The translation will usually be right; when it's wrong the cost is a confused user or a support ticket.

Human translation, or human writing. Legal text, terms of service, privacy policy, financial disclosures, medical or safety information, marketing headlines, anything where a specific regulated phrase is required. Also anything where you want the copy to be good rather than correct — a headline that converts in English rarely translates into a headline that converts.

The line between the second and third categories is roughly: does this need to be accurate, or does it need to be persuasive? Machines are reliable at accurate. They're mediocre at persuasive, because persuasion depends on cultural context they don't have about your market.

The failure modes worth reviewing for

When you do review, these are the specific things that go wrong. Knowing them makes review much faster than reading everything with equal attention.

Missing context

The single biggest cause of wrong translations, and it's structural rather than a model weakness. A key like actions.open gives a translator — human or machine — no way to know whether "Open" is a verb on a button or an adjective describing a status. Many languages use different words.

// Ambiguous: is "Open" a command or a state?
'open' => 'Open',

// Unambiguous
'actions.open_file' => 'Open',
'status.ticket_open' => 'Open',

Same English word, two keys, and now translation can be correct for both. This is the highest-leverage thing you can do to improve translation quality, and it costs nothing at the time you write the key.

Short strings are worst affected. "Post" (noun or verb), "Order" (noun or verb), "Free" (no cost or available), "Right" (direction or correct) — all common in interfaces, all ambiguous without context.

Placeholders and word order

Machines usually preserve :name and :count, but not always, and a dropped placeholder is a broken string:

// en
'greeting' => 'Welcome back, :name!',

// A translation that lost the placeholder — renders without the name
'greeting' => '¡Bienvenido de nuevo!',

This is worth automating rather than eyeballing. Assert that required placeholders survive, as in the localization testing post:

expect(Lang::get('greeting', [], 'es'))->toContain(':name');

Also watch for placeholders that need to move. Languages with different word order may require :count before or after the noun, and a translation that keeps English order can read awkwardly even with the placeholder intact.

Plural forms

Machine translation of a plural line is unreliable, because the pipe-separated format is a Laravel convention rather than natural language. A model given ':count item|:count items' may return two forms for a language that needs six, and Laravel then silently falls back to the first segment.

Arabic needs six forms, Polish three under Laravel's rules. Generating those correctly requires knowing the target language's grammar and Laravel's format. Always verify plural lines, and use the pluralization tester to check the form count. Details in the trans_choice() deep dive.

Formality and register

Many languages distinguish formal and informal address — tú/usted, du/Sie, tu/vous. Machine translation picks one, often inconsistently across strings, and the result is an interface that switches register mid-flow. Native speakers find this jarring in a way that's hard to articulate but immediately noticeable.

Decide the register per language up front, document it, and check for consistency. This is a genuine advantage of reviewing in bulk rather than string by string — inconsistency is only visible when you see strings together.

Text expansion

Not a correctness issue but a layout one. German runs roughly 30% longer than English; Finnish and Russian expand too. A translation that's correct can still break a button. Review with the interface in front of you where possible, not just a spreadsheet of strings.

Terms that shouldn't be translated

Product names, feature names you've branded, technical terms your users know in English. Machine translation will helpfully translate "Dashboard" or your product name into something nobody searches for.

Keep a glossary of do-not-translate terms and check output against it. If your tooling supports a glossary, use it; if not, a list plus a grep is better than nothing.

Budgeting realistically

Rough shape of the cost for a typical app, with 800 keys and 5 target languages:

Machine translation covers all 4,000 strings for a cost that's essentially rounding error at this scale — a few euros of API usage, or a modest quota on a translation platform. Our cost calculator gives you the number for your key count.

Human review of the 20% that needs it — 160 keys × 5 languages — is 800 strings. A reviewer working through familiar interface copy manages a few hundred an hour, so call it a day or two per language for a first pass. Rates vary a lot by language and market; get quotes rather than trusting a generic per-word figure.

Human translation from scratch of the legal and marketing tier is priced per word by professionals and is the genuinely expensive line. Keep this tier small and deliberate.

The mistake in both directions is instructive. Teams that machine-translate everything and review nothing ship terms of service with a mistranslated liability clause. Teams that insist on professional translation for all 4,000 strings spend months and a large budget getting perfect translations of table headers.

A workflow that works

1. Write good keys. Namespaced by context, unambiguous, with a comment where the meaning isn't obvious from the key. This is where quality is won.
2. Machine translate everything. Get to full coverage immediately so nothing falls back to English while you deliberate.
3. Automate the mechanical checks. Placeholders present, plural forms sufficient, glossary terms untouched, key parity across locales. These are tests, not review.
4. Route by tier. Ship tier one. Queue tier two for review. Send tier three to a professional.
5. Review in context. Reviewers should see the interface, or at least the key and a description, not a bare list of strings.
6. Fix in production. When a native speaker reports an awkward string — and they will, months later — you want that to be an edit, not a deploy.

Step 2 before step 4 is deliberate. Complete-but-imperfect beats partially-translated: a user who sees consistent Spanish with one awkward phrase has a better experience than one who sees Spanish with English holes in it, and you get feedback on real strings instead of guessing.

On publishing unreviewed translations at scale

One caveat if the translated content is public and you care about search. Large volumes of unreviewed machine translation published as content pages is the kind of thing search engines' spam policies target. Interface strings in an application aren't what that's aimed at — but auto-generated translated content pages, at scale, with nobody reading them, is a real risk.

The distinction is roughly: machine translation as a production aid, reviewed before it represents you publicly, is normal practice. Machine translation as a way to generate pages you've never read is not. More on the search side in the multilingual SEO post.

Summary

• Most interface strings can be machine-translated and shipped. Reserve review for copy where errors cost something.
• Legal, financial, safety and marketing copy need humans — accuracy for the first three, persuasion for the last.
• Ambiguous keys are the top cause of bad translations. Namespace by context: actions.open vs status.open.
• Automate placeholder and plural checks; don't review those by eye.
• Always verify plural lines — machines get the pipe format wrong and Laravel fails silently.
• Decide formality per language and check consistency across strings, not per string.
• Keep a do-not-translate glossary for product and technical terms.
• Translate everything first, then review by tier. Complete beats partial.

That last point is the practical argument for AI translation inside your workflow rather than as a separate procurement exercise. LangSyncer translates missing keys with AI, keeps them in draft for review, shows coverage per language so gaps are visible, and publishes approved copy to production in seconds — so the string a native speaker flags next month is a two-minute fix rather than a release.