Teil 3. Seiten duplizieren – Jede Sprache eine WordPress Kopie

Der Titel verrät bereits was das Prinzip dieses Konzepts für eine mehrsprachige WordPressseite beinhaltet.

In den meisten Fällen wird der mehrsprachige Aufbau einer Seite nicht beim Launch geplant, sondern ergibt sich aus der Beobachtung der Zielgruppe, sowie durch die Ausweitung des Angebots.

Dabei ist es in keinem Fall ungewöhnlich eine Seite für eine weitere Sprachversion einfach zu duplizieren. Schlussendlich passiert bei den vorhergegangenen Konzepten im Prinzip nichts anderes, als das die Inhalte in einer weiteren Sprache zusätzlich angeboten werden.

Die Vorgehensweise ist simpel. Man zieht eine Kopie des gesamten deutschen Setups inklusive Datenbank und Dateien. Idealerweise bereitet man eine Domain sowie einen geeigneten Webspace für die englische Version der Seite vor.

Um die Kopie aufzusetzen, gibt es verschiedene Ansätze:

A. Frisches WordPress Setup – Datenimport
Installieren Sie eine frische und aktuelle WordPress Version auf dem Webspace idealerweise direkt in der jeweiligen Sprache der Zielseite. Damit erhalten Sie für Standardtexte auch gleich die aktuellen Sprachdateien für WordPress, falls Sie Standardanwendungen wie zum Beispiel die Kommentarfunktion nützen.

Im Menü „Werkzeuge“ bzw. „Tools“ gibt es die Funktion WordPress Export XML importieren. Sie können also auch die deutsche Version als XML exportieren und in das neue Setup importieren. Hier kommt es jedoch sehr oft zu Broken Links und vielen Fehlern. Besser ist es die Dateien manuell einzuspielen und die Seite quasi mit den bereits vorhandenen Daten nachzubauen. Bei dieser Gelegenheit lassen sich zum Beispiel auch Entwicklerkommentare, etc. aus dem Theme entfernen, die man in der Erstversion bei der Erstellung vielleicht angelegt hat.

B. Setup-Kopie – Datenbank Update
Für diesen Ansatz werden alle WordPress Daten von der deutschen Version auf den Webspace geladen. Zuerst muss dann die wp-config Datei angepasst werden. Hier müssen vor allem die Zugangsdaten für die MySQL Datenbank, sowie die BASE-URL für die WordPress Installation angepasst werden.

Danach müssen einige Standard-Pfade direkt in der Datenbank angepasst werden.

1. Zuerst einmal die Permalink Struktur auf die Standard Version zurückstellen, also auf
/?p=123
2. In der Tabelle _options die Werte siteurl, home bzw. recently_edited anpassen.
3. In der Tabelle _posts & _postmeta muss nichts angepasst werden, das wird mit Re-Aktivierung der Permalinks neu gesetzt. In einzelnen Fällen kann es vorkommen, dass man Artikel nochmals neu publishen muss. Da man die Übersetzungen einfügen muss, ist jeder Inhalt sowieo noch mal zu kontrollieren.

Für die letzte Kontrolle auf „alte“ Pfadangaben bietet sich der folgende SQL Befehl an:

UPDATE tabellenname SET feldname = replace(feldname, suchstring, ersatzstring);

Ist die weitere Sprachversion aufgebaut, geht es an den Language Switch. Die einfachsten Lösung ist es einfach den Link zum neuen Setup im alten Setup zu platzieren und umgekehrt. Das heißt sie fügen zum Beispiel eine österreichische Flagge + Deutsche Version in der neuen englischen Version ein und setzen den Link vom neuen Setup auf die bisherige Startseite des deutschen Setups. Genau das gleiche machen Sie auch für das alte Setup.

Warum keine direkte Verknüpfung zwischen übersetzten Inhalten
Natürlich ist das die „korrekteste“ Lösung, was den Language Switch angeht. Aus Usability Sicht hingegen wechselt ein Besucher im Netz nur sehr selten die Sprache, wenn er bereits den Inhalt in der Muttersprache gefunden hat.

Die Vorteile:

• Eigenständigkeit der Sprachversionen – Während man bei multilingualen Lösungen für WordPress für Abweichungen zwischen zwei Sprachen immer individiuell eine Lösung mit Conditions und Template Tags finden muss, kann in den zwei seperaten Systemen bedenkenlos entwickelt und auch verschiedene Plugins eingesetzt werden.
• Migration – Wenn jemand schon einmal damit konfrontiert war ein mehrsprachiges System zu migrieren, dann kann er diesen Punkt wohl am Besten verstehen. So schön es ist die vorgerfertigten Plugins und Lösungen zur Mehrsprachigkeit einzusetzen, so ein Alptraum ist aber auch diese zum Beispiel auf einen neuen Hosting-Account bzw. eine andere Domain zu transferieren. Mit dieser Lösung migrieren Sie jeweils ein einsprachiges Setup.

Die Nachteile:

• Der Aufwand für die Wartung des Systems verdoppelt sich mit einer neuen Sprachversion. Plugins updaten muss man mit diesem Setup pro Sprachversion.
• Aus Kostensicht ist es auch die teuerste Lösung, was zum Beispiel das Hosting betrifft.

Ideen & Tricks:

• Sollten Sie sich für das Duplikat-Setup entscheiden, reservieren Sie sich die jeweilige Top-Level Domain für das sprachliche Zielland und legen Sie die weitere Sprachversion auf ein eigenes Web-Hosting Paket mit einer anderen IP-Adresse bzw. einem anderen Class-C Netzwerk. So erhalten Sie für beide Sprachversionen durch die gegenseitige Verlinkung mehr IP-Pop.
• ABER: Generell können natürlich beide Setups auf dem gleichen Webhosting Account liegen und über Unterordner getrennt werden. Der Faktor Serverstandort, sowie verschiedene IP Adressen macht keinen sehr großen Unterschied im Bezug auf Rankings und SEO Potential aus.
• Übertreiben Sie es nicht mit den Sprachversionen! Sie bilden mit dieser Lösung ein Netzwerk an verschieden-sprachigen Webseiten. Google mag keine Linknetzwerke und im Endeffekt bauen Sie mit dieser Lösung so etwas in der Art.
• In den Webmaster-Tools kann die neue Sprachversion gleich wie die dt. Ausgangseite eigenständig eingetragen werden und ebenfalls geografisch zugeordnet werden.

In nächsten Teil der Artikelserie behandeln wir die logische Weiterentwicklung dieses Konzepts – WordPress Multisite Installation bzw. Blognetzwerke – Teil 4.

« zurück zu Teil 2. – Mehrsprachigkeit Plugins – WPML, Xili-Language, Polylang od. qTranslate