Mit „_LOCAL_LANG.languageKey.label“ teilt man TYPO3 mit, für welche Sprache man welchen Text definieren möchte. „languageKey“ steht dabei für die jeweilige Sprache. Für „label“ muss der Index des Labels aus der Datei „locallang.xml“ eingesetzt werden. Auf diese Weise kann man Texte für alle Marker definieren, die durch die Erweiterung berücksichtigt werden.
Der Vorteil dieser Methode liegt auf der Hand: Auf die Abfrage der Bedingung „[globalVar = GP:L = id]“ kann verzichtet werden. Zusätzlich muss nicht für jede Sprache ein (X)HTML-Template gepflegt werden, was fehleranfällig und aufwändig wäre.
Damit die Definition von Textausgaben durch eine Erweiterung mit TypoScript funktioniert, muss diese entsprechend programmiert sein. Wird der Mechanismus, der die Inhalte aus der Datei „locallang.xml“ einliest, nicht angesprochen, werden auch die Definitionen im TypoScript nicht berücksichtigt.
In den TYPO3 Coding Guidelines [6] ist die Behandlung von Sprachen fest definiert. Leider halten sich viele Entwickler von Erweiterungen nicht an diese Vorgaben oder bieten nicht für alle Textausgaben Marker an. Streng genommen dürften solche Erweiterungen nicht als „stable“ markiert im TER zur Verfügung gestellt werden. Da auch diese Vorgabe oft nicht eingehalten wird, muss vor dem Einsatz einer Erweiterung also festgestellt werden, ob die Lokalisierung korrekt und vollständig Verwendung findet. Im Zweifelsfall bleibt leider doch nur der Umweg über die Pflege von (X)HTML-Templates für jede Sprache. Das beugt zumindest dem Verlust eigener Übersetzungen durch das Update der Erweiterung vor.
TYPO3-Erweiterungen konfigurieren
Die meisten Erweiterungen sind nach der Installation direkt einsetzbar. In der Regel ist jedoch ein individueller Einsatz erwünscht, weshalb die Konfiguration von Erweiterungen ein wesentlicher Bestandteil der Administration von TYPO3 ist.
Die Einarbeitung in umfangreiche Konfigurationsskripte kann mit einem erheblichen Zeitaufwand verbunden sein, den viele scheuen. Herumprobieren führt nicht immer zum gewünschten Ergebnis und so sieht man nicht wenige TYPO3-Installationen, für deren Konfiguration das TypoScript von Erweiterungen „der Sicherheit halber“ vollständig in ein eigenes TypoScript-Template kopiert wurde. Das verringert den tatsächlich anfallenden Aufwand jedoch nur selten, denn eine umfangreiche Konfiguration reduziert sich mit dieser Methode nicht und bleibt unübersichtlich. Wer effizient mit TypoScript arbeiten möchte, kommt um die Aufgabe, sich in die Konfiguration von Erweiterungen einzuarbeiten, nicht herum. Drückt man sich vor dieser Arbeit, kommt die Frage „Wie geht’s, wo steht's?“ spätestens dann wieder auf, wenn man nach einer Pause wieder Hand an die Konfiguration legen muss.
Eine gute Erweiterung liefert ein streng nach Constants und Setup aufgeteiltes TypoScript. Der Sinn und Zweck dieser Trennung ist, die Zuweisung von Werten für Variablen und funktionale Anweisungen voneinander zu unterscheiden. Die Festlegung der maximalen Breite einer durch eine Erweiterung ausgegebenen Grafik gehört in die Constants. Durch welchen Quelltext diese Grafik gewrapped wird, ist eine Frage, die im Setup beantwortet werden sollte. Die in den Constants festgelegten Werte müssen im Setup an die Konfiguration der Erweiterung übergeben werden, wodurch der Umfang des notwendigen TypoScripts wieder wächst. Diese Zuweisung sollte durch die Entwickler im „static template“ der Erweiterung bewerkstelligt werden, sodass sich der Anwender nicht darum kümmern muss.
Der Aufwand zur Konfiguration einer Erweiterung lässt sich also durch die Trennung von Constants und Setup stark reduzieren. Des Weiteren sollte nicht mehr TypoScript in das eigene Template übernommen werden, als für den Einsatz einer Erweiterung im Rahmen eines Projekts notwendig ist. In aufgeräumten, übersichtlichen TypoScript-Templates lassen sich Fehler sehr viel schneller entdecken und beheben.
Fazit
Die aspektorientierte Konfiguration von TYPO3 ist ein Ansatz, die Arbeit mit TypoScript für Administratoren zu erleichtern. Die in diesem Artikel vorgestellte Methode ist sicherlich nur eine von vielen möglichen Interpretationen dieses Paradigmas. In der Praxis hat sich gezeigt, dass die vorgestellte Umsetzung vielfältig einsetzbar ist. Dadurch wird nicht nur die Administration von individuellen Websites erleichtert, sondern gleichzeitig eine Vereinheitlichung der Arbeit über viele verschiedene Projekte hinweg erreicht.




