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

To automate multi-language content translation, automate the glossary, the do-not-translate rules, the locale rules and version tracking, not just the translation. Machine translation is fluent enough for most content, which is why translation projects still go wrong: the translation was never the hard part, and automating it leaves every surrounding problem untouched.

Four things decide whether a multi-language site works: 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 changes. A better model solves none of them.

What we'll cover

• What machine translation does and does not solve
• Terminology is the main failure
• What must never be translated
• Building it with CodeWords
• Locale is more than language
• How to keep translated versions in step
• How much review you need
• How to decide which languages to support
• How to make the automation reliable
• Limits of translation automation
• What to build first
• Frequently asked questions

Key takeaways

• A glossary of your product names, features and domain terms, enforced on every run, improves perceived quality more than switching to a better model.
• Product names, code, placeholders, legal names and meaningful identifiers must never be translated.
• Each translation must record the source version it came from, so changed sources mark translations as stale.
• Review effort should follow consequence: legal, safety and pricing content needs human review first.
• Choose languages from the traffic, revenue and support requests you already have, and launch one language completely before adding another.

What machine translation does and does not solve

Machine translation solves fluency for major language pairs and ordinary prose. It does not solve consistency, context, tone or domain vocabulary.

Consistency is not solved. The same term is translated three different ways across a site, which reads as carelessness.

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. 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 by language pair. Languages with the least training data are often the ones with the most to gain.

Terminology is the main failure

Terminology is the main failure, so build a glossary first. A glossary lists your product names, features and the terms that carry meaning in your domain.

Include what not to translate. This is half the glossary's value.

Enforce the glossary on every run, instead of hoping the model is consistent across separate calls.

Make the glossary reviewable by someone who knows both the language and the product. That group is smaller than either alone.

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

A glossary of fifty terms takes an afternoon and does a great deal for perceived quality, because the glossary terms are the ones readers see most.

What must never be translated

Never translate the following items, because translating them breaks the content or changes its meaning.

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

Code, commands, file paths and configuration keys. These break when translated.

Placeholders and variables, including the ones inside sentences. 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, such as an order reference or an error code.

Quotations and citations. Show the translated version alongside the original, not instead of it.

Building it with CodeWords

CodeWords connects to 3,000+ integrations (CodeWords integrations page, 2026), 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, and a source change to already-translated material.
5. Run it over existing content that you already have translated, and compare.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan costs $0, Pro costs $39 per month and Business costs $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Locale is more than language

Locale covers everything about a market that is not the words. Check each of the following.

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

Address and phone formats break forms, not just the look of the page.

Units of measurement, including the conversions, are a content decision, not a formatting one.

Regional variants matter. Using one Spanish or Portuguese for every region is a decision with consequences. Make it a decision, not an oversight.

Text expansion. Translated text is often longer than the source and breaks layouts designed around the original.

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

Images and examples carry culture: names, screenshots containing text, and examples that do not transfer.

How to keep translated versions in step

Keep translated versions in step by recording which source version each translation came from. Version drift grows over time and decides whether a multi-language site stays maintainable.

Track the source version behind every translation, without exception.

Detect source changes and mark the affected translations as stale, instead of leaving them silently wrong.

Distinguish a typo fix from a meaning change. A meaning change needs retranslation; a typo fix does not.

Show readers when a page was last updated in their language. This is more honest than implying parity.

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

Accept partial coverage. Translating the most-read pages well beats translating everything badly, and claiming full parity creates the maintenance problem.

How much review you need

Review effort should follow consequence. Legal, safety and pricing content needs human review; a blog post may not.

Review the glossary terms first. Fixing those fixes the most visible errors across everything.

Use native speakers who know the product. They are the constrained resource in the whole process.

Review a sample, not everything, for lower-tier content. Let what you find set the sample size.

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

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

How to decide which languages to support

Choose languages from the demand you already have, not from a list of the largest markets. The decision comes before any automation.

Follow the traffic. Analytics by country and by browser language show where people already arrive and struggle.

Follow the revenue. The revenue list often differs from the traffic list.

Ask support. Languages in which people already write to you, through poor translation, are the clearest demand signal.

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

Start with one language, fully: content, support and the buying process. A half-localised experience converts worse than an English one.

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

How to make the automation reliable

A reliable translation pipeline protects formatting and placeholders, and never publishes a string that fails validation.

Preserve formatting and markup through translation. Broken markup is a common source of faulty output.

Validate that placeholders survive on every string, and fail instead of publishing when they do not.

Queue requests to handle provider outages and rate limits.

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 of translation automation

Translation automation has five limits.

Quality varies by language pair, so one process may not suit every language.

Regulated content often requires certified translation. This is a legal requirement, not 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, not an audience.

Cultural adaptation is not translation. Some content needs rewriting for a market, not converting.

What to build first

Build the glossary first: around fifty terms covering product names, features, domain vocabulary, and everything that must never be translated, enforced on every run. It takes an afternoon, and every other part of the process depends on it.

Two habits make the difference. Record the source version behind every translation from the start, because without it you cannot tell which pages are stale and the whole system degrades invisibly. And translate the most-read pages well instead of all pages 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, machine translation is largely good enough. It does not solve consistency, terminology, context for short strings, formality or domain vocabulary, and those are the problems readers notice. Add a glossary and review rules to cover them.

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. A glossary of around fifty terms improves visible quality across the whole site and takes an afternoon to build, which a model change cannot match.

What should never be translated?

Never translate product and feature names, code and file paths, placeholders and variables, legal names and trademarks, meaningful identifiers, or quotations. Show translated quotations alongside the original instead of replacing it. Translating these items breaks content or changes its legal meaning.

What breaks besides the words?

Dates, numbers, currency, address and phone formats, and units all break. Text expansion also damages layouts, right-to-left languages change the interface, and images with embedded text or culture-specific examples fail to transfer. Check each of these for every new locale.

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 instead of leaving them silently wrong. Distinguish typo fixes from meaning changes, because only meaning changes need retranslation. Show readers the last-updated date in their language.

Should everything be translated?

No, translate selectively. Translating the most-read pages well beats translating everything badly, and claiming full parity creates an unmaintainable backlog. Start with the pages that carry traffic and revenue, and expand only as fast as you can maintain quality. Review the list yearly, because the pages that earn their translation change as your markets change.

How much human review is needed?

Tier review by consequence. Legal, safety and pricing content needs human review; a blog post may need only a sample check. Review glossary terms first, because fixing those corrects the most visible errors everywhere at once. Increase review for legal, medical and pricing text, where an error costs far more than the review.

What is the hidden cost of launching a new language?

Support is the hidden cost. Publishing in a language you cannot answer questions in creates a problem, not an audience, and teams usually discover this after launch. Plan support, sales material and legal review for the language before you publish content.

How do I choose which languages to support?

Choose from the traffic and revenue you already have and from the languages people already use to write to support. Then count the full cost, including content, support, sales material, legal review and ongoing maintenance, and complete one language before starting another.

Is a half-localised experience better than none?

Usually not. A site translated without localised support or a localised buying process converts worse than the original-language site, because it raises an expectation it cannot meet. Finish one language end to end before adding the next. Mark clearly which sections are translated, so readers know what to expect before they start.

Why does editing a translation directly cause problems?

Direct edits fork 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. Make corrections in the glossary or the source so they persist on every future run.

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 not be findable in another market. Research local search terms for each language before you publish.

Related reading

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