The round trip
A content pipeline that works in one language tends to fail in a predictable place when it reaches five. The page is finished and approved. Someone exports it, usually as a spreadsheet, and sends it to the translation agency. Two weeks pass. The files come back, someone imports them, and the page that looked right in the source language now has a headline wrapping onto three lines, a button with its label missing and a paragraph that landed in the wrong component.
So the page goes back for fixes, which means another export, another wait, another import. Meanwhile the source page has changed, because nobody else stopped working, and the cycle starts again from a new baseline.
The cost is not the two weeks. It is that the two weeks repeat for every page, every market and every change.
Why layout breaks on the way back
The page you built is structured content: a headline field, an intro field, a list of feature blocks each with a title and a body, a call to action with a label and a link. The layout depends on that structure. The template knows a feature block has a title and sets it at a certain size.
An export flattens that structure. What the agency receives is a list of strings. A translator working in their own tool sees a line of text with no sign that it was a button label limited to two words. They translate it faithfully, which in several European languages means it comes back noticeably longer. On import the string goes back into its field, and the template does what it was told to do with text that no longer fits.
Nothing is broken. The structure was never sent with the text, so it cannot come back with it.
Translation as an editorial action
The approach we have scoped treats translation as something an editor does inside the content system, on the structured content itself, rather than something that happens to an exported file. An editor chooses the target markets and a machine assisted first pass fills the variant field by field. The first pass produces a draft and stops there. The headline stays a headline. The button label stays a button label, with the length constraint it had in the source language.
This does not necessarily replace the agency you already pay. It changes what they receive and how their work comes back: a draft in place instead of a spreadsheet of strings, and edits that land on the variant instead of in a file.
We scoped it for a five market rollout in a regulated sector, as an addition to an existing platform, using the content system's own editorial actions rather than a translation tool wired in beside it. It has not been delivered, and nothing here is a measurement.
The review gate
If your review function has told you it will never accept machine translation, take that at face value and design around it. The gate before publication stays human in every version of this approach. The machine produces a draft. A person decides whether it publishes, and nothing reaches a live market without that decision.
What changes is what the reviewer looks at. Today they review a file, usually without the layout, after the import has already happened. Inside the system they review the page as it will appear, in the language they are responsible for, with the source version alongside. If they reject it, the variant goes back to draft rather than starting another round trip.
We make no claim about the quality of machine output, and you should not make one to your reviewers. The claim is narrower: the draft arrives in context, and a person still decides.
Terminology as a shared asset
In the round trip model, terminology is decided per file, per agency, per round. The glossary lives in someone's inbox, and consistency depends on whether the same translator happened to get the same file twice.
Held centrally, terminology becomes a rule the system applies rather than a memory the translator carries. Product names that must not be translated, terms your sector uses in a specific way, brand phrasing that has already been argued over and settled: these are defined once and applied to every first pass in every market. When a term changes, it changes in one place, and the next draft carries it. A reviewer who finds a term wrong corrects the rule rather than the file.
Who owns which field
Most localisation arguments are field ownership arguments in disguise. The local market wants to rewrite the headline. Head office wants the product claims left alone. Both are right, and the argument repeats on every page until the decision is written down.
Some fields are global: product names, legal copy, claims that have been through review. Some are local: the headline, the intro, the testimonial. If a market insists on rewriting rather than translating, make those fields local by governance: a legitimate answer, and better than a copy that diverges silently. Variants keep divergence visible: when a global page changes after a local edit, the difference is in the system, not between two files nobody compares.
For the architect or IT lead: translations live as content in your own system, in the same structure as the source, so there is no second store to reconcile. They export with everything else, and changing supplier changes who edits the variant, not where it lives.
