Tutorial

Every Drupal team building a multilingual site eventually discovers the same thing: the machine translation itself is the easy part. In 2026, any capable AI model produces a fluent German or Romanian draft of an English page in seconds. What separates sites that win international search traffic from sites that quietly accumulate stale or half-translated pages is not the model — it is the workflow around it: who triggers a translation, who reviews it, what happens when the source changes, and how search engines are told about the result.

We covered the capability side in AI-powered content translation in Drupal — what the AI module ecosystem can do. This article is the operational sequel: a Drupal translation workflow you can run in production, stage by stage, with the building blocks for each. It is the same workflow we use to run softescu.com in English, Romanian, and German.

Why a "translate" button is not a workflow

Wiring an AI provider into Drupal and exposing a translate button on every node solves the wrong problem. Four failure modes show up within weeks:

• Silent drift — the English source gets updated, the translations do not, and nobody notices because nothing tracks the relationship between source revisions and translated revisions.
• Terminology inconsistency — the same product term is translated three different ways across three pages, because each translation ran in isolation with no shared glossary.
• Unreviewed output in production — AI translations are fluent, which makes their occasional errors (negation flips, false friends, wrong legal terms) harder to spot, not easier. On compliance-sensitive pages this is a real liability.
• SEO breakage — pages get translated but hreflang alternates, canonicals, and localized sitemaps do not follow, so search engines index the wrong language version or none at all.

A workflow addresses each failure mode with a stage. There are five.

Stage 1 — Decide what gets translated

Drupal's content translation module works at field level, and that granularity is the point. Before any AI call, walk each content type and mark every field as translatable or shared:

• Translatable: title, body, summary, meta description, image alt text, CTA labels.
• Shared (never translated): machine names, SKUs, code samples, embedded configuration, brand and product names, author fields, dates.

Then write the glossary: the 30–80 terms that must translate the same way everywhere — product names that stay English, industry terms with an established local form, terms your legal team has signed off. The glossary is the single highest-leverage artifact in the whole workflow: it costs an afternoon and prevents the majority of review findings later.

Stage 2 — Generate AI drafts with context, not raw strings

The difference between a mediocre and a strong AI translation is almost entirely the context you send with the request. Field values translated in isolation produce the classic machine-translation feel. Instead, send the model:

• the full page content, so paragraph-level references resolve;
• the glossary, with an explicit instruction that its terms are non-negotiable;
• the audience and register ("B2B decision makers, formal Sie-form" for German; sentence-case conventions for Romanian headlines);
• what to leave untouched — code blocks and configuration stay in English even inside translated pages, because the developers who copy them work in English.

In Drupal terms, the AI module ecosystem with a translation provider supports exactly this pattern — and the result should always land as an unpublished draft revision of the translation, never go straight to published.

Stage 3 — Human review as a moderation state, not a habit

Reviews that rely on goodwill stop happening the first busy week. Make the review a structural gate instead: a content moderation workflow for translations with three states — AI draft → In review → Published — where the transition to Published requires a role that only human reviewers have.

The reviewer's job is narrower than translating: check glossary compliance, legal accuracy on sensitive claims, tone, and that internal links point to the right language version. In practice a reviewed page takes 10–15 minutes instead of the 2–3 hours a human translation would — that is the actual economic win of AI translation, and it only materialises if the review step is fast because Stages 1 and 2 were done properly.

Stage 4 — Publish with the SEO plumbing intact

A translated page that search engines cannot attribute to its language is wasted work. Publication must include:

• hreflang alternates on every language version, each pointing to all sibling versions — and reciprocally;
• per-language canonicals — especially when languages live on different domains (our Romanian pages canonicalise to softescu.ro, not softescu.com; getting this wrong de-indexed our Romanian site for weeks);
• localized sitemaps with per-language URLs and fresh lastmod dates;
• translated meta titles and descriptions that follow each language's own conventions — English titles are title-cased, Romanian and German use sentence case. Copying English casing into other languages reads as machine output to native readers.

Stage 5 — Close the loop with per-language measurement

The workflow's output is measurable, so measure it: impressions and CTR per language folder in Search Console, engagement per language in analytics. This is where translated content stops being a cost centre and starts being an argument. On our own site, the German versions of two technical guides currently convert search impressions at two to five times the CTR of their English originals — the German pages are the best-performing snippets we have. Without per-language measurement we would never have known, and would never have doubled down on German content.

Handling updates: re-translation without drift

When the source changes, Drupal marks translations as outdated — wire that flag into the workflow: re-run the AI draft for the changed fields only, and route the delta through the same review state. Re-translating whole pages on every source edit burns review time and introduces churn in previously approved copy; field-level re-translation keeps the diff reviewable in minutes.

Common pitfalls

• Translating everything — legal archives, old event announcements, and expired job posts do not need three language versions. Translate what has an audience.
• Publishing AI output unreviewed "just this once" — the one page that skips review is reliably the one a native-speaking prospect finds first.
• One-way hreflang — alternates that are not reciprocal are ignored by search engines. Validate reciprocity automatically, not by hand.
• Locking the workflow to one provider — models improve monthly. Keep the provider behind an interface so you can swap without touching the workflow.

What this looks like in practice

We run this workflow on softescu.com itself — every page and article exists in English, Romanian, and German, AI-drafted and human-reviewed, with the hreflang, canonical, and sitemap plumbing automated. The same setup scales down to a five-page corporate site and up to enterprise Drupal platforms with editorial teams in multiple markets.

If you are planning a multilingual Drupal project — or you have one where translations have drifted — our enterprise web development team builds exactly these workflows. Get in touch.