How to Run a Localization Project with Machine Translation and Not Regret It

What's the actual question?

"How do I localize my product with machine translation without shipping garbage?" That's the question you typed into a search bar, and it's the one I'm going to answer. Not with a vendor pitch, but with a walkthrough. I've seen too many teams dump raw MT output into their app and then act surprised when users in Berlin or Tokyo bounce. You don't need a linguistics degree. You need a process.

Who this is for (and my blunt recommendation)

This is for product managers, indie developers, and in-house marketing teams who need to ship localized content in more than one language and don't have a full-time translation department. If you're a professional translator, you already know this stuff—skip ahead.

My recommendation, up front: use machine translation for high-volume, low-risk content (UI strings, support macros, internal docs) and never for your landing page headline or your legal terms without a human post-editor. The reason is simple: MT is fully automated and replaces the human during the translation phase, while computer-assisted translation (CAT) keeps the human in control. You want the human in control exactly where a mistake costs you money or trust. Everywhere else, let the machine run.

Step-by-step: how to actually do this

1. Inventory your content by risk. Before you touch any tool, sort every string into three buckets: (a) disposable (log messages, internal notes), (b) functional (buttons, form labels, error messages), and (c) brand-critical (homepage, checkout, legal). This sounds obvious, but most teams skip it and then treat all three the same. Don't.

2. Pick your engine per bucket. For bucket (a) and (b), a neural engine is fine. DeepL Translator launched in August 2017 and supports multiple European languages; Google Translate and Microsoft Translator are also NMT-based. For bucket (c), you're going to use a CAT tool with a translation memory, not raw MT. Translation Memory is a database of previously translated segments that gets reused, which keeps terminology consistent across releases. That matters more than raw speed.

3. Prepare your files in a standard format. Don't send a spreadsheet. Use XLIFF, the OASIS-standard XML format that holds source and target segments together. Microsoft's localization guidance lists XLIFF, TBX, and TMX as the standard interchange formats for CAT tools. XLIFF 2.1 was approved as an OASIS Standard on 13 February 2018. If your vendor asks for "just a CSV," push back—you'll lose segment context and create rework.

4. Pre-translate with MT, then post-edit. This is the workflow that made Google Translator Toolkit (2009–2019) popular: split documents into segments, pre-translate from TM, and fall back on MT when there's no match. It still works. The key is that a human post-editor reviews the MT output. ISO 18587:2017 specifies requirements for full human post-editing of MT output and for post-editor competences. If your vendor can't tell you what standard they post-edit against, that's a red flag.

5. Measure post-editing effort, not just speed. Human-targeted Translation Edit Rate (HTER) is widely used as a proxy for post-editing effort: it counts the edits a human makes to turn MT output into something acceptable. Ask your vendor for HTER numbers per language pair. If they can't provide them, you're flying blind.

6. Build a glossary and lock it. Domain-specific terminology is where MT falls apart. A termbase (TBX format) forces consistency. This is the single highest-leverage thing you can do for a technical product.

7. Run a pilot on one language. Don't localize into twelve languages at once. Pick your highest-value market, run the full pipeline, and measure. Then scale.

What can go wrong

The classic failure: you skip post-editing because the MT output "looks fine" in English. It isn't fine. MT output often requires human post-editing for idiomatic expressions, cultural nuance, and domain-specific terminology. I've watched a SaaS company ship a German UI where the MT rendered "sign up" as a literal physical signature request. Users were confused. Support tickets spiked. The fix cost more than the post-editing would have.

Second failure: trusting BLEU scores as your quality gate. BLEU was introduced by IBM researchers in 2002 and scores translations on a 0 to 1 scale by comparing n-gram matches to human references. But BLEU correlates poorly with human judgment, which is why newer metrics like COMET and BLEURT are becoming standard. If a vendor leads with BLEU alone, ask about COMET or chrF—chrF is language- and tokenisation-independent, which helps for morphologically rich languages.

Choose your tool by what you're localizing

One more thing: if you're localizing into a low-resource language, check whether your engine even supports it. Meta's NLLB-200 covers 200 languages, but most commercial engines cover far fewer. If your target language isn't supported, you need a human translator, full stop.

• Use MT for scale, humans for nuance.
• Standardize on XLIFF for handoffs.
• Demand HTER or COMET numbers, not BLEU alone.

Takeaway

Localization with MT is not a plug-in; it's a pipeline. Sort your content by risk, pre-translate with MT, post-edit against ISO 18587, and measure effort with HTER. Do that, and you'll ship faster without shipping embarrassment. Skip it, and you'll spend your next quarter apologizing in a language you don't speak.

Sources

• Machine translation (Wikipedia) - https://en.wikipedia.org/wiki/Machine_translation
• ISO 18587:2017 (ISO) - https://www.iso.org/standard/62970.html
• Translation Edit Rate (ACL Anthology) - https://aclanthology.org/2006.amta-papers.25/
• IBM Research - https://research.ibm.com/blog/bleu-nlp-benchmark-anniversary
• Localization file formats (Microsoft Learn) - https://learn.microsoft.com/en-us/globalization/localization/localization-file-formats