Automating multi-language translation: the part that is not translation

Machine translation is good enough for most content, which surprises people who last looked at it some years ago. That is also why translation projects still go wrong: the translation was never the hard part, and automating it leaves every surrounding problem untouched.

What actually determines whether a multi-language site works is terminology consistency, knowing what must not be translated, handling everything about a locale that is not language, and keeping versions in step as the source keeps changing. None of those is solved by a better model.

What we'll cover

• What machine translation does and does not solve
• Terminology, which is the main failure
• What must never be translated
• Building it with CodeWords
• Locale is more than language
• Keeping versions in step
• Review, and how much you need
• Deciding which languages at all
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What machine translation does and does not solve

Fluency is largely solved for major language pairs and ordinary prose.

Consistency is not. The same term will be translated three different ways across a site, which reads as carelessness rather than as a translation artefact.

Context is lost. A short interface string with no surrounding text is ambiguous, and "Open" as a verb and as a status translate differently in most languages.

Tone is approximate, and formality distinctions that matter in several languages are chosen without information.

Domain vocabulary is unreliable, particularly for anything technical, regulated or specific to your product.

Quality varies enormously by pair, and the languages with the least training data are frequently the ones with the most to gain.

Terminology, which is the main failure

Build a glossary first, of your product names, features, and the terms that carry meaning in your domain.

Include what not to translate in it, which is half its value.

Enforce it on every run, rather than hoping the model is consistent across separate calls.

Make it reviewable by whoever knows both the language and the product, which is a smaller group than either alone.

Keep the approved translation of each term, once decided, and never let it drift.

A glossary of fifty terms does more for perceived quality than a substantially better model, and it takes an afternoon.

What must never be translated

Product and feature names, unless you have deliberately localised them.

Code, commands, file paths and configuration keys, which break rather than read oddly when translated.

Placeholders and variables, including the ones inside sentences, where a translated placeholder silently produces a broken string.

Legal names, trademarks and regulatory terms, several of which have defined meanings.

Units and identifiers where the identifier is meaningful — an order reference, an error code.

Quotations and citations, where the translated version should accompany the original rather than replace it.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so the content source, the translation service, the review queue and the publishing system can meet in one pipeline.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: the languages, the glossary, what needs review, and where the output goes.
3. Authorize the connections — the content system, the translation provider, and the review destination.
4. Describe the exceptions: legal or regulated content, a string with placeholders, a source change to already-translated material.
5. Run it over existing content you already have translated and compare.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Locale is more than language

Dates, numbers and currency formats, which are the most visible errors and the easiest to get right.

Address and phone formats, which break forms rather than just looking wrong.

Units of measurement, including the conversions, which is a content decision rather than a formatting one.

Regional variants matter. One Spanish or Portuguese for everywhere is a decision with consequences, and it should be a decision rather than an oversight.

Text expansion. Translated text is frequently longer than the source, which breaks layouts designed around the original.

Right-to-left languages affect the interface, not only the text, and retrofitting that is substantial work.

Images and examples contain culture: names, screenshots with text in them, examples that do not transfer.

Keeping versions in step

The problem that grows rather than being solved, and the one that decides whether this stays maintainable.

Track which source version each translation came from, without exception.

Detect source changes and mark the affected translations as stale rather than leaving them silently wrong.

Distinguish a typo fix from a meaning change, since one needs retranslation and the other does not.

Show the reader when a page was last updated in their language, which is more honest than implying parity.

Decide what to show while a translation is stale — the old version, the source, or a notice — deliberately.

Accept partial coverage. Translating the most-read twenty per cent well beats translating everything badly, and pretending to full parity is what creates the maintenance problem.

Review, and how much you need

Tier by consequence. Legal, safety and pricing content needs human review; a blog post may not.

Review the glossary terms first, since fixing those fixes the most visible errors across everything.

Use native speakers who know the product, and accept that this is the constrained resource in the whole process.

Review a sample rather than everything, for lower-tier content, with the sample size driven by what you find.

Collect reader reports, with a simple way to flag a bad translation on any page, which is the cheapest quality signal available.

Feed corrections back into the glossary, or the same error recurs on every future run.

Deciding which languages at all

The decision that precedes everything above, and the one most often made by looking at a list of the largest markets.

Follow the traffic you already have. Analytics by country and by browser language tells you where people are already arriving and struggling.

Follow the revenue, which is frequently a different list from the traffic.

Ask support. The languages in which people already write to you, badly translated, are the clearest possible demand signal.

Count the real cost: content, support, sales material, legal review, and the ongoing maintenance of every one of them as the source changes.

Start with one, fully — content, support and the buying process — rather than several partially, since a half-localised experience converts worse than an English one.

Set a review point. A language that has not produced anything after a year is a maintenance cost, and deciding in advance how you will judge it makes retiring it possible.

Making it survive

Preserve formatting and markup through translation, which is a common source of broken output.

Validate placeholders survive on every string, and fail rather than publish when they do not.

Handle provider outages and rate limits by queuing.

Keep the source as the single origin. Editing a translation directly creates a fork that the next run overwrites.

Report the outcome: content translated, terms enforced, strings held for review, and translations now stale.

Limits worth knowing about

Quality varies by language pair enough that a single process may not be appropriate for all of them.

Regulated content often requires certified translation, which is a legal requirement rather than a quality preference.

Search behaviour differs by market, so translated content is not automatically findable content.

Support must follow. Publishing in a language you cannot answer questions in creates a problem rather than an audience.

Cultural adaptation is not translation, and some content needs rewriting for a market rather than converting.

What to build first

The glossary. Fifty terms — product names, features, domain vocabulary, and everything that must never be translated — enforced on every run. It is an afternoon of work, it does more for perceived quality than any model choice, and it is the artefact every other part of this process depends on.

Two habits make the difference. Record the source version behind every translation from the start, since without it you cannot tell which pages are stale and the whole thing degrades invisibly. And translate the most-read fraction of your content well rather than all of it badly, because partial coverage stated honestly is better received than a site that is uniformly slightly wrong.

Frequently asked questions

Is machine translation good enough now?

For fluency in major language pairs and ordinary prose, largely yes. Consistency, terminology, context for short strings, formality and domain vocabulary are not solved by it, and those are what readers notice.

What is the single biggest quality improvement available?

A glossary of your product names, features and domain terms — including what must never be translated — enforced on every run. Fifty terms does more than a better model.

What should never be translated?

Product and feature names, code and file paths, placeholders and variables, legal names and trademarks, meaningful identifiers, and quotations — which should accompany the original rather than replace it.

What breaks besides the words?

Dates, numbers, currency, address and phone formats, units, text expansion breaking layouts, right-to-left interface changes, and images containing text or culturally specific examples.

How do I keep translations current as the source changes?

Record which source version each translation came from, detect source changes, and mark affected translations as stale rather than leaving them silently wrong. Distinguish typo fixes from meaning changes.

Should everything be translated?

No. Translating the most-read twenty per cent well beats translating everything badly, and claiming full parity is what creates an unmaintainable backlog.

How much human review is needed?

Tier it by consequence. Legal, safety and pricing content needs review; a blog post may not. Review glossary terms first, since fixing those fixes the most visible errors everywhere.

What is the hidden cost of launching a new language?

Support. Publishing in a language you cannot answer questions in creates a problem rather than an audience, and it is usually discovered after launch.

How do I choose which languages to support?

From traffic and revenue you already have, and from the languages people already write to support in. Then count the full cost — content, support, sales material, legal review and ongoing maintenance — and do one language completely rather than several partially.

Is a half-localised experience better than none?

Usually not. A site translated without localised support or a localised buying process converts worse than leaving it in the original language, because it raises an expectation it cannot meet.

Why does editing a translation directly cause problems?

Because it forks the content. The source stays the single origin, so the next automated run overwrites the manual edit, and the correction is lost without anybody noticing. Corrections belong in the glossary or the source.

Does translated content rank in search automatically?

No. Search behaviour and the terms people use differ by market, so a faithful translation of content built around one market's search terms may be findable by nobody in another.

Related reading

• Automating knowledge base updates
• Automating blog post distribution
• Automating podcast transcription