AI Translation in Drupal: Who Approves the German Version?

By Greg Nowak. Last updated 2026-09-12.

Before generating a German version of your service page, decide who can approve it. The German reviewer checks the language. The service owner checks what the business is promising. The publishing editor decides whether the page is ready to go live. One person can cover more than one role, provided everyone knows which decisions they own.

Drupal’s AI Translate project lists version 1.4.1 as released on September 2, 2026. It supports creating translations as drafts and configuring prompts and models for each target language. That gives a business room to test translation with a proper review step before anything reaches customers.

Take a Danish page offering an ongoing maintenance service. It has a service description, exclusions, a response commitment and a contact button. You want to publish it in German. This is a worked example of how the process could run, not a client case study.

Start with the Danish offer. The service owner needs to settle any ambiguous promises and confirm that the same terms apply to German customers. If delivery arrangements differ, record the German variation before translation begins. Otherwise, the reviewer is left guessing whether a condition needs better wording or whether the business intends to offer something different.

There is also a source revision detail to check. Drupal’s Content Moderation overview says a new translation takes its default text from the currently published source, rather than the latest revision. Each node translation is moderated separately, too. Publishing a Danish update does not publish the German version.

Record which source revision the pilot will translate, then verify what the configured AI integration actually receives. Test a Danish page that has both a published version and an unpublished edit. The German reviewer should be able to tell exactly which version their draft represents.

Set AI Translate to create new translations as drafts, and agree what belongs in the translation batch. The project documentation describes extraction of summaries, link titles and image alt text as well as body text. It can also follow referenced content to a configured depth. If the page uses a shared service component, make an explicit decision about including it before running the translation.

A short terminology sheet will give the German reviewer something concrete to work from: approved service names, terms that should stay in Danish, preferred German equivalents and the chosen form of address. Ask the reviewer to separate language corrections from changes to the offer. More persuasive wording still needs the service owner’s approval if it makes a broader promise.

Provider selection needs a test through the actual Drupal integration. The DeepL translation API documents controls for context, glossary selection, formality and HTML tag handling. Context can inform the translation without being translated itself. A glossary requires an explicit source language and a matching language pair; formality support depends on the target language. Those are API capabilities. You still need to establish which controls the Drupal connector exposes.

For the pilot, try a short, ambiguous button label with relevant context, a paragraph using approved terminology and formatted content containing links. Check which settings reach the provider. Let the reviewer assess meaning and tone, then inspect the rendered page. If a control you need is missing from the integration, include that work in the delivery scope before choosing the provider.

Put these responsibilities into Drupal permissions and a short handover procedure. Drupal’s moderation overview demonstrates how authors who create drafts can be separated from editors who publish them. Test the setup using ordinary editorial accounts: the reviewer needs access to the draft, corrections need a route back for review, and publishing must be restricted to the intended role. Staff should be able to explain the process without reaching for a workflow diagram.

Before publication, read the complete German page as a customer would. Check the heading, service conditions, button wording and destination, along with any Danish text that remains. Have the service owner approve the rendered offer. Agree that substantive changes made after approval go back to the relevant reviewer.

The publication check also needs to cover multilingual SEO. Google’s guidance on localized versions describes HTML annotations, HTTP headers and XML sitemaps as ways to identify language variants. With HTML annotations, each page should reference itself and the other variants through fully qualified URLs, and the links must be reciprocal. Sitemap annotations likewise need to list every variant, including the page itself, for each URL entry.

Choose the method the site can maintain reliably, then inspect its output when the German page goes live. The Danish and German URLs should point to the corresponding service pages. Be deliberate about targeting: Google distinguishes general German content, labelled de, from content intended for a particular region. Give someone responsibility for checking this as part of publication.

The next Danish edit will show whether the process holds up. Suppose the service owner changes the response commitment in our example. Approval of that source change should trigger an assessment of the German page: what changed, who needs to review it, and can the existing German offer stay public while its replacement is prepared?

Make translation refresh tracking a separate deliverable. Independent moderation does not, by itself, establish the notification process you need. An assigned refresh queue and recorded source revisions are enough to begin a pilot. If automated flagging is included, demonstrate it with a real source edit during acceptance testing. Previously approved German wording should remain available for comparison.

Greg could help configure Drupal translation and moderation, select and test an AI provider, agree terminology rules with the business and implement a way to flag translations that need attention. A sensible pilot would cover a few representative pages, including one with shared content, followed by a source update exercise. The handover would include named approvers, tested permissions, reviewer instructions and a record of the review effort. That gives you a basis for deciding how much of the site to translate next, and who will keep it current.

Related on GrN.dk

• An AI Voice Agent Needs More Than a Phone Number and a Realtime Model
• Before You Buy a GPU: Test Your Team’s Local AI Workload
• Cloudflare Service Keys: Audit Old Automation Before September 30

Need help with this kind of work?

Discuss a Drupal translation pilot Get in touch with Greg.

Sources

• AI Translate — Drupal project
• Content Moderation module overview
• Translate text — DeepL API
• Tell Google about localized versions of your page