Von TYPO3 und Übersetzungsverhalten
TYPO3 ist ein in unzählige Richtungen anpassbares Content Management System. Dass dies manchmal auch Nachteile mit sich bringt, erfährt man schnell, wenn man von Sachen träumt, die TYPO3 zwar zur Verfügung stellt, es sich gleichzeitig aber auch dagegen sträubt, diese ohne Konsequenzen zu verarbeiten. Eine solche Sache ist das Übersetzungsverhalten. Besonders wenn es um die Übersetzung von einzelnen Records und deren Ausgabe in einer eigens entwickelten Extension geht.
Ausgangslage
Um alle Aspekte unter einen Hut zu bringen, bauen wir ein einfaches Beispiel auf. Gehen wir also von einer Extension aus, die Produkte und Kategorien umfasst.
Produkten können dabei mehrere Kategorien zugewiesen werden, wie man auf der Grafik rechts erkennen kann.
Des weiteren nehmen wir an, dass die Seite auf Deutsch und Englisch verfügbar ist, wobei Deutsch die Default-Sprache ist. Um es gleich noch etwas konkreter zu machen hat unser Beispielredaktor bereits einzelne Produkte, Kategorien und dazu jeweils auch Übersetzungen erstellt. Grafisch würde das folgendermassen aussehen:
Soweit so gut. Was noch fehlt sind die an sich offensichtlichen Zuweisungen der Produkte zu den einzelnen Kategorien.
Die problematische Anwendung
Verzichtet man auf zusätzliche Konfiguration des Übersetzungsverhaltens erhält man bei übersetzten Records im Backend die gleichen Eingabefelder wie bei der Default-Sprache.
Da wir hier ein Problem aufzeigen wollen, gehen wir davon aus, dass die Zuweisungen nicht ganz korrekt gemacht wurden. Der Redaktor hat den englischen Unkrautvernichter den Spielwaren und nicht den Gartengeräten zugeteilt. Das ergibt das zugegebenermassen verwirrende Bild:
Konsequenzen
Es drängt sich die Frage auf, warum es dem Redaktor überhaupt möglich war, die englische Variante einer anderen Kategorie zuzuweisen, wie die deutsche Ausgabe? Ist dies überhaupt nötig?
Zur Beantwortung stellen wir uns im Frontend eine Liste aller Produkte vor. Oberhalb der Liste befindet sich ein Kategorienfilter in Form einer Selectbox. Würde ich jetzt die Sprache ändern, könnte es sein, dass ich Kategorien erhalte die vorhin nicht verfügbar waren, oder in unserem Fall je nach Wahl der Kategorie andere Produkte aufgelistet werden. Ich sehe also nicht einfach Übersetzungen, sondern ich habe eine komplett andere Ausgabe vor mir. Die Antwort auf die ursprüngliche Frage ist demnach denkbar einfach: Nein natürlich nicht. Es ergibt keinen Sinn, einen Datensatz, nur weil der Titel in Englisch geschrieben ist, plötzlicher einer anderen Kategorie zuzuweisen wie den Default-Record.
In diesem Zusammenhang muss zusätzlich ein Umdenken stattfinden. TYPO3 speichert zwar Übersetzungen im Hintergrund als eigenen Datensatz, um das Übersetzungsverhalten aber richtig zu nutzen sollte man sich lieber einfach eine Übersetzung von Text und nicht einen separaten Datensatz vorstellen. Dann wird auch schnell klar, dass Zuweisungen zu anderen Datensätzen (wie in unserem Beispiel Kategorien) immer über den eigentlichen Datensatz, sprich den Default-Record gemacht werden sollen. Dies minimiert die Fehleranfälligkeit für Redaktoren und hat neben einem aufgeräumten Diagramm noch weitere Vorteile bei der Entwicklung.
Die saubere Anwendung und der technische Hintergrund
TYPO3 bietet die Möglichkeit einzelne Felder bei Übersetzungen auszublenden. Der gesuchte Parameter heisst „l10n_mode“ und ist in der Dokumentation des TCA zu finden. Weiter hilfreich ist „l10n_display“. Mithilfe dieses Parameters kann konfiguriert werden, dass das Feld zwar angezeigt, aber nicht bearbeitet werden kann. Stattdessen wird der Wert des Default-Records als Information für den Redaktor angegeben.
Bei der Extension-Entwicklung wird ebenfalls schnell klar, dass es keinen Weg am Default-Record vorbei geben sollte. TYPO3 stellt einige Methoden zur Verfügung um Übersetzungen zu handhaben. Unter anderem ist dies „getRecordOverlay“, die sich in der Klasse „t3lib_pageSelect“ befindet. Der Methode wird der Default-Record mitgegeben. Zurück kommen Übersetzungen der einzelnen Felder anhand der bereits besprochenen Konfiguration des „l10n_mode“-Parameters. Egal wie das Ergebnis aussieht, die Uid (also die eindeutige Identifikation des Datensatzes) zeigt immer auf den Default-Record.
Wenn wir zur Frontend-Ausgabe mit der Produkteliste und dem Kategorienfilter zurückgehen, heisst das, dass die Filterwerte (die values der Selectboxeinträge, nicht die Labels) immer gleich aussehen, egal in welcher Sprache ich die Seite ausgebe. Schicke ich den Filter ab, kann ich sprachunabhängig immer mit der gleichen Uid arbeiten um die zugewiesenen Produkte auszulesen. Habe ich die Liste der Produkte beisammen, geht es im zweiten Schritt noch darum diese allenfalls zu übersetzen und wieder auszugeben.
Kurz zusammengefasst, wie der Ablauf aussehen sollte:
- Uid des Default-Records der Kategorie wird mitgeschickt
- Zugewiesene Produkte werden gesucht (ebenfalls Default-Records)
- Vorhandene Übersetzungen werden geladen
- Ausgabe
Projektleiter oder Redaktoren internationaler Unternehmen stellen oft die Frage, was ist, wenn gewisse Produkte nur in einzelnen Ländern und demzufolge in einzelnen Sprachen verfügbar sein sollen?
Wie man aus der Fragestellung bereits herauslesen kann, ist dies nicht ein Problem, das grundsätzlich die Sprache betrifft. Ich kann in den USA eine deutschsprachige Seite anbieten und der umgekehrte Fall funktioniert genauso gut. Die Verfügbarkeit in einzelnen Ländern sollte man deshalb nicht über die Sprache, sondern über ein zusätzliches Feld handhaben.
In früheren TYPO3-Versionen war es sogar so, dass übersetzte Datensätze ohne Default-Record im Backend gar nicht aufgelistet wurden. So kam es im Frontend zur Ausgabe von Daten, die im Backend nicht aufzufinden waren. Der Fehler wurde mittlerweile behoben, aber wie der Artikel aufzeigen soll, ist es trotzdem keine gute Idee auf Records in der Default-Sprache zu verzichten.
