Simplify Translation Workflow Management for Drupal Sites

Drupal supports three translation workflows, and the right one depends on how many people can approve a translation, not on how many words need translating. Review capacity is the constraint that decides it, and it is the one most teams count last.

The backlog usually arrives before the decision does. A team publishes in English, adds two languages, and within a few quarters there is a spreadsheet tracking what has been translated, what changed since, and who owes what to whom. Nobody chose that system. It accumulated.

What Is a Drupal Translation Workflow?

A Drupal translation workflow is everything around the translation itself: deciding what needs translating, assigning it, reviewing what comes back, publishing it, and catching the source content when it changes again. The translation is one step. The workflow is the other five.

For a single page, the sequence is short:

1. Content is added to the CMS in the source language.
2. A translation job is requested, carrying the target language, the content type, and the word count.
3. The job is reviewed before it goes anywhere.
4. A translation provider is chosen.
5. The translations come back.
6. Results are reviewed and published.

Image

Five of those six steps run the same way every time. Step four is the only point where the route changes, and every route returns to the same review before anything publishes.

Run that across news, landing pages, documentation, and campaign assets, multiply it by every language, and repeat it for every source edit. The coordination overhead is what breaks first, not the translation.

What Changed Since Translation Meant Sending Files to a Vendor?

The Drupal AI ecosystem now sits inside the translation workflow rather than beside it, and it moved recently enough that most implementation guidance still describes the old shape.

Three things are worth knowing before choosing a workflow:

• The Translation Management Tool (TMGMT) is still active and still the reference implementation for job-based translation. Its January 2026 release supports current Drupal, and more than 12,000 sites report using it.
• AI Translate was part of the Drupal AI module until version 1.4.0 removed it. AI Translate is now its own contributed project, installed separately, adding one-click translation to the Translate tab through any configured AI provider.
• AI TMGMT connects the two, acting as an AI translator plugin inside TMGMT so machine output flows through the same job and review process a human vendor would use. AI TMGMT has no stable release yet.

The underlying Drupal AI module connects to 48 and counting providers, including self-hosted options, and reports use on more than 16,000 sites. The capability is not scarce. The decision about where it sits in the publishing pipeline is.

Which Translation Workflow Should You Run in Drupal?

Choose Translation Management Tool when external suppliers and an audit trail matter, AI Translate when a small team is clearing non-critical backlog, and AI TMGMT when TMGMT is already running and the goal is to add AI without rebuilding review. The three workflows differ less in translation quality than in where review happens and how much process comes with them.

The table below compares the three Drupal translation workflows on who does the translating, how review works, the coordination each carries, and how mature the release is.

Translation Management Tool also exports and imports XLIFF and HTML, which matters when a supplier works in their own tooling. Its dashboard shows per-item translation status and flags existing translations as outdated when the source changes, which is the single most useful thing it does and the thing spreadsheets are worst at.

When Should You Not Add a Translation Workflow Tool?

There are three situations where a Drupal translation workflow tool costs more than it returns, including work we would otherwise be glad to do.

1. You publish in two languages and change a handful of pages a month

A university department site running English and Spanish, or a small foundation running English and Arabic, is fully served by Drupal core's content translation plus a shared document. Job management at that volume is process you will maintain and never use.

2. Your content carries legal or safety consequences

If a mistranslation changes someone's asylum claim, medical decision, or benefits eligibility, do not put AI in the workflow as a cost measure. Use human translators and use the workflow only for tracking and evidence. We cover this properly in AI translation governance for multilingual humanitarian content, and it is the one case where the cheaper route is the wrong one.

3. Your bottleneck is translator capacity, not coordination

If work sits because there is nobody to do it, better job management makes the queue more visible without making it shorter. Buy translation hours before buying tooling.

Where We Land: Review Capacity Is the Real Constraint

Our view: adding AI translation to a Drupal workflow does not reduce the total work. It moves the work from translating to reviewing, and the reviewer is the scarcer person.

A translator who works into Arabic can both produce and approve. A model can only produce. Every language added through AI creates a review queue that needs someone fluent enough to catch a plausible-sounding error, and that person is harder to hire than a translator and usually already holds another job inside the organization.

This is why teams that switch to AI translation often report the backlog moving rather than shrinking. The pages get generated in a week, then sit in review for a month. In the multilingual platforms we build for international NGOs and public-sector teams, the constraint that actually binds is how many people can sign off in each language, not how many words can be produced.

That reframes the setup question. You are not configuring a translation pipeline. You are configuring a review pipeline, and translation is the part that feeds it.

As a Drupal Diamond Certified Partner and top-20 contributor to the project, we have built multilingual platforms for organizations publishing in multiple languages.

How Do You Set Up Multilingual Drupal Without Assembling It Yourself?

Multilingual is core Drupal rather than a bolt-on, which is why this is a configuration exercise and not a build. The pieces are language management, interface translation through Locale, configuration translation, and content translation, plus permissions deciding who can approve what in which language.

Assembling those pieces and getting the permission model right is the part that takes time. Varbase ships that assembly as a recipe, Varbase Internationalization Base, applying language, locale, configuration translation, and content translation together with role-based translation permissions and language workflows driven by the Event-Condition-Action module. Because it is a recipe rather than an install profile step, it applies to a site that already exists, and because it is all core modules underneath, it stays aligned with Drupal's roadmap, and your configuration stays yours to change.

Image

If AI sits anywhere in the workflow, the editorial rules it works under are worth configuring in the same pass. Drupal's Context Control Center holds site-specific context such as brand voice, editorial standards, and governance guidance, and the Varbase AI Context recipe installs it with starter rules already populated. This does not replace glossary enforcement on high-stakes terminology, which belongs at the translation provider. It reduces the volume of ordinary tone and consistency corrections reviewers would otherwise make by hand, which is the load that determines throughput.

As a Gold Sponsor of the Drupal AI Initiative, we work on this layer of the project directly.

Image

The current internationalization recipe targets Drupal 11.4. Teams still on Drupal 10 have that upgrade on the calendar anyway before its December 9, 2026 end of life, which makes it the natural moment to fix the translation workflow rather than port the spreadsheet forward.

What Should You Decide First?

Count three numbers before choosing a Drupal translation workflow. All three are facts you already know about your own organization.

1. How many languages do you publish in?
2. How many people can approve a translation in each of those languages?
3. How many content items change in a typical month?

Two languages, a named approver for each, and a modest change rate means core content translation is enough and the rest is overhead. This is most departmental and single-campus sites.

Several languages and external suppliers means you need TMGMT's job structure whether or not AI is involved, because the audit trail and the supplier handoff are the actual requirements. This is most government portals and multi-country NGOs.

More languages than approvers means adding AI translation will make the problem worse before it makes it better. Fix review coverage first, then automate what feeds it.

At Vardot we build both fully human and AI-assisted translation workflows, and we recommend against AI in the pipeline often enough that it is worth saying plainly: the right answer depends on what your content does to the reader, not on which option is newer.

Where to Start

Before committing to a workflow, it helps to know where your platform stands. Our free AI-Readiness Scorecard runs 20 checks across content, discoverability, connectivity, governance, and platform health, and returns a prioritized fix list.