Automatic translation of Drupal pages with AI

A multilingual backlog has a special smell. You publish in English on Monday, you promise German “this week,” and by Friday you’re staring at 47 updated pages and no clean way to answer, “So… what’s the real status?”

I’ve watched teams try to solve this by throwing more process at it: spreadsheets, translation tickets, weekly syncs. It works until someone edits the hero paragraph on 200 pages. Then you’re back to guessing.

What finally worked for us was treating translation like a production system: TMGMT to track and govern, a small custom module to trigger jobs automatically via cron, and an AI translator that runs in the background and can handle large fields by chunking.

This article is the manager’s view: outcomes, risks, and what to ask your team so you don’t end up with a quiet mess.

First, what “automatic translation” really means (in Drupal terms)

If you’re picturing a magic button that instantly converts an entire site into five languages, forget it. The reliable version is slower and more boring:

• New or updated content gets detected.
• A translation job gets created and tracked.
• Work runs in the background on a schedule.
• Results land in a review step (or auto-accept if you choose that risk).
• The translated content publishes when it meets your rules.

That “job” concept is why TMGMT is a good backbone. It’s built to manage translation as work with states, tracking, sources, and translator plugins.

So you’re not buying “AI translation.” You’re buying a workflow you can measure.

Why cron and queues are not an implementation detail

Managers usually hear “cron” and think “scheduled task, fine.” But Drupal’s automated cron runs on a schedule that can slip in low-traffic conditions, and it can add load to user requests in default setups.

Translation jobs are heavy. They involve external API calls, retries, and sometimes long text. So the reliable pattern is: queue the work, then let cron process it in controlled slices.

Here’s the managerial translation of that:

• Your editors don’t wait on translation.
• Your site doesn’t spike latency because somebody published a long page.
• You can tune throughput by allocating more or less background time.
• Failures get isolated to small units of work instead of taking down the whole run.

If your team hasn’t planned for this, you’re not getting automation. You’re getting a new failure mode.

The AI piece: what you get, and what you don’t

For the AI translator, we use a TMGMT-compatible approach so translation is still managed through jobs and workflow, not one-off scripts.

From a project perspective, provider choice matters more than people expect. It gives you options later:

• You can switch models when cost changes.
• You can route sensitive content differently if policy demands it.
• You can adjust prompt style per language to reduce tone drift.
• You can treat translation settings as configuration rather than hard-coded logic.

But don’t oversell it internally. AI translation is fast, and it can be surprisingly good, yet it still needs governance. Review workflows exist for a reason.

The big operational risk: long Body fields

This is the part PMs usually hear about only after the first incident.

Large Body fields (documentation, policy pages, pages with lots of embedded markup) are where naïve AI translation breaks. Sometimes it fails loudly. More often it fails quietly: partial output, inconsistent formatting, or broken HTML that slips through until someone spots it on the live site.

Our fix is not “better prompting.” It’s engineering:

• Translate in the background, not in the user request path.
• Split large Body values into chunks that stay within practical limits.
• Reassemble in the original order.
• Retry at the chunk level so one failure doesn’t block the whole page.

Chunking does introduce a trade-off: terminology can drift across chunks. You mitigate that with a light glossary or style rules per language.

What the custom module does (and why you want it)

TMGMT is the workflow engine, but something still needs to decide when a translation job gets created. That’s what the custom module does:

• Detect content changes.
• Decide which languages are required for that content type.
• Create or update translation jobs automatically.
• Push work into a queue so cron processes it later.

This gives you a predictable operational rhythm. It also makes translation part of publishing hygiene instead of a separate project stream.

In larger programs, you’ll want explicit rules: which content types are auto-translated, which require review, and what happens on minor edits versus major rewrites. Without rules, automation turns into surprise behavior.

What to measure (so you can tell if it’s working)

If you don’t define success, the team will define it for you, and you may not like the definition. Here are metrics that actually map to outcomes:

• Translation latency: median time from content publish/update to translation available for review.
• Backlog size: number of items sitting in “needs translation” or “needs review.”
• Rework rate: how often translations get edited by humans after AI output.
• Failure rate: retries, stuck jobs, or formatting issues that require intervention.

Use job tracking as the reporting surface instead of inventing a parallel dashboard.

Governance: where projects succeed or quietly embarrass you

The fastest way to lose trust in automatic translation is to publish something legally risky or brand-damaging. Automation raises the blast radius.

You’ll need policy decisions, not just modules:

• Which content types can auto-publish AI translations?
• Which ones must go through review?
• Who owns glossary terms for product names, legal phrases, regulated language?
• What’s your rollback plan if a model update changes tone?

A hybrid model is often the sane compromise: AI handles volume, humans handle risk.

A rollout plan that doesn’t blow up your editorial team

If you do this all at once, editors will feel like the ground moved. There’s a better path.

Start with one content type that has clear structure and lower risk. News posts, event pages, FAQs. Get the pipeline stable. Then expand to the messy stuff: long-form pages, documentation, marketing pages with heavy formatting.

Also, decide early how you run cron. Reliability and throughput affect delivery dates in a way teams underestimate. This is not a technical footnote.

The question I’d ask before green-lighting this

When the system is working, translation becomes background noise. That’s the goal.

But here’s the uncomfortable question: are you optimizing for speed, or for confidence? Because the answer decides whether you auto-publish, how strict review is, what languages you roll out first, and how much you invest in terminology control.

If you tell me what kind of site you’re running (marketing-heavy, documentation-heavy, or mixed) and how many languages are in scope, I can suggest a rollout approach that matches the risk profile instead of pretending one workflow fits everyone.

Looking for the best Drupal development company on the market? You’ve just found it.

We’re the largest Drupal-focused digital agency built to deliver fast, secure, scalable platforms—without compromise. From new builds and redesigns to migrations and long-term support, our Drupal experts ship enterprise-grade results with boutique-level attention.

Book a call today and let’s turn your Drupal roadmap into a high-performing reality.