Continuous Localisation Is Release Infrastructure

A customer in Spain opens checkout. The banner says they can get 20% off their next order. Great. They enter the code.

“Error: you cannot use this code.”

Oh. Today’s not going to be our day, is it?

Turns out the offer is now for first orders only. The English checkout was updated to say so. The translated checkout… less so.

So, who can we point our proverbial pitchfork at? Marketing changed the promo. Engineering updated the validation. The localisation team got an email to update the translations. Support only found out about all of this when customers started accusing them of false advertising.

As is often the case, this isn’t any one team’s fault. It is a fault of the process. Localisation is an afterthought, not part of the release pipeline.

Continuous localisation is a release workflow in which copy changes are detected, translated, reviewed, and delivered alongside product changes. Translation stops being a separate batch of work and becomes part of continuous delivery.

The Slow Path to a Fix

Let’s follow that bug through the company, as it gets fixed.

Support sees the first ticket. They can apologise, but they cannot change checkout copy.

The localisation team can fix the translated sentence, but they don’t have access to prod deployment.

Engineering can update the app, but they don’t know what the translations should be, or whether the English or Spanish text is to be believed.

Marketing owns the offer. They know for sure what the deal should be, but, like support, they can’t actually push it anywhere themselves.

So guess what that means? Meetings!

When this happens once, it’s annoying. When it happens regularly… then i18n becomes the bogeyman. Suddenly, people decide that not all of the website needs translating. “This page? Hmm, that’s tricky… I’m sure our users can just really quickly become fluent in English.”

Users do not care which team owns the sentence. They just want to buy their shoes. 76% of online shoppers prefer it in their own language, and 40% will just quit if it’s not .

So “can’t we just render the promo banner in English” is only a valid suggestion if you are lucky enough to work for a company where you have too much money already.

Translation Delay Is Release Delay

Many teams deploy code every day, but only translate copy once a week.

That gap sounds harmless until the copy controls a launch, a price, a checkout rule, a legal notice, or a support promise.

A spreadsheet can become a hidden deployment dependency. It does not look like infrastructure. It has no status page. It does not wake anyone up at 3 am. But it can still hold a release hostage.

If a product change is live in English on Monday and reliable in German on Friday, the user-facing lead time was not Monday. It was Friday.

The code shipped. The experience did not.

Lokalise surveyed 500 global business leaders in February 2026. In that survey, 32% named speed to market as a major global growth challenge, and 36% said they had delayed or pulled back from entering a market because of localisation challenges.

Work waits between systems. Context leaks between teams. Small copy changes get batched because moving them through the process hurts.

Batching feels efficient. It is often a tax receipt for a slow system.

How to Build a Continuous Localisation Pipeline

A continuous localisation pipeline should make translation part of the normal path to production:

1. Detect copy changes. New and updated product copy enters the localisation workflow as soon as it changes, without waiting for somebody to export a file.
2. Translate with context. AI and human translators get the surrounding page, product state, terminology, and brand guidance needed to understand what the words actually mean.
3. Apply the right review policy. Low-risk changes can move automatically, while sensitive or uncertain translations notify a human reviewer without blocking unrelated work.
4. Validate the rendered product. Automated QA checks the real page for mistranslations, missing content, and layout problems instead of approving strings in isolation.
5. Deliver continuously. Approved translations reach users alongside the product change, or immediately afterwards, without waiting for the next translation batch or application release.

This is the workflow 18ways is built for. It translates copy at runtime, preserves server-rendered pages and locale-aware URLs, attaches real product context, and uses AI agents to review translated experiences continuously. If you are starting with Next.js, follow the guide to adding multiple languages without hurting SEO, then use the 18ways Next.js quickstart to put the pipeline into practice.

Fast Localisation Changes Product Culture

DORA frames delivery performance around throughput and stability. Two of its useful measures are deployment frequency and change lead time. In plain English: how often can you ship, and how long does a change take to reach users?

Localisation is not often considered when discussing DORA, but a release is not complete until it is available to its users.

When localising a page or experience means having another meeting with 3 different departments, people avoid it. They feel bad for their users, but repetition turns into resignation. Everyone gets used to the idea that the Spanish site is just slightly worse. Customer complaints get responded to with a shrug. The site will work for them in 2 weeks, why can’t they just wait until then?

Now let’s imagine the promo change again, in a world where localisation is a first-class citizen.

Marketing changes “returning customers” to “first orders only”. AI translations kick off immediately to ensure that all locales have that update. Anonymised snapshots are sent alongside the text, giving the AI translator enough context to validate the translation in place. Humans can add manual translations as soon as they are able.

This changes more than just the speed of the translation: it changes how people behave.

If the business logic doesn’t match the marketing text, engineering can fix the logic immediately. If marketing needs to tweak the copy to make it clearer, they can fix the source text immediately. If a translation isn’t quite on brand, the localisation team can update the translations. Immediately.

Developer experience research often talks about three things: feedback loops, cognitive load, and flow state.

• A feedback loop is how quickly you learn whether your change worked.
• Cognitive load is how much stuff you have to keep in your head.
• Flow state is the rare, precious stretch where you are in the zone getting things done, not prepping for a meeting with Brian.

Slow localisation hurts all three.

Make Translation Speed a Business Advantage

For a modern product, localisation is release infrastructure. It dictates when markets receive the real product (and again, releasing to “most” of your users does not count as done).

Martin Fowler has a useful phrase: frequency reduces difficulty. Painful work becomes less daunting when teams do it in smaller, more regular loops. That is true for deployments. It is true for tests. It is true for localisation too.

When localisation and translations occur in large batches, every update carries more risk. Auditing and QA become harder. When it moves with the product, every update is smaller, clearer, and easier to verify.

AI translation makes faster localisation possible. AI agents make faster localisation safer. Live snapshots make the evidence visible enough for teams to trust.

That combination is where the industry is heading. The future is not developers filing more careful translation tickets. It is not more columns in a spreadsheet named final_FINAL_really_final.xlsx.

It is also why writing and maintaining translation keys should not be the centre of modern i18n. The release pipeline should carry the context and coordination burden, not every developer shipping a sentence.

If your localisation solution is not automated and self-serve, you’re living in the past. In the past with a lot more meetings.

Good localisation is not a drag on release speed; it is a natural part of how good products ship.

See how 18ways makes continuous localisation part of your product infrastructure.