Machine translation: what can ship without anyone reading it

Machine translation rarely enters a company through a decision. It enters when someone in marketing pastes a product description into a browser translator, drops it into the French catalogue, and nobody notices for two years. The problem isn't that the translation is bad — these days it's usually fine. The problem is that there is no way to know which of your 4,000 product pages went through that route, who checked them, and what happens if one of them says "non-flammable" where the original said "flammable".

This guide is about the opposite: running machine translation in a company so that you always know which text shipped unreviewed, which text a person signed off, and what each option costs. It isn't a model problem. It's a problem of process, glossary, and deciding — content type by content type — how much risk each piece of text can absorb.

What has actually changed in machine translation?

What changed isn't average quality: it's quality in hard contexts. The neural translators of a few years ago worked sentence by sentence and lost everything beyond the full stop. Today's language-model-based systems work with the whole document, which fixes three things that used to wreck any catalogue:

• Gender and register. "You" can be informal or formal. The model can now hold the same choice across twenty paragraphs if you tell it to.
• Your own terminology. If your product is a "cutting head" and never a "cutter head", you can now impose that choice through a glossary instead of hoping.
• Formatting. HTML tags, template variables like `{customer_name}`, units and references survive the trip far better than they used to.

What hasn't changed: the system doesn't know what isn't in the text. If the source page says "food-safe" and that claim requires a specific certification in Germany, no translator will warn you. That remains the job of a person who knows the market.

The second thing that hasn't changed: the model never says "I don't know". Faced with an internal abbreviation it doesn't understand, it won't leave a gap — it invents something plausible. That is the real risk, and it's why the important question isn't "which model do I use?" but "which text can be published without anyone reading it?".

What ships automatically and what needs a human?

This is the central decision of the project, and it isn't taken by language or by department. It's taken by consequence of error. Text that, if wrong, triggers a return, a fine or an accident gets a human. Text that, if wrong, triggers a raised eyebrow ships on its own.

| Content type | What a mistake costs | Level | |---|---|---| | Spec sheets, usage instructions, safety | Legal or physical risk | Human translation, or full post-editing by a specialist | | Terms of sale, warranty, returns policy | Claims, direct cost | Full post-editing | | Commercial product descriptions | Lower conversion | Light post-editing, or automatic with glossary if the catalogue is huge | | First-line support replies | Confused customer, escalates | Automatic, with a clear handover | | Internal knowledge base, minutes, project docs | Fixable misunderstanding | Automatic | | Customer reviews, forum comments | Nothing | Automatic |

The right-hand column is an internal contract, not a recommendation. Write it down, approve it once, and keep it somewhere visible — what kills these projects is the silent exception: someone is in a hurry, skips a level, and nobody finds out.

On the two kinds of review, known in the industry as post-editing:

• Light post-editing. You fix what's wrong: meaning errors, terms, figures. You don't touch style. The result is correct and understandable, not beautiful. Right for catalogue and high-volume documentation.
• Full post-editing. The text ends up reading as if a native of that market wrote it: rhythm, idiom, calls to action that work there. For the homepage, campaign landing pages and anything contractual.

How does the cost compare with human translation?

Market figures for Spain, useful as an order of magnitude when budgeting (always get a firm quote from your supplier — rates vary a lot by language pair and specialism):

| Option | Approximate cost | Speed | When it makes sense | |---|---|---|---| | Professional translator | €0.08–0.15/word | Days | Contracts, safety, brand campaigns | | Full post-editing | 50–70% of the human rate | Hours | Important commercial copy, main site | | Light post-editing | 30–50% of the human rate | Hours | Catalogue, manuals, documentation | | Automatic with glossary | Cents per thousand words | Minutes | High volume, low risk |

The gap between the first row and the last is three orders of magnitude, and that's the trap in these projects: the saving looks so obvious on paper that everything gets pushed into the bottom row. The cost missing from the table is a mistake sitting live for two years across 4,000 pages, which isn't fixed by a translator but by someone reviewing the entire catalogue.

The honest way to budget is by tier: count the words at each level of the previous table, apply that row's rate, and add it up. If the result is still 70% cheaper than translating everything by hand — the usual outcome when there's a lot of catalogue — the project defends itself without any need to oversell it.

And one line item that is almost always forgotten: maintenance. Catalogues change. Every change in the source text forces a retranslation of that fragment in every language. Without a process to detect what changed, six months later you have an up-to-date Spanish version and five versions drifting out of sync.

What is a brand glossary for, and how do you build one?

The glossary is what separates a correct translation from a translation that sounds like you. It's a table with three columns: source term, required translation per language, and a usage note. That's it.

What belongs in it:

• Product and range names, including the ones that aren't translated.
• Industry terms where two valid options exist and you use one.
• Interface vocabulary: "cart", "my account", "order", "delivery note". It has to match whatever your shop or ERP says, or the customer reads one thing in the email and another on screen.
• Legal boilerplate already signed off by counsel in each market.
• Register decisions: if you're formal in German and informal in English, write it down.

How to start without turning it into a six-month project: pull the 300 most frequent terms from your catalogue, run them through the translator, sit down with whoever sells in that country, and correct. That's two afternoons. That glossary goes into every request to the system and is what makes the output consistent across the website, the emails and support. It's exactly the principle we apply when writing instructions for production: context you don't supply gets invented — we covered it in prompt engineering for business.

A well-argued 300-term glossary improves perceived quality more than switching translation vendors.

The glossary's sibling is the translation memory: the store of approved source-target pairs. Every time a person corrects a sentence, that correction is saved and reused. It's an asset that stays with you. Before signing with any vendor, ask who owns that memory and in what format they hand it over if you leave.

How do you integrate this without touching the catalogue by hand?

The pattern that works has four pieces, none of them exotic:

1. Change detection. Something that knows which texts are new or have changed since last time. In ecommerce, the PIM or the CMS itself; in documentation, version control. Without this there is no process, just manual exports to spreadsheets. 2. Translation with context. The request to the model carries the text, the glossary, the content type and the matches from the memory. You don't send the bare sentence. 3. Review queue. Anything needing a human shows up in a list with the source alongside it, not in an email with an attachment. The reviewer should approve or correct in two clicks, and their correction feeds the memory. 4. Publishing and traceability. Every published text records where it came from: automatic, post-edited or human, with a date and an approver. This is the piece people skip, and the one that saves you the day somebody asks about a specific page.

Two integration warnings. First: watch out for email templates and variables. A model will cheerfully translate `{order_id}` and break the dispatch. You protect those by marking them as non-translatable. Second: URLs and metadata. Translating a page slug changes the address; if you do it, you need redirects and correct hreflang tags, or you lose the ranking you already had in that market.

If the text ends up in your shop, read this alongside what affects search and the product page in AI for ecommerce; and if the case is multilingual support, the line between what the machine answers and what escalates to a person is covered in chatbots for business.

How do you know it's working?

Three measures are enough, and all three come out of the flow itself:

• Edit rate. What percentage of the sentences sent to review end up modified, and by how much. If it drops month on month, the glossary and the memory are doing their job. If one language pair plateaus at a high percentage, that pair needs a real translator, not another tweak.
• Incidents by language. Complaints, returns or tickets where the customer says "I didn't understand" or "it said something else". It's the only metric that measures actual damage.
• Time to publish. How many days — or hours — it takes a new product to be live in all six markets. This usually carries more weight with management than the saving does.

A warning about automated quality scores: they're useful for comparing two configurations against each other, not for deciding whether a text is publishable. A text can score high and still say something legally disastrous. For what matters, a sample reviewed by someone from that market is still the only judge.

What usually goes wrong?

• Translating into the wrong variety. Neutral Spanish for both Mexico and Spain is a decision, not an oversight — but it has to be made deliberately and written into the glossary.
• Starting with the public website. It's the most visible content and the most style-sensitive. Start with internal documentation or the support knowledge base: mistakes are cheap there and the learning is identical.
• Not cleaning the source. If your source pages have typos, internal abbreviations and half-finished sentences, translation multiplies them by six languages. Good source material is 80% of the result; it's the same argument as data quality, applied to text.
• Leaving review without an owner. "The French rep will look at it when he can" means nobody looks at it. Assign a person, a weekly volume and a deadline.
• Pasting customer data into a public translator. A support ticket carries a name, an address and sometimes bank details. That requires a vendor under a data processing agreement and a written policy on what can be pasted where.

Frequently asked questions

Does machine translation already replace a professional translator?

Not everywhere. It replaces well in high-volume, low-risk content: catalogue, internal documentation, first-line support. It doesn't replace contractual or regulatory text, nor the brand piece where style is the product. In a mid-sized company the usual answer is a mix, not a choice.

What data should I never send to a machine translator?

Personal data about customers or employees, health information, anything under NDA, and anything you wouldn't email to a third party. If text containing personal data has to be translated, you need a vendor under a data processing agreement and, where possible, anonymisation before sending.

How long does it take to build something usable?

A first full circuit for one content type — initial glossary, translation with context, review queue and publishing — is usually a matter of weeks, not months. What stretches the timeline is never the model: it's agreeing on terminology and deciding who reviews.

Do I need to change my CMS or ERP for this?

Almost never. The normal approach is to hang it off what you already have via API or a scheduled export. The thing worth checking carefully is whether your system handles multiple languages per record cleanly; if it doesn't, that's the first problem to solve, and it comes before translation.

---

If you're weighing up opening new markets, or you already have six languages drifting out of sync, the useful move isn't picking a translator: it's writing down which content can ship unreviewed and which can't. That table takes an afternoon and decides the whole budget. If you'd like us to look at your catalogue and publishing flow before anything moves, start with the audit or tell us about it at let's talk.