Automatische Übersetzung von Drupal-Seiten mit KI

Ein mehrsprachiger Backlog hat einen ganz eigenen Geruch. Du veröffentlichst am Montag auf Englisch, versprichst Deutsch „diese Woche“, und am Freitag starrst du auf 47 aktualisierte Seiten — ohne eine saubere Antwort auf die Frage: „Also… wie ist der echte Status?“

Ich habe Teams gesehen, die das mit noch mehr Prozess lösen wollten: Tabellen, Übersetzungstickets, wöchentliche Syncs. Das funktioniert, bis jemand den Hero-Absatz auf 200 Seiten ändert. Dann wird wieder geraten.

Was bei uns schließlich funktioniert hat, war, Übersetzung wie ein Produktionssystem zu behandeln: TMGMT zum Nachverfolgen und Steuern, ein kleines Custom-Modul, das Jobs automatisch per Cron anstößt, und ein KI-Übersetzer, der im Hintergrund läuft und große Felder durch Chunking verarbeiten kann.

Dieser Artikel ist die Manager-Perspektive: Ergebnisse, Risiken und welche Fragen du deinem Team stellen solltest, damit daraus kein stilles Chaos wird.

Zuerst: Was „automatische Übersetzung“ wirklich bedeutet (in Drupal-Begriffen)

Wenn du dir einen magischen Button vorstellst, der eine komplette Website sofort in fünf Sprachen verwandelt — vergiss es. Die verlässliche Variante ist langsamer und langweiliger:

• Neuer oder aktualisierter Inhalt wird erkannt.
• Ein Übersetzungsjob wird erstellt und nachverfolgt.
• Die Arbeit läuft im Hintergrund nach Zeitplan.
• Ergebnisse landen in einem Review-Schritt (oder werden automatisch akzeptiert, wenn du dieses Risiko eingehen willst).
• Der übersetzte Inhalt wird veröffentlicht, wenn er deinen Regeln entspricht.

Dieses „Job“-Konzept ist der Grund, warum TMGMT ein gutes Rückgrat ist. Es ist darauf ausgelegt, Übersetzung als Arbeit mit Status, Tracking, Quellen und Übersetzer-Plugins zu managen.

Du kaufst also nicht „KI-Übersetzung“. Du kaufst einen Workflow, den du messen kannst.

Warum Cron und Queues kein Implementierungsdetail sind

Manager hören meist „cron“ und denken: „geplanter Task, passt“. Aber Drupals automatischer Cron läuft nach einem Zeitplan, der bei wenig Traffic ins Rutschen geraten kann, und in Standard-Setups kann er Last auf Benutzeranfragen legen.

Übersetzungsjobs sind schwergewichtig. Sie beinhalten externe API-Calls, Retries und manchmal lange Texte. Das zuverlässige Muster ist daher: Arbeit in eine Queue stellen und Cron sie dann in kontrollierten Scheiben abarbeiten lassen.

Die Management-Übersetzung davon:

• Eure Redakteur:innen warten nicht auf Übersetzung.
• Eure Website bekommt keinen Latenz‑Spike, nur weil jemand eine lange Seite veröffentlicht.
• Ihr könnt den Durchsatz tunen, indem ihr mehr oder weniger Hintergrundzeit zuteilt.
• Fehler werden auf kleine Arbeitseinheiten isoliert, statt den gesamten Lauf zu kippen.

Wenn euer Team das nicht eingeplant hat, bekommt ihr keine Automatisierung. Ihr bekommt einen neuen Failure Mode.

Der KI‑Teil: was ihr bekommt — und was nicht

Für den KI‑Übersetzer nutzen wir einen TMGMT‑kompatiblen Ansatz, damit Übersetzung weiterhin über Jobs und Workflow gemanagt wird — nicht über Einmal‑Skripte.

Aus Projektsicht ist die Provider-Wahl wichtiger, als viele erwarten. Sie gibt euch später Optionen:

• Ihr könnt Modelle wechseln, wenn sich die Kosten ändern.
• Ihr könnt sensible Inhalte anders routen, wenn Policies es verlangen.
• Ihr könnt den Prompt‑Stil pro Sprache anpassen, um Ton‑Drift zu reduzieren.
• Ihr könnt Übersetzungseinstellungen als Konfiguration behandeln statt als hart codierte Logik.

Aber verkauft es intern nicht zu groß. KI‑Übersetzung ist schnell und kann überraschend gut sein — sie braucht trotzdem Governance. Review‑Workflows haben ihren Grund.

Das große operative Risiko: lange Body-Felder

Das ist der Teil, von dem PMs meist erst nach dem ersten Incident hören.

Große Body-Felder (Dokumentation, Policy-Seiten, Seiten mit viel eingebettetem Markup) sind genau dort, wo naive KI-Übersetzung scheitert. Manchmal laut. Viel öfter leise: Teil-Ausgaben, inkonsistentes Formatting oder kaputtes HTML, das durchrutscht, bis es jemand auf der Live-Seite bemerkt.

Unser Fix ist nicht „besseres Prompting“. Es ist Engineering:

• Im Hintergrund übersetzen, nicht im Pfad der Benutzeranfrage.
• Große Body-Werte in Chunks splitten, die innerhalb praktikabler Grenzen bleiben.
• In der ursprünglichen Reihenfolge wieder zusammensetzen.
• Auf Chunk-Ebene retryen, damit ein Fehler nicht die ganze Seite blockiert.

Chunking bringt einen Trade-off mit: Terminologie kann zwischen Chunks driften. Das mildert ihr mit einem leichten Glossar oder Stilregeln pro Sprache.

Was das Custom-Modul macht (und warum ihr es wollt)

TMGMT ist der Workflow-Engine, aber irgendetwas muss trotzdem entscheiden, wann ein Übersetzungsjob erstellt wird. Genau das macht das Custom-Modul:

• Inhaltsänderungen erkennen.
• Festlegen, welche Sprachen für diesen Content-Type erforderlich sind.
• Übersetzungsjobs automatisch erstellen oder aktualisieren.
• Arbeit in eine Queue schieben, damit Cron sie später verarbeitet.

Das gibt euch einen vorhersehbaren operativen Rhythmus. Außerdem wird Übersetzung damit Teil der Publishing-Hygiene statt ein separater Projektstream.

In größeren Programmen wollt ihr explizite Regeln: welche Content-Types automatisch übersetzt werden, welche Review benötigen und was bei kleinen Edits versus größeren Rewrites passiert. Ohne Regeln wird Automatisierung zu überraschendem Verhalten.

Was ihr messen solltet (damit ihr erkennt, ob es funktioniert)

Wenn ihr Erfolg nicht definiert, definiert das Team ihn für euch — und euch könnte diese Definition nicht gefallen. Hier sind Metriken, die wirklich auf Outcomes einzahlen:

• Übersetzungs-Latenz: mediane Zeit von Publish/Update bis die Übersetzung zur Review verfügbar ist.
• Backlog-Größe: Anzahl der Items in „needs translation“ oder „needs review“.
• Nacharbeitsrate: wie oft Übersetzungen nach KI-Output von Menschen editiert werden.
• Fehlerrate: Retries, festhängende Jobs oder Formatierungsprobleme, die Intervention erfordern.

Nutzt Job-Tracking als Reporting-Oberfläche, statt ein paralleles Dashboard zu erfinden.

Governance: wo Projekte gelingen — oder euch leise peinlich werden

Der schnellste Weg, das Vertrauen in automatische Übersetzung zu verlieren, ist, etwas rechtlich Riskantes oder markenschädigendes zu veröffentlichen. Automatisierung vergrößert den Blast Radius.

Ihr braucht Policy-Entscheidungen, nicht nur Module:

• Welche Content-Types dürfen KI‑Übersetzungen automatisch veröffentlichen?
• Welche müssen durch ein Review?
• Wer ist Owner der Glossar-Termine für Produktnamen, juristische Formulierungen, regulierte Sprache?
• Was ist euer Rollback-Plan, wenn ein Model-Update den Ton verändert?

Ein Hybrid-Modell ist oft der vernünftige Kompromiss: KI übernimmt das Volumen, Menschen übernehmen das Risiko.

Ein Rollout-Plan, der euer Redaktionsteam nicht sprengt

Wenn ihr das auf einmal ausrollt, fühlen sich Redakteur:innen, als hätte sich der Boden verschoben. Es gibt einen besseren Weg.

Startet mit einem Content-Type, der klar strukturiert und risikoärmer ist. News-Posts, Event-Seiten, FAQs. Stabilisiert die Pipeline. Danach erweitert ihr auf das „chaotische“ Zeug: Longform-Seiten, Dokumentation, Marketing-Seiten mit schwerem Formatting.

Legt außerdem früh fest, wie ihr Cron betreibt. Zuverlässigkeit und Durchsatz beeinflussen Liefertermine stärker, als Teams unterschätzen. Das ist keine technische Fußnote.

Die Frage, die ich stellen würde, bevor ich das freigebe

Wenn das System läuft, wird Übersetzung zum Hintergrundrauschen. Genau das ist das Ziel.

Aber hier ist die unbequeme Frage: optimiert ihr auf Geschwindigkeit oder auf Vertrauen? Denn die Antwort entscheidet, ob ihr auto-published, wie strikt Reviews sind, welche Sprachen ihr zuerst ausrollt und wie viel ihr in Terminologie-Kontrolle investiert.

Wenn ihr mir sagt, welche Art von Website ihr betreibt (marketing-lastig, dokumentations-lastig oder gemischt) und wie viele Sprachen im Scope sind, kann ich einen Rollout vorschlagen, der zum Risikoprofil passt — statt so zu tun, als würde ein Workflow für alle funktionieren.

Auf der Suche nach der besten Drupal-Development-Company am Markt? Du hast sie gerade gefunden.

Wir sind die größte Drupal-fokussierte Digitalagentur, gebaut, um schnelle, sichere und skalierbare Plattformen zu liefern — ohne Kompromisse. Von Neubauten und Redesigns über Migrationen bis hin zu langfristigem Support liefern unsere Drupal-Expert:innen Enterprise-Ergebnisse mit Boutique-Aufmerksamkeit.

Buche heute einen Call — und lass uns eure Drupal-Roadmap in eine leistungsstarke Realität verwandeln.