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.
Key Takeaways
- Adding AI translation does not reduce the work. It moves it from translating to reviewing, and the reviewer is the scarcer person.
- A translator can produce and approve. A model can only produce, so every AI language creates a review queue.
- Three workflows: TMGMT for suppliers and audit trails, AI Translate for small teams clearing backlog, AI TMGMT to put AI inside TMGMT's review.
- More languages than approvers means AI makes the problem worse first. Fix review coverage before automating what feeds it.
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.
A Drupal translation workflow is the process around translation itself: tracking what needs translating, assigning it, reviewing it, and publishing it. Drupal supports three workflows. Translation Management Tool handles job-based human or vendor translation, AI Translate generates machine translations from the Translate tab, and AI TMGMT puts AI output inside TMGMT's review process.
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:
- Content is added to the CMS in the source language.
- A translation job is requested, carrying the target language, the content type, and the word count.
- The job is reviewed before it goes anywhere.
- A translation provider is chosen.
- The translations come back.
- Results are reviewed and published.
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.
| Criterion | Translation Management Tool | AI Translate | AI TMGMT |
|---|---|---|---|
| Who translates | In-house translators, agencies, or a machine translation provider | A configured AI provider | An AI provider inside a TMGMT job |
| Review | Job-based, side by side against the source | Optional: keep source status, or create every translation as a draft | Full TMGMT review process |
| Coordination | Job queue, provider assignment, per-item status | None, a per-node action | Job queue, with AI in the provider slot |
| Release status | Stable | Stable | Beta |
| Fits when | Multiple languages, external suppliers, an audit trail matters | A small team clearing a backlog on non-critical content | TMGMT already runs and AI should sit inside it |
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.
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.
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.
- How many languages do you publish in?
- How many people can approve a translation in each of those languages?
- 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.
Check out the Free AI Readiness Scorecard
If you would rather work the routing decision through against your own content, languages, and team, talk to us about a multilingual workflow review.
FAQs
Yes. Translation Management Tool (TMGMT) released version 8.x-1.18 in January 2026, supporting Drupal 10.3 and Drupal 11, and more than 12,000 sites report using it. The module has been maintained since 2012 and remains the reference implementation for job-based translation in Drupal, covering provider assignment, side-by-side review, and per-item status tracking.
Drupal core handles translation on its own. The Language, Locale, Content Translation, and Configuration Translation modules let you publish in multiple languages with no contributed module at all. What core does not provide is the workflow around it: a job queue, provider assignment, and a dashboard showing what is translated, outdated, or waiting for review. That is the layer Translation Management Tool adds.
Drupal translates considerably more than page body content. Menu links, taxonomy terms, field labels, metadata, and interface strings are all translatable, through Content Translation for entities and Locale for interface strings. Translation Management Tool exposes these as translation sources alongside nodes, so interface elements and taxonomy can be assigned and reviewed inside the same job as the page they sit on.
Translation Management Tool marks an existing translation as outdated when its source content is modified, and shows that status on the translation dashboard alongside translated, not translated, and needs review. Drupal core carries its own outdated flag on content translations. This is the control most teams are trying to reproduce by hand in a tracking spreadsheet.
Translation Management Tool connects Drupal to agencies two ways. Provider modules integrate directly with services such as GlobalLink and Acclaro, submitting jobs and pulling completed translations back. For suppliers who work in their own tooling, the module exports and imports XLIFF and HTML, the standard exchange formats, so an agency can work outside Drupal without breaking the job record.