Multilingual content operations rarely break the day you launch the second language. They break about three languages later, quietly, in ways nobody put on a dashboard. The German site stops matching the English promotion by a week, a legal line changes in the Spanish footer and nobody catches it, the Turkish product title gets a stray English word in the H1, and the attribution team starts to notice that non-English markets convert worse than their traffic suggests they should.
None of that reads as a crisis. Each item is a nuisance for a different team. Added up over a year, it is a line of lost revenue that nobody owns, and we have watched more than one organisation discover it only when a localisation audit lands on a CFO’s desk.
The frame I would offer a buyer thinking about this: multilingual content is not a translation question. It is an infrastructure question dressed up as a translation question, which is why it is almost always underbudgeted at the point where it starts to hurt. The person on the record who says this most plainly runs the function at a company that handles 79 billion words a year, and he is worth listening to.
The Catch-22 Sits Where Two Teams Share the Problem and Neither Owns It
Mik Szajna, Head of Localisation at Booking.com, put it on DeepL’s New Fluency podcast earlier this year: “The main challenge is knowing where to begin.” On the surface that sounds like a scoping line. It is not. It is the honest admission that at any serious scale the localisation function has more surfaces to fix than it has budget, and the question is not which fix is biggest but which one costs the most in downstream revenue when it goes wrong.
Szajna’s team supports 45 languages and more than 100 content types, processing roughly 79 billion words a year, around 200 million a day, per the DeepL article summarising the episode. At that volume, as the piece puts it, “localisation becomes an infrastructure problem rather than a content problem.” If you are not Booking.com, your version of this problem is smaller but it has the same shape, and it bites earlier than most teams expect.
Localisation becomes an infrastructure problem rather than a content problem.
DeepL, The New Fluency, summarising Mik Szajna, Head of Localisation at Booking.com
Sizing It: The Industry Itself Is Admitting the Model Has Changed
The macro picture is useful because it tells a buyer where the pricing conversation is actually going. In its 2026 predictions, published 20 January 2026, CSA Research writes that “translation revenue is expected to decline even as global content volumes grow”, with AI compressing per-word prices even as the number of surfaces to localise rises. The same note calls for enterprises to “invest in governance frameworks for managing global content operations”, and flags “increasing governance requirements around compliance, risk, and accountability.”
Read that two ways. The first is price: the hour you buy from a language service provider is cheaper than it was, which looks like a win on the invoice. The second is cost: the thing that used to be bundled into that hour, the quality control, the governance, the context, is now your problem, and if you have not built the infrastructure to do it yourself, you are paying for the cheap translation with mistakes further down the funnel.
CSA’s longer January report, The Transformational Imperative: Reframing Global Content, co-authored by Donald A. DePalma, Arle Lommel, Alison Toon and Fatima Bengana (published 30 January 2026), argues that global content has moved from being a translation task to being an enterprise transformation. We agree, and we would add the operational corollary: once a buyer accepts that framing, the budget line sitting under “translation” is the wrong line to grow. The one that needs to grow is the one that reads “content infrastructure”.
Lever One: What Breaks First Is Architecture, Not Vocabulary
Szajna’s point about Booking.com is that there is no uniform process. Different content types get different treatment, and the team keeps checking whether each approach works. That is the shape of a mature localisation operation, and it is a shape that only emerges after a few painful cycles of discovering that one pipeline cannot serve both a product description and a legal disclaimer.
The clearest published account of what breaks when you push the number of languages up fast is the Spotify engineering post Scaling Translations at Spotify, written in September 2022 by Tommy Tynjä, Senior Engineering Manager, and Martiño Prada Díaz, Director of Localization. Spotify went from 26 languages to 62 in a six-month window. Discovery alone took two months and produced a 25-page write-up. The automated changes touched more than 30 backend services. The authors are blunt: “Adding just one new language has not been as straightforward as one might think,” and they attribute the complexity to a stack grown through hypergrowth, where “Conway’s law manifests itself in our architecture.”
Translated for a buyer: the organisational chart you had when you launched in two markets is the thing fighting you when you launch in ten. Content lives in the systems the teams that owned it in 2020 happened to use, and nobody budgeted the work of reconciling them before adding the fifth language. The fix is boring. Someone has to own the content model across teams, and they have to be senior enough to say no to a product group that wants to put its microcopy somewhere clever.
Lever Two: Quality Estimation Is Where the Money Hides
Booking.com’s loop is instructive because it exposes the thing most teams do by instinct and should do by rule. Szajna’s team pairs quality estimation with automated post-editing, and he is clear on the trap, per the DeepL summary: over-correction by human editors confuses the model, which then applies the wrong threshold, which then feeds back into future outputs. In plain English, if your editors are quietly rewriting the machine every time, you are not improving the system, you are teaching it to need rewriting.
Only a small number of buyers I have talked to this year have anything resembling an acceptance-threshold policy for machine output. Most either accept everything the vendor returns, or edit everything in-house and lose the economics of using machine translation in the first place. The middle position, where a quality estimation score decides which strings get human review and which do not, is where the margin lives, and it is where the governance work CSA keeps flagging actually has to be done.
Lever Three: The ROI Test Is the One Nobody Volunteers
The most useful experiment Szajna describes is the one that would scare the budget line into existence. Booking.com, for a small share of users across all 45 languages, turned the localised content off for several weeks. Then it compared. The impact, as he puts it, was “really significant,” and his summary line is the one every CFO deserves to hear once: “can’t read, won’t buy.”
Few companies will run that test, because the result is predictable and the cost of running it is real revenue foregone. The point is not that you must repeat it. The point is that somewhere in the business, somebody is treating localisation as a cost centre whose return is unknown, and the only honest answer to “what does it return” is a holdout group that no one wants to authorise. In the absence of the holdout, treat the budget as a cost of being in the market at all, and stop asking the localisation team to justify it in CPM.
Lever Four: The One That Does Not Work Yet Is Full Autonomy
Every Format D piece should name the lever that does not pay off. For multilingual content, in October 2026, that lever is end-to-end autonomous localisation, the one some vendors sell as if it had already arrived. It has not. Booking.com’s own setup, which is further along than almost any brand we have seen, still routes meaningful content through human review and still ties the loop back by hand when the model starts drifting. If a vendor pitch to you implies that an enterprise can run its global content without a human loop in the middle, the pitch is ahead of the practice at the one place that most publicly runs it at scale.
The honest buy today is a layered pipeline, machine translation for the long tail, quality estimation deciding the escalation, human editors in the loop on the content that moves the needle, and a governance layer that remembers what you decided to call things in each market. That is not glamorous and it is why nobody buys it off a slide.
What We Would Build Inside a Real WordPress or WooCommerce Estate
This is the half Econsultancy stops at, and it is where a buyer has to make choices. The build section below is what we would stand up for a mid-market brand that already runs in two languages and is adding a third or a fourth. Numbers are rough shapes rather than quotes, and they are the ones we have hit on real work.
One: multisite, not many sites. On WordPress, run the markets as a multisite with a shared user table, a shared taxonomy where it genuinely is shared, and distinct options per site where it is not. Content pairing between languages is a plugin layer, not a convention: one pair, one database row, one editorial banner that both sides read. We run this on our own two properties and it costs us roughly a sprint to set up and almost nothing to maintain. On WooCommerce, keep product IDs stable across markets and let the catalogue be the single source of truth for SKUs and prices; translate the strings that face the customer, not the identifiers.
Two: strings in fields, not in body copy. Model the content so that the parts the editor rewrites per market are explicit fields with their own version history. A free-text blob is the enemy, because it is where every drift problem lives. Budget roughly a week of information architecture per content type, more for product data. The payoff is linear: every language you add afterwards is noticeably cheaper than the one before.
Three: a quality-estimation gate before publishing. Score the machine output on confidence, send everything below a threshold to a human reviewer, and store the score alongside the string. Set the threshold deliberately high at launch and relax it as the model learns the house style. Three to six weeks of instrumentation gets you a working loop; two quarters of running it tells you whether the threshold is in the right place.
Four: a glossary and a tone register the model actually reads. This is the piece that most teams skip because it is unglamorous. Terminology is the thing that fragments first. If “subscription” and “membership” refer to the same product in English but the Spanish team translates them differently each time, you are paying for the same confusion twice. One owned glossary per market, pushed into the translation pipeline as a constraint, kept honest by a monthly review cycle. Half a day a month, consistently, is worth more than a quarterly audit.
Five: analytics that know a language exists. GA4 by default will tell you a user visited; it will not tell you that the Spanish-speaking user on a German URL bounced because the string on the hero was in the wrong language. Instrument the language variant as a dimension, so a drop in conversion in one market reads back as a locale problem rather than a creative problem.
What Is Still Unsolved, Honestly
Even with everything above in place, two problems stay open. One is tone across markets when the brand voice is itself contested: a line that reads warm in English can read evasive in German if the register is not calibrated, and no model fixes that for you. The other is attribution across machine readers. When an AI assistant quotes your Spanish page as the answer to a Spanish query, the citation shows up as traffic from the assistant, not as a Spanish-market signal, and the usual market dashboards do not see the shift coming. Both are solvable, and neither is a plugin.
If an organisation in your position asked me the honest question, I would answer it like this. Start by picking one market where the content infrastructure is weakest and stand up the governance layer there first, before adding the next language. Resist the temptation to buy a tool before you have decided who owns the glossary. And treat multilingual content as what Szajna’s team already treats it as: an infrastructure line, with its own budget, its own metrics, and a holdout you refuse to run because the result is already obvious. If you want help designing that layer against a real WordPress or WooCommerce estate, that is work we do, and we are happy to walk through it on a call.
Last modified: October 26, 2026
