Continuous localization, without the wait: how one enterprise team stopped waiting for the slowest language

A long-standing XTM customer just moved off a legacy Drupal connector and onto a rebuilt one on XTM Connect, the integration layer of the XTM platform. They called the result "game-changing." Here's the problem they had, what we changed, and what continuous localization out of a CMS should really look like for any team.

The problem: continuous localization that wasn't continuous

Plenty of enterprises will tell you they run continuous localization. Far fewer actually do.

This customer, an enterprise we'd worked with for over four years, produces a high volume of customer-facing content across two business units: one for support pages, one for marketing. Accuracy matters enormously, so much of it goes through human review and subject-matter checks before it can go live.

The connector they'd relied on had served them well for years. But as their content volumes and speed expectations grew, two limits of its original design began to show.

Translations came back only when the whole project was done

The connector returned translations once the entire project had completed, every language and every file together. If three languages were machine-translated and ready within a day but the fourth needed four days of human review, the first three waited on the fourth. For a team focused on speed to market, that batched rhythm had become the bottleneck.

Very large jobs were hard to push through

Because the original plugin did the heavy lifting itself, a large machine translation submission could strain the setup. The bigger the content, the greater the chance it didn't complete in a single pass.

The trigger: a tense quarterly account review

The pressure came to a head in a quarterly account review that was, to put it plainly, tense. The customer had been told for some time that moving to the new platform would be better, but they hadn't yet seen the proof. On top of that, the new connector didn't initially handle their content the way the old one did.

That's a familiar moment for anyone who has run a CMS migration. The new system is technically superior, but it doesn't yet speak the customer's language. The honest response isn't to tell the customer their setup is the problem. It's to close the gap.

What we changed: rebuilding the connector on XTM Connect

XTM Connect is the door to a customer's translation needs, and that door is built from composable workflows. Instead of one hard-coded integration, a connector on XTM Connect is assembled from discrete, reusable steps that capture content from the source system, route it through translation, and return it as the work completes. When an off-the-shelf path doesn't fit, our team composes one that does.

That's exactly what happened here. Our solutions and engineering team went hands-on, rebuilding the integration around what the customer actually needed and composing the workflow from the platform's granular building blocks to deliver capabilities beyond what the original connector was built for.

Per-language delivery, so fast languages go live while slow ones finish review

This is the headline. Content now flows back the instant each language is complete, rather than waiting for the whole project. The fast languages go live while the slow ones finish review, so the review process on one language no longer holds the rest hostage.

Background submission that scales with the size of the job

With XTM Connect handling the pull-and-push in the background, the turnaround after a user hits "submit" stays consistent no matter how large the job is or how many resources it contains. Large machine-translation submissions that once strained the setup now go through reliably.

Native XML support, so the customer kept their existing format

The platform is built around JSON, but this customer's established setup was XML. Rather than force them to rework their file types and templates, we built native XML support into the connector itself, converting cleanly so their existing process kept working. It removed reconstruction work on their side, and it turned out to be a better pattern that now benefits other connectors too.

Built on the latest version of Drupal for what comes next

The rebuilt connector runs on the latest version of Drupal, extending support beyond the versions the earlier connector reached, so the customer is on current, forward-compatible footing.

The result: from the pace of the slowest language to per-language delivery

The clearest proof isn't a chart. It's what the customer said.

After the rebuild, they described the outcome as "game-changing," a phrase that traveled all the way up to our leadership team as a marker of what good looks like.

The team delivered the rebuild ahead of the ten-day timeline committed during that difficult review, under real pressure, and the relationship that was at risk is now one of our strongest references.

The deeper result is structural. This customer's entire content chain (translate, review, publish, go to market) used to move at the pace of its slowest language. It no longer does.

What this means for any team localizing content from a CMS

If you localize content out of a CMS, three lessons travel beyond this one customer. They're a useful test for any localization strategy built on a translation management system and a CMS connector.

1. Continuous has to mean per-language. If your setup makes you wait for an entire project to complete before anything is usable, you don't have continuous localization. You have batch localization with a friendlier name. The single biggest lever on time to market is decoupling delivery from the slowest item in the batch.
2. A migration shouldn't cost you your workflow. The right integration adapts to the content formats and processes you already run. Being asked to rebuild your own pipeline to suit a vendor's architecture is a red flag, not a requirement.
3. The platform should absorb the load, not your plugin. Submission reliability is invisible until it fails. Pushing the orchestration off the CMS plugin and into a platform layer is what keeps large jobs from timing out.

XTM Connect is the orchestration layer of XTM that makes all three real: composable workflows, set up and tailored by our professional services team, that route your content to the right place and bring it back as fast as the work allows.

Talk to our team about how XTM can give your content stack continuous, reliable website localization and per-language delivery across every CMS.

FAQs

What is continuous localization?

Continuous localization is an approach where translated content is delivered as it becomes ready, rather than in one large batch at the end of a project. It lets teams publish finished languages immediately instead of waiting for the slowest one.

How is continuous localization different from traditional localization?

Traditional localization is a batch handoff. You freeze a release, export the files, send them for translation, wait, then import everything back at once. Continuous localization removes the freeze. Content goes for translation as soon as it's ready, and each language returns the moment it's done, not when the whole project finishes.

What are the main benefits of continuous localization?

The main benefits are faster time to market, less rework, and language versions that stay in sync with your source content. Because translation runs in parallel with development and review rather than after it, you can publish finished languages right away and avoid the delays and last-minute fixes that batch workflows create.

Can XTM Connect deliver translations one language at a time?

Yes. The connector returns content on a per-language basis. Each language is delivered the moment its translation and review are complete, rather than waiting for the entire project to finish.

Does XTM Connect work with Drupal, including the latest version?

Yes. The rebuilt connector supports the latest version of Drupal, extending beyond the versions the earlier connector covered.

Does XTM Connect support both XML and JSON content?

Yes. The platform works natively with JSON and can handle XML, so customers don't have to change their existing file types or templates to migrate.

Will large translation jobs time out?

No. XTM Connect handles submission in the background, so the turnaround after submitting stays consistent no matter how large the job is.

Is XTM Connect self-serve?

No. XTM Connect is set up and configured by our professional services team, a concierge approach. We have out-of-the-box templates for common scenarios that give a proven starting point, and we customize wherever a customer needs something different. Where no template fits, we compose a workflow from scratch. The setup is always ours to run. Templates speed it up, but customers don't configure it themselves.