WordPress multilingual mit WPML

Vor kurzem habe ich das erste Mal eine Webseite auf Basis von WordPress mehrsprachig umgesetzt. Nach einiger Recherche fiel die Entscheidung auf die Verwendung des PlugIns WPML (WordPress Multilingual) zur Übersetzung der Inhalte. Hier nun ein kleiner Erfahrungsbericht.
WPML ist deswegen zur Auswahl gekommen, weil es „echte“ Übersetzungen erlaubt. Es kursieren unter dem Stichwort „mulitlingual“ oder „multi language“ auch etliche PlugIns, die eine automatisierte Übersetzung via Google Translate oder ähnlichen Diensten einfügen – die Qualität dieser Übersetzungen kennt man ja aus etlichen merkwürdigen Spam-Mails.
WPML bietet also die Möglichkeit, weitere Sprachfassungen zu allen Inhalten anzulegen. Dazu wird im Backend zum einen ein neuer Bereich ins Menü (WPML) und je eine neue Spalte in die Übersichten eingefügt, die anzeigt, ob zu einem Inhalt auch eine Übersetzung in den angelegten Sprachen vorhanden ist. Oben erscheint eine Flagge und in der Spalte darunter Symbole zum Anlegen (ein Plus) oder Ändern (ein Bleistift) eines Posts. Das Menü bietet Grundeinstellungen und Funktionen wie zum Beispiel die Übersetzung von einzelnen Phrasen aus den Templates an. Alles in allem ganz nett und intuitiv soweit. An der Integration ins WordPress-System jedenfalls kann man nicht meckern.
Viel komplexer wird es allerdings, die Templates auch entsprechend umzubauen.
Den größten Stolperstein bietet da meiner Meinung nach, dass Posts und Kategorien in den Sprachfassungen eine andere ID bekommen. Habe ich also einen deutschen Post mit der ID 5, hat der gleiche Post auf englisch eine andere ID, z.B. 354. Genau so verhält es sich mit Kategorien: auch diese haben andere IDs in den Sprachvarianten, auch die „Slugs“, die Kurzform in der Datenbank muss unterschiedlich sein.
Hat man nun also „harte“ Links in seinem Menü verwendet, werden diese eigentlich nicht mehr funktionieren. Hier greifen daher die Funktion „icl_link_to_element“, und die Funktion „ID-Adjust“. Die erste Funktion ersetzt bisher eingesetzte WordPress-Links, die zweite passt automatisch die IDs an, so dass es keine „toten“ Links mehr geben sollte.
Sofern noch nicht geschehen, sollten alle Theme-Dateien außerdem noch auf vorhandene Phrasen „Strings“ überprüft werden. Diese kann man dann „maskieren“ und so für WPMLs integrierte Funktion zur Übersetzung der Theme-Dateien zur Verfügung stellen. Die Maskierung geschieht über die Funktion

<?php _e('STRING'); ?>

.

Was fehlt ist aber immer noch die Übersetzung fester Begriffe aus WordPress. Es können an keiner Stelle die Begriffe „more…“ (für den automatischen Link zum Weiterlesen) oder für die Links zum Blättern in den Artikeln ersetzt werden. Diese kann man zwar in den Templates definieren, lassen sich aber nicht wie oben beschrieben maskieren (sie stehen ja schon in einer php-Funktion). Hier sehe ich noch Verbesserungspotential und habe noch keine Lösung für diesen Umstand gefunden. Hier sollte WPML noch eine Lösung anbieten. Man kann sich behelfen, indem man eine if/else-Abfrage schreibt, die aufgrund der URL einen anderen Code ausführt. Da man die Template-Tags durch Variablen ändern kann, ist eine Übersetzung über diesen Weg möglich.
Auch das Verfahren, jeder Sprachfassung eines Posts eine neue ID zu geben und nur über die Funktion „icl_link_to_element“ den Eintrag sprachneutral verlinken zu können, macht mehr Arbeit als notwendig. Hier geht das PlugIn „qTranslate“ einen anderen Weg und speichert zunächst einmal einen Artikel, den man dann in verschiedenen Sprachvarianten anlegt. Ob die Übersetzung und Programmierung der Templates nun mit „qtranslate“ besser als mit WPML funktioniert, kann ich leider nicht beurteilen. WPML kann ich aufgrund der Erfahrungen eigentlich schon empfehlen, gerade wenn man die hier beschriebenen Kniffe kennt.