Multilanguage mit automatischer Sprachwahl in TYPO3?

Ich habe einen Kunden, der eine mehrsprachige Internetseite betreiben möchte. Nach Feststellung der Anforderungen und dem Testen einer ML-Lösung für WordPress habe ich beschlossen, das Projekt mit TYPO3 umzusetzen. Auch mit dem Hintergrund der eingebauten Lokalisierungsmöglichkeit.

Nun stellte sich im Projektverlauf heraus, dass auch das nicht so einfach ist, wie ich es mir vorgestellt hatte.

Es muss immer noch schön alles per Hand eingestellt werden, wenn man die Sprache wechseln will. Hallo? 2010? Da geht doch mehr, oder nicht? Sprache anhand der Browser-Accept-Lang-Header identifizieren und so. Notfalls mit einem Language-Chooser überschreibbar. Aber dazu muss man 2 Plugins installieren („rlmp_language_detection“ und „sr_language_menu„), mit denen man die Sprachwahl 1. automatisieren und 2. überschreiben kann und dann noch mindestens 10 Zeilen TS-Config ins Setup und die Konstanten stecken muss.

Und da sind noch nicht die eigentlichen Sprachconfigs dabei mit mit jeder Sprache auch nochmal 8 Zeilen und mehr fressen. Ich will mich ja nicht beschweren, aber das ginge bestimmt einfacher. Sowas verstehe ich nicht unter „eingebauter Mehrsprachigkeit“. Und davon ist man auch bei dem tollen neuen TYPO3 4.4 noch weit entfernt, wie ich finde.

Webseite: IN-LIVE-EVENTS & GASTRO

Anforderungen

Die Webseite der Firma IN-LIVE EVENTS lief bisher auf einem proprietären CMS der Firma Compose. Ein Umzug auf einen anderen Server ist natürlich mit der kompletten Neuentwicklung der Seite verbunden.

Die Entwicklung hatte den Schwerpunkt auf bestmöglicher Suchmaschinenfreundlichkeit. Dazu zählte das Konzept, dass jetzt einen eindeutigen Fokus auf die Hauptgeschäftszweige der Firma legt: Cocktails und Events.

Screenshot: www.in-live-events.de

Umsetzung

Dem System liegt als Plattform das Wikisystem DokuWiki zugrunde, dass sich durch eine einfache Erweiterbarkeit durch Plugins und eine geringe Größe auszeichnet. Das Design und die Struktur basieren grob auf dem 360.gs-Framework, die einzelnen Seiten sind mittels dem „WRAP-Plugin“ für Dokuwiki sehr individuell gestaltbar.

Die Wahl auf DokuWiki im Vergleich zu WordPress fiel aufgrund der Möglichkeit, einzelne Inhaltselemente zu bearbeiten. Durch die flexible Inhaltsgestaltung haben wir den goldenen Mittelweg zwischen Einheitlichkeit durch vordefinierte Elemente und Vielfältigkeit durch einfache Variation und Anordnung der Elemente erreicht.

Der Tag an dem ich lernte, Conditional Comments zu lieben

Es gibt ja viele Möglichkeiten, eine Seite pixelgenau zu designen, so dass Sie in allen Browsern läuft gleich aussieht.

  1. Man baut die Seite aus Imageready-gesliceten Bildern in einem Tabellenlayout zusammen
  2. Man baut die Seite aus Imageready-gesliceten Bildern in einem DIV-Layout zusammen
  3. Man baut die Seite mit einem Tabellenlayout zusammen
  4. Man benutzt ordentliches (x)HTML mit CSS-Hacks
  5. Man benutzt ordentliches (x)HTML und Conditional Comments mit validem CSS
  6. Man benutzt ordentliches (x)HTML und valides CSS

Das Problem des gleichen Layouts betrifft im übrigen fast ausschließlich die Webbrowser aus Redmond. Eine valide Seite sieht in 95% aller Fälle in Firefox, Opera und Safari identisch aus. Lediglich der IE mit seinem verkorksten Boxmodel haut da quer. Der IE 8 im übrigen nur noch ganz selten.

Was nehm‘ ich denn da?

Dass wir die Punkte 1-3 vergessen können, sollte sich von selbst erklären. Tabellenlayouts sind rückständig und codeüberladen, außerdem semantisch unsinnig und barrierelastig.

Bleiben die Punkte 4-6 übrig. Wie man sieht, sind die Möglichkeiten ihrer Unsinnigkeit absteigend geordnet und dementsprechend werden wir diese drei Möglichkeiten jetzt mal durchgehen.

(x)HTML mit CSS-Hacks

CSS-Hacks sind kleine „Tricks“, die Interpretationsfehler bei Browsern ausnutzen um bestimmte CSS-Anweisungen nur für bestimmte Browser zugänglich zu machen. Diese Technik ist relativ zielgenau, auch weil es dafür entsprechende Zielhilfen gibt. Problem an der Geschichte ist, dass es leicht möglich ist, das CSS damit invalide zu machen, was zukünftig nicht vorhersehbare Bugs im Rendering noch nicht erschienener Browser erzeugen kann.

(x)HTML und Conditional Comments mit validem CSS

Die sauberste Möglichkeit, einem Rendering, dass von einzelnen Versionen des IE (und es ist in 95% aller Fälle mindestens einer der IEs der querschießt) zerschossen wird, zusätzliche CSS-Regeln beizubringen, sind CSS Conditional Comments. Hier werden zusätzliche CSS-Anweisungen für den Internet Explorer eingebunden. Dabei kann man sowohl ein paar zusätzliche Regeln mittels eines <style>-Tags einbringen oder einfach direkt ein zusätzliches Stylesheet einbinden.

Nachteil ist natürlich, dass diese Methode nur auf Internet-Explorer-Versionen unter Windows anwendbar sind. Meine bisherige Erfahrung hat aber gezeigt, dass Hacks/Workarounds im großen und ganzen nur für den IE nötig sind. Meistens auch unterschiedliche Lösungen für unterschiedliche Versionen.

Vorteil bei dieser Technick ist das Aufrechterhalten sämtlicher Validität in HTML und CSS, auch wenn man in den IE-Stylesheets unter Umständen Hacks einsetzt. Durch die Einbindung der Conditional Comments in Form eines speziell syntaktischen HTML-Kommentars werden andere Browser diese einfach ignorieriern und nicht ins DOM aufnehmen, wie es der IE tut, sofern er mit der Zielversion des Kommentars übereinstimmt.

Die restlichen 5% von Problemen, die sich damit nicht lösen lassen erfordern meist etwas Nachdenken über die CSS-Struktur und wie man Dinge anders beschreiben könnte. Allerdings muss man auch hier eventuell die IE-Styles dann nachpflegen, besonders wenn man am HTML etwas ändert.

(x)HTML mit validem CSS

Die „reinste“ Möglichkeit von allen. Erstrebenswert, aber eine Herausforderung, die sich gewaschen hat. Pixelgenaues Arbeiten ohne irgendwelche Kniffe ist kaum möglich. Für einfache Designs geht das bestimmt noch so halbwegs, aber dieses Blogdesign käme schon nicht ohne Extraregeln für den IE 6 aus, wenn ich ihn unterstützen wollte – was ich nicht will.

Vorteil ist bei dieser Methode eine sehr hohe Zukunftssicherheit, während man sich hier nicht allzusehr auf pixelgenaues Arbeiten versteifen sollte. Irgendein IE macht immer einen Strich durch die Rechnung.

Zusammenfassung

Wenn möglich, ohne Hacks, ohne Conditional Comments und Co. Wenn aber unbedingt hier im IE und da was im IE gemacht werden muss (wofür es natürlich mehrere Gründe geben kann, meistens ist es ein Kundenwunsch), dann am besten mit Conditional Comments.

Links

Rainbow-Wallpaper

Keine Ahnung, was mich da gerade überkam. Aber ich hab mal ein buntes Wallpaper gemacht. Bedient euch!

Made with GIMP on Linux, die Schrift ist Ubahn von Manfred Klein.

Wenn’s euch gefällt, sagt es mir, dann werd ich zukünftig auch mal das eine oder andere Wallpaper einstellen, wenn’s gefällt.