Die Behandlung von Mehrsprachigkeit in TYPO3 ist sehr flexibel. Manche Möglichkeiten sind „neuer“ (z.B XLIFF), andere sind schon immer mit an Board gewesen. Viele Wege führen ans Ziel – und das sorgt wohl manchmal auch für Verwirrung und Verirrung…
Ein Beispiel, wie man Language-Handling mit TypoScript NICHT umsetzt, will ich kurz teilen, und erklären, warum man das so nicht machen will.
Conditions sind böse!
Vor dem Ausliefern von Daten aus dem Cache, werden die gespeicherten Conditions aus dem TypoScript erneut evaluiert. Nur bei selbem Zustand der Condition Evaluierungen wird die Seite aus dem Cache geliefert.
TypoScript ist in der Regel für die gesamte Website eingebunden, d.h. für jede Einzelseite dasselbe. Das heißt, dass beim Aufruf jeder Seite jeder Condition noch einmal geprüft wird, bevor irgendetwas aus dem Cache geholt wird. Jede Condition, bei jedem Aufruf!
Wer sich damit näher beschäftigen möchte: mit „TypoScript Performance Condition“ landet man schnell bei guten Treffern.
Lösung
Die Umschalterei auf die richtigen Sprachlabels nimmt uns TYPO3 von ganz alleine ab. Wir müssen _LOCAL_LANG lediglich korrekt nutzen.
Die Form der Einträge ist definiert mit: _LOCAL_LANG.[lang-key].[label-key]
Kehren wir zu vorgefunden Snippet von oben zurück: benötigt wird ein vom Standard des Plugins abweichendes Label für die englische Version (Das war in dem Fall languageId 1) und ein abweichendes Label für Deutsch (Das war in dem Fall die Standardsprache der Website).
plugin.tx_felogin_login {
_LOCAL_LANG {
default {
success_header = Login successful
}
de {
success_header = Login erfolgreich
}
}
}
Man kann es gar nicht oft genug sagen, dass die Anzahl an Conditions so minimal wie möglich gehalten werden sollte. Nicht nur beim Languagehandling, auch wenn es darum geht, z.B. Staging-Systeme auseinander zu halten. Sowas macht man am Besten mit Environment Variablen. Und und und.