KI-Übersetzung direkt im CMS: TYPO3 14, der neue Translation Wizard und Ollama

Wie der modernisierte Übersetzungs-Workflow in TYPO3 14 funktioniert – und wie wir ihn mit TranslateGemma 27b für vollautomatische KI-Übersetzungen erweitert haben.

TYPO3 14: Ein neues Kapitel für Mehrsprachigkeit

Mit TYPO3 14.3 LTS, veröffentlicht im April 2026, steht nun die langfristig unterstützte Version der 14er-Reihe bereit. Sie bündelt die seit 14.0 eingeführten Neuerungen – darunter über 2.000 Änderungen – und legt einen klaren Schwerpunkt auf die Editor-Experience, insbesondere beim Arbeiten mit mehrsprachigen Inhalten.

Das Herzstück dieser Neuerungen im Übersetzungsbereich ist Feature #108049 – Modernized Translation Workflow: Der bisherige monolithische Lokalisierungsdialog wurde vollständig durch ein schrittbasiertes Wizard-System ersetzt.

Was hat sich konkret geändert?

Vorher: Der Übersetzungsdialog war ein einfaches Modal, das nur im Modul Content > Layout (früher: Web > Page) verfügbar war – je nach Kontext mit leicht abweichendem Verhalten.

Jetzt: Ein einheitlicher, geführter Wizard öffnet sich überall im Backend, sobald eine Übersetzung angestoßen wird – egal ob in der Seitenansicht, der Listenansicht oder einem anderen Modul. Der Wizard führt Schritt für Schritt durch den Prozess und überspringt automatisch Schritte, bei denen keine Nutzereingabe nötig ist.

Zusätzlich verbessert TYPO3 14 die Sprachauswahl im Backend grundlegend: Redakteure können mehrere Sprachen gleichzeitig anzeigen, zwischen ihnen wechseln und die Auswahl bleibt konsistent zwischen Page- und List-Modul erhalten.

„The new translation system also lets developers integrate custom localization handlers, including connections to third-party translation services or AI tools.”
— TYPO3 News, Dezember 2025

Genau dieser letzte Satz war unser Startpunkt.

Die neue Handler-API: Offen für eigene Übersetzungsdienste

Technisch gesehen führt TYPO3 14 im Namespace TYPO3\CMS\Backend\Localization ein neues Interface ein: das LocalizationHandlerInterface. Wer es implementiert, erscheint im Wizard als wählbare Übersetzungsoption – gleichrangig neben der eingebauten manuellen Übersetzung.

Das Interface ist in der TYPO3-Dokumentation unter Feature #108049 beschrieben und verlangt sechs Methoden:

interface LocalizationHandlerInterface
{
    public function getIdentifier(): string;     // eindeutige ID
    public function getLabel(): string;          // Anzeigename im Wizard
    public function getDescription(): string;    // Kurzbeschreibung
    public function getIconIdentifier(): string; // TYPO3-Icon-ID
    public function isAvailable(LocalizationInstructions $instructions): bool;
    public function processLocalization(LocalizationInstructions $instructions): LocalizationResult;
}

Das DTO LocalizationInstructions enthält alle nötigen Informationen für den Handler:

final readonly class LocalizationInstructions
{
    public string $mainRecordType;  // z. B. 'pages' oder 'tt_content'
    public int    $recordUid;
    public int    $sourceLanguageId;
    public int    $targetLanguageId;
    public LocalizationMode $mode; // 'translate' oder 'copy'
    public array  $additionalData; // z. B. ausgewählte Content-Element-UIDs
}

Der Handler gibt ein LocalizationResult zurück – entweder mit Erfolg und einem Finisher (der vorgibt, was der Wizard danach tut: Redirect, Reload, oder nichts), oder mit einer Fehlerliste.

Die Registrierung erfolgt über einen Symfony-Service-Tag:

UniErfurt\OllamaTranslate\Localization\OllamaLocalizationHandler:
  tags:
    - name: backend.localization.handler

Unsere Extension: `ollama_translate`

Auf Basis dieser API haben wir die Extension ollama_translate entwickelt, die den HPC-Ollama-Cluster des HS-ITZ mit dem TYPO3-Übersetzungs-Wizard verbindet. Als Modell kommt TranslateGemma 27b zum Einsatz – ein auf Übersetzungsaufgaben spezialisiertes Modell auf Basis von Googles Gemma-Architektur.

Ablauf einer Übersetzung

Der Wizard öffnet sich – Ollama / TranslateGemma erscheint als Auswahloption

Nach Bestätigung: TYPO3 legt die übersetzten Records per DataHandler an

Redakteur wechselt im Layout-Modul auf die Zielsprache (z. B. Deutsch)
Klick auf „Übersetzen” bei einem Content-Element oder einer Seite
Der Wizard öffnet sich – Ollama / TranslateGemma erscheint als Auswahloption
Nach Bestätigung: TYPO3 legt die übersetzten Records per DataHandler an
Unser Handler ruft für jedes Textfeld die Ollama-API auf und schreibt die Übersetzung zurück
Der Wizard schließt und leitet zur übersetzten Seite weiter

Kommunikation mit Ollama

Die Extension spricht den /api/chat-Endpunkt des Ollama-Clusters an – das offizielle Chat-API-Format von Ollama (Dokumentation):

$payload = [
    'model'  => 'translategemma:27b',
    'stream' => false,
    'messages' => [[
        'role'    => 'user',
        'content' => "Translate from {$sourceLang} to {$targetLang}. 
                      Return only the translated text: {$text}",
    ]],
];

// Ollama gibt zurück:
// { "message": { "role": "assistant", "content": "..." } }
$translation = $data['message']['content'];

Welche Felder werden übersetzt?

Der Handler liest dynamisch die TCA-Konfiguration des jeweiligen Tabelle aus und übersetzt alle Felder vom Typ input oder text, die nicht explizit mit l10n_mode: exclude ausgeschlossen sind. Das macht die Extension universell einsetzbar – für tt_content, pages und beliebige Custom-Tables.

Stolpersteine – damit ihr es einfacher habt

Die Entwicklung war kein gerader Weg. Hier die wichtigsten Fallstricke:

1. Falscher Namespace – der häufigste Fehler

Das Interface LocalizationHandlerInterface gibt es in TYPO3 zweimal. Eines im Core-Namespace für völlig andere Zwecke, eines neu in Backend. Der Handler erscheint im Wizard überhaupt nicht, wenn der falsche Namespace importiert wird – ohne jede Fehlermeldung:

// FALSCH – bitte nicht:
use TYPO3\CMS\Core\Localization\LocalizationHandlerInterface;

// RICHTIG:
use TYPO3\CMS\Backend\Localization\LocalizationHandlerInterface;

2. Autoconfiguration funktioniert nicht – expliziter Tag nötig

Die offizielle Dokumentation beschreibt, Handler würden per Autoconfiguration automatisch erkannt. In TYPO3 14.3 stimmt das nicht. Der LocalizationHandlerRegistry sammelt Handler ausschließlich über den Tag backend.localization.handler, der explizit gesetzt werden muss. Ein Wildcard-Scan (resource: '../Classes/*') reicht nicht – und verursacht zudem ein Henne-Ei-Problem beim composer dumpautoload, weil Symfony versucht alle Klassen zu laden bevor der Autoloader fertig ist.

3. `LocalizationInstructions` enthält keine Sprach-Objekte

Ich hatte erwartet, dort SiteLanguage-Objekte zu finden. Tatsächlich gibt es nur Integer-IDs. Der ISO-Code muss über den SiteFinder aufgelöst werden – und die Methode heißt nicht getTwoLetterIsoCode() (existiert in TYPO3 14 nicht mehr), sondern:

$language->getLocale()->getLanguageCode();

4. `LocalizationResult::success()` braucht einen Finisher

Die Signatur ist anders als man vermuten könnte:

// FALSCH – Methode existiert nicht:
LocalizationResult::createSuccess($data)

// RICHTIG – ein Finisher ist Pflicht:
LocalizationResult::success(new RedirectLocalizationFinisher($url))
LocalizationResult::success(new ReloadLocalizationFinisher())

5. Der Handler überschreibt keine Inhalte selbst – DataHandler muss zweimal laufen

Ein konzeptioneller Punkt: Der Handler ist nicht dafür gedacht, Records zu erstellen. Das macht TYPO3 selbst. Der Handler bekommt erst danach die Kontrolle. Das bedeutet:

Erst Records per DataHandler anlegen (localize/copy)
Die UIDs der neu angelegten Records aus $dataHandler->copyMappingArray_merged auslesen
Dann diese Records mit den Übersetzungen per zweitem DataHandler-Aufruf befüllen

6. Ollama-Response-Format ≠ OpenAI-Format

Wer vorher mit der OpenAI-API gearbeitet hat, greift instinktiv auf choices[0] zu. Ollama /api/chat gibt ein anderes Format zurück:

{ "message": { "role": "assistant", "content": "..." } }

7. DDEV: Alles im Container ausführen

composer dumpautoload auf dem Host aktualisiert den Autoloader des Host-Systems – nicht den des DDEV-Containers. Alle Befehle müssen mit ddev exec bzw. ddev composer laufen. Klingt trivial, kostet aber viel Zeit wenn man es vergisst.

Ergebnis

Noch ist die Lösung nicht produktiv im Einsatz. Mit TYPO3 14 und der neuen Handler-API steht jedoch erstmals eine saubere, integrierte Erweiterungsmöglichkeit bereit, um KI-gestützte Übersetzungen direkt in den Redaktionsworkflow einzubinden.

Die Extension zeigt, dass sich Modelle wie TranslateGemma 27b ohne Medienbruch in den Wizard integrieren lassen – technisch stabil und für Redakteure nahtlos bedienbar. Für das geplante Upgrade auf TYPO3 14 ergibt sich damit eine zusätzliche, praxisnahe Option, um Übersetzungsprozesse künftig deutlich zu vereinfachen und zu beschleunigen.

Quellen & Links

Update:

Auch Glossare und RTE-Felder sind in der Extension bereits mitgedacht. Das Glossar unterscheidet zwischen proper und term: Eigennamen wie „Universität Erfurt“ können per Platzhalter geschützt und unverändert übernommen werden, während Fachbegriffe als Kontext an das Modell gehen und im Deutschen grammatikalisch passend flektiert werden können. Damit bleibt die Übersetzung kontrollierbar, ohne dem Modell jede sprachliche Anpassung zu verbieten.

Auch Rich-Text-Felder werden nicht einfach als HTML-Block an Ollama geschickt. Die Extension zerlegt den Inhalt per DOM-Parsing, übersetzt nur die Textknoten und setzt das HTML anschließend wieder zusammen. Tags, Links, Attribute und Struktur bleiben dadurch erhalten, während der sichtbare Text übersetzt wird.