Machine Translation vs Human Review: A Routing Framework for i18n Leads
Two teams ship to 20 languages. Team A pays $400K a year in human translation. Team B pays $80K. Team A shows up in more support tickets. Team B does not.
Team B is not using cheaper translators. Team B is routing intelligently. That is the entire game.
What is translation routing?
Translation routing is the set of rules that decide, for every string that enters your pipeline, whether it goes straight to production on machine translation, gets a light human spot-check, or requires full human review before shipping. The rules combine three factors: which language, what kind of surface, and how confident the MT engine is in its own output.
A team without a routing framework defaults to one of two failure modes. Either everything gets full human review, which burns budget and slows releases. Or everything ships on MT, which produces the "we translated our checkout page with Google Translate" news cycle nobody wants. Both failures come from treating translation as a uniform commodity when it is actually a spectrum of risk.
How should you tier your languages?
Not every language is worth the same to your business. Build the tiers explicitly.
- Tier 1: revenue-critical languages. The top 3 to 5 languages by pipeline, ARR, or strategic weight. For most US-founded B2B SaaS, this is German, French, Japanese, and one of Spanish or Portuguese. These languages get full human review on every string.
- Tier 2: growth languages. The next 5 to 10 languages where you have paying customers and active marketing but not yet a dedicated CS or sales team. Route billing, legal, error, and onboarding strings through humans. Ship everything else on MT with a monitoring loop.
- Tier 3: long-tail languages. Everything else. Shipping in these languages is a coverage play, not a revenue play. MT ships. A human reviews the top 20 CS ticket themes per language, once a month.
The tiering is a business decision, not a linguistic one. It should be revisited quarterly with revenue data, not set once at launch and forgotten.
How should you classify surfaces by risk?
Independent of language, some strings carry more risk than others. Rank them.
| Surface | Risk category | Default routing |
|---|---|---|
| Billing, invoicing, refund policy | High (financial + legal) | Human review, always |
| Terms of service, privacy notice | High (legal + regulatory) | Human review, always |
| Error and system status strings | High (support cost) | Human review for Tier 1 and 2 |
| Onboarding and first-run UI | Medium (conversion impact) | Human review for Tier 1, MT with spot-check for Tier 2 |
| In-app tooltips, help text | Medium (usability) | MT with spot-check for all tiers |
| Marketing microcopy, empty states | Low | MT with monitoring |
| Blog posts, help center articles | Low (unless legal) | MT with monitoring |
The one surface teams underestimate is error strings. A mistranslated error message doubles as a mistranslated support onboarding: the user has already hit friction, and now the friction is compounded by language friction. Route these carefully.
How does MT confidence scoring fit in?
Every modern MT engine returns a confidence score with its translation. Use it. The three-band rule:
- Above 0.90. Auto-approve. The MT output is at or above human parity for that string pair. Ship it. Log for monitoring.
- Between 0.75 and 0.90. Spot-check. Route to a reviewer who confirms or edits within 24 hours. Do not block the release.
- Below 0.75. Full review. The engine is uncertain. This almost always correlates with source-string ambiguity, missing context, or unusual terminology. A human should look.
Tune the thresholds based on defect data from your first month. If auto-approved strings generate visible defects at more than 1 percent, raise the threshold. If your spot-check queue is bottlenecking releases, invest in reviewer capacity or lower the threshold selectively.
What glossary and tone controls should you enforce?
Constraints, not suggestions. Two mechanisms enforce consistency.
- Term dictionaries fed to MT at inference. Modern MT APIs accept glossary constraints. Your brand name stays untranslated. Your product terms have canonical translations per language. This bias happens at generation time, not after.
- Post-translation lint that runs in CI. For every translated string, check that do-not-translate terms are unchanged and that glossary terms match the canonical translation. Fail the build on drift. This is your safety net when the MT engine ignores the constraint, which happens more often than the API docs suggest.
Tone rules are harder to enforce mechanically. Get the top 200 most-visited strings reviewed by a human in your top languages, and use those as tone anchors when onboarding new reviewers.
When should you use community or crowd translation?
Rarely, and only for specific cases. Community translation works when the community is invested (developer tools, open source projects, hobbyist software), your product terminology is stable, and you have moderators who can catch drift. It fails when the community is thin, the terminology is domain-specific, or the tone needs to be tightly controlled.
For B2B SaaS, community translation is almost never the right choice for revenue-critical strings. It can work for help center content, documentation, and long-tail language coverage, as long as a paid reviewer approves community contributions before they ship.
What should the routing look like in a live pipeline?
Automated, transparent, and auditable.
- Every new string enters with a language tier, a surface risk classification, and an MT confidence score. All three are metadata on the string.
- A routing engine reads the three fields and assigns the string to one of four queues: auto-approve, spot-check, full-review, or hold-for-context.
- Reviewers work their queues. Auto-approve strings flow to production immediately. Everything else flows on approval.
- A monitoring dashboard tracks defect rates by tier, surface, and confidence band. Thresholds get retuned based on data.
The dashboard is what makes the framework a system rather than a wish. Without measurement, teams cannot tell whether their routing is too generous or too conservative.
The mistake to avoid
Most teams pick one policy for all translation: either full human review, which is expensive and slow, or MT everything, which is cheap and embarrassing. Both are the same mistake, which is treating translation as a uniform activity rather than a spectrum of risk. Build the routing rules explicitly. Measure defects by tier and surface. Retune quarterly. The teams that do this ship more languages faster, spend a fraction of the budget, and take fewer support tickets. The teams that do not still think their translator is the bottleneck.
Frequently asked questions
Has machine translation gotten good enough to ship without review?
For long-tail languages and low-stakes surfaces, mostly yes. Modern neural MT combined with a glossary and tone rules produces output that is grammatically correct and semantically close to intent for 85 to 95 percent of strings in most language pairs. The failure cases are idioms, ambiguous source strings, and terminology that requires domain knowledge. Those are exactly the strings you want a human to touch, and confidence scoring surfaces them automatically.
What is the ROI of routing MT vs full human review?
For a team supporting 15 languages with 5000 strings updated per quarter, full human review costs roughly $60K to $120K per quarter. Intelligent routing that sends 30 to 40 percent of strings to human review and the rest to MT with monitoring runs $20K to $40K for equivalent quality on the surfaces that matter. The savings compound as you add languages, because MT scales without a linear cost increase and human review does not.
How do we handle terminology consistency with MT?
Feed your glossary and do-not-translate list into the MT provider as constraints, and check compliance in CI. Modern MT APIs accept term dictionaries at inference time and will bias outputs toward your preferred translations. Combined with a post-translation lint that fails the CI check if any term deviates from the glossary, you get consistency without human touch on every string. The lint is the important part. MT constraints alone drift.
Which languages should never ship on MT alone?
Any language where a mistranslation could trigger a regulatory violation, a lawsuit, or a churn event. That usually means your top 3 to 5 revenue languages plus any language covered by explicit compliance obligations (EU languages under GDPR privacy notices, Quebec French under Bill 96, and so on). Long-tail languages can ship on MT with a monitoring loop that catches the 1 to 3 percent of strings that generate the most user friction.
What confidence threshold should we use for MT auto-approval?
Start at 0.90 on a normalized 0 to 1 scale and tune based on your first month of defect data. Strings above 0.90 auto-approve, strings between 0.75 and 0.90 route to a spot-check reviewer, strings below 0.75 route to full human review. If your defect rate on auto-approved strings exceeds 1 percent, raise the threshold. If your reviewer queue is bottlenecking releases, lower it after fixing the top defect categories.
Ship every language the day you ship English
Thalarum syncs strings from your repo, drafts translations with your glossary, routes review, and blocks broken releases in CI.
Request early access