Wenn Inhalte nicht übersetzt werden sollen: Mehrsprachigkeit in TYPO3 richtig modellieren

Image Description
Christopher Zechendorf
29.06.2026
Share:

Manche Inhalte sind echt übersetzbar, andere sprachneutral. Wie wir bei VINUM Dubletten, explodierende Tabellen und falsche Suchergebnisse an der Wurzel beheben.

Wenn Inhalte nicht übersetzt werden sollen: Mehrsprachigkeit in TYPO3 richtig modellieren

Nicht alles, was mehrsprachig ist, will übersetzt werden

Mehrsprachige Websites gelten als gelöstes Problem: Man legt die Sprachen an, übersetzt die Inhalte, fertig. In der Praxis steckt die Komplexität woanders – nämlich in der Frage, welche Inhalte überhaupt übersetzt gehören. Auf einer Plattform wie VINUM, die in drei Sprachräumen (Deutschland, Schweiz und französische Schweiz) ausgespielt wird, sind manche Daten echte Übersetzungen – ein Titel etwa lautet auf Französisch anders. Andere Daten sind dagegen sprachneutral: Eine Verkostungsnotiz zu einem bestimmten Wein ist dieselbe, egal in welcher Sprachversion sie erscheint.

Vermischt man beide Fälle im Datenmodell, entstehen Probleme, die zunächst nichts mit Sprache zu tun zu haben scheinen: Datensätze vermehren sich, Tabellen wachsen ins Uferlose, und die Suche zeigt veraltete Ergebnisse. Dieser Beitrag zeigt am echten Projekt, wie man die Sprach-Architektur von Anfang an sauber aufsetzt – und wie wir genau diese Wurzel bei einer bestehenden Plattform saniert haben.

Die Herausforderung

Auf der Weinplattform waren mehrere Objekte als “übersetzbar” modelliert, die es inhaltlich gar nicht sind. Eine Degustation (ein Verkostungsereignis) etwa hat zahlreiche untergeordnete Verkostungsnotizen. Diese Notizen sind sprachneutral – und doch hingen sie an einem übersetzbaren Eltern-Objekt.

Das Tückische: TYPO3 nimmt eine solche Modellierung wörtlich. Sobald ein übersetztes Eltern-Objekt gespeichert wird, versucht das System, dessen untergeordnete Datensätze “mitzuübersetzen” – und legt dabei Kopien an. Bei jedem weiteren Speichern entstehen neue Kopien. Eine einzige grosse Degustation wuchs so von gut 800 auf rund 148.000 Notiz-Datensätze. Über alle Objekte hinweg sammelten sich Tausende Dubletten und verwaiste Verknüpfungen an.

Die Folgen waren konkret spürbar: Die öffentliche Weinsuche zeigte für eine aktuelle Verkostung keine frischen Treffer mehr, weil die Notizen mit der falschen Sprach-Kennung im Suchindex landeten. Und ein zuvor selbst gebauter “Aufräum-Mechanismus”, der die Klone nachträglich wieder löschte, kämpfte nur gegen das Symptom – nicht gegen die Ursache.

Unsere Lösung

1. Die eigentliche Ursache: geklonte Datensätze beim Übersetzen

Der Kern des Problems steckte in einer einzigen Einstellung an den verschachtelten Beziehungen (Inline-Relationen) zwischen Eltern- und Kind-Datensätzen. Sie wies TYPO3 an, die Kind-Datensätze beim Lokalisieren gesondert zu behandeln. Der TYPO3-DataHandler – die zentrale Komponente, die alle Schreibvorgänge verarbeitet – interpretiert das so: Fehlt ein Kind-Datensatz in der Übersetzung, kopiere ihn. Diese Kopien tragen keine saubere Rückverknüpfung zum Original, weshalb das System sie bei der nächsten Prüfung erneut für “fehlend” hält und wieder kopiert – ein Aufschaukeln ohne Obergrenze.

Der erste Schritt war daher, diese Einstellung von den betroffenen Inline-Relationen zu entfernen. Damit endet die Vermehrung beim Speichern. Wichtig dabei: Das ist Vorbeugung, nicht Nachsorge. In der Verifikation haben wir reproduziert, dass dasselbe Speichern vorher Hunderte Kopien erzeugte und danach exakt null.

2. Bewusste Entscheidung: sprachneutrale Inhalte als “alle Sprachen”

Die Vermeidung der Klone war nur die halbe Miete. Der eigentliche Designfehler war, sprachneutrale Objekte überhaupt als übersetzbar zu deklarieren. Also haben wir sie konsequent als das modelliert, was sie sind: sprachneutral.

TYPO3 kennt dafür eine eigene Sprach-Kennung – den Wert “alle Sprachen” (intern sys_language_uid = -1). Ein so markierter Datensatz gilt in jeder Sprachversion und wird nie übersetzt oder kopiert. Die Verkostungsnotizen tragen jetzt durchgängig diese Kennung; die übergeordneten Objekte sind nicht mehr übersetzbar.

Damit das auch dauerhaft hält, mussten wir alle Wege absichern, auf denen neue Datensätze entstehen – sowohl die Bearbeitung im Backend als auch die Erstellung über das Frontend. An jeder dieser Stellen wird die Sprach-Kennung “alle Sprachen” erzwungen. Zusätzlich haben wir die bereits falsch gespeicherten Datensätze – über 5.000 Stück – per Migrationsskript auf den korrekten Wert zurückgeführt.

3. Das Shadow-Field-Muster für die wenigen sprachabhängigen Felder

Bleibt die Frage: Was ist mit den Feldern, die doch eine eigene französische Fassung brauchen, etwa der Titel einer Kategorie? Die naheliegende Antwort – “dann macht den ganzen Datensatz eben übersetzbar” – führt direkt zurück ins Klon-Problem.

Stattdessen nutzen wir ein Shadow-Field-Muster: Neben dem normalen Titelfeld erhält das Objekt eine zusätzliche Spalte allein für die französische Fassung. Der Datensatz bleibt sprachneutral, nur dieses eine Feld kennt eine Variante. Damit nicht Dutzende Ausgabestellen einzeln angepasst werden müssen, läuft die Titel-Ausgabe über einen zentralen Mechanismus, der im französischen Kontext automatisch das Französisch-Feld liefert und sonst den Standardtitel. So liessen sich rund 57 Stellen in den Templates mechanisch und ohne Regressionsrisiko umstellen.

4. Verbundene Übersetzung statt selbstgebauter Aufräum-Logik

Einige wenige Objekte – etwa Wettbewerbs- und Guide-Kategorien – brauchen tatsächlich eine echte Titelübersetzung. Für sie nutzen wir nun die “verbundene” Übersetzung, die TYPO3 von Haus aus mitbringt: Jede Kategorie bekommt genau eine fest verknüpfte Übersetzung pro Sprache. Anders als beim Kopiermechanismus erkennt das System diese Verknüpfung wieder und dupliziert sie bei späteren Änderungen nicht erneut.

Mit dem sauberen Standardverhalten wurde der selbst gebaute Workaround überflüssig. Wir konnten den nachträglichen “Klone-aufräumen”-Mechanismus und das zugehörige Wartungskommando ersatzlos entfernen. Toter Code, der zuvor jede Bereitstellung mitschleppte, ist verschwunden – das System wurde nicht nur korrekt, sondern auch schlanker.

5. Sprach-Fallback und Menüs: das Gate wieder einsetzen

Während der Vorbereitung auf TYPO3 v13 fiel eine vermeintlich überflüssige Einstellung weg, die Seiten ohne Übersetzung in der aktuellen Sprache aus den Menüs ausblendete. Die Folge: Plötzlich tauchten fremdsprachige Seiten in den deutschen, schweizerischen und französischen Menüs auf.

Die Korrektur stellt dieses “Gate” auf eine v13-taugliche Weise wieder her: Ein Menü zeigt nur noch Seiten, die in der aktuellen Sprache tatsächlich übersetzt sind. Der inhaltliche Fallback bleibt davon unberührt – für Deutschland und die Deutschschweiz greift weiterhin der Standardinhalt, wenn keine Übersetzung existiert, während die französische Version bewusst nur französische Inhalte zeigt. Sichtbarkeit der Seite und Fallback des Inhalts sind damit zwei getrennte, jeweils korrekt gesteuerte Mechanismen.

6. Auswirkung auf die Suche

Der rote Faden dieses Projekts: Konsistente Sprach-Kennungen sind die Voraussetzung dafür, dass die SolR-Suche aktuelle Ergebnisse liefert. Solange die Verkostungsnotizen mit uneinheitlichen Sprach-IDs gespeichert waren, wurde der Index für einzelne Sprachen nicht zuverlässig aktualisiert – genau deshalb fehlten in der Weinsuche die frischen Treffer.

Nachdem die Datensätze einheitlich als “alle Sprachen” geführt und die betroffenen Indizes neu aufgebaut waren, lieferte die Suche in allen drei Sprachräumen wieder konsistente, aktuelle Resultate.

Das Ergebnis

Nach der Sanierung dupliziert weder das Übersetzen noch das Speichern noch irgendeinen Datensatz. Die wenigen wirklich sprachabhängigen Felder erscheinen pro Sprache korrekt, die Suche ist über alle Sprachräume konsistent, und ein ganzer Block selbst gebauter Aufräum-Logik konnte ersatzlos entfallen.

Die wichtigste Lehre ist keine technische, sondern eine konzeptionelle: Mehrsprachigkeit beginnt nicht beim Übersetzen, sondern bei der Entscheidung, was übersetzt werden soll. Wer für jedes Objekt früh festlegt, ob es echt übersetzbar oder sprachneutral ist, und das im Datenmodell sauber abbildet, erspart sich Dubletten, explodierende Tabellen und schwer auffindbare Suchfehler. Nachträglich diese Wurzel zu sanieren ist möglich – es ist nur deutlich aufwendiger, als es von Beginn an richtig zu modellieren.

Planen Sie eine mehrsprachige Website oder kämpfen Sie mit einer bestehenden TYPO3-Installation, die sich beim Übersetzen seltsam verhält? Sprechen Sie uns an – wir schauen uns Ihre Sprach-Architektur gemeinsam an.

Interesse geweckt? Top-Stories direkt in Ihre Mailbox:

Share:

Über den Autor

Christopher Zechendorf

Christopher Zechendorf

Christopher Zechendorf leitet die ext.dev GmbH und bringt über 25 Jahre Erfahrung in Webentwicklung, CMS-Systemen und Infrastruktur mit.