Multilingual | WP-Plugins

Lösungen für Multilingual WordPress Sites

wilhelmsburg 285920 1920

Der WordPress Kern ist zwar nicht auf mehrsprachige Websites ausgelegt. Dennoch gibt es eine Reihe interessanter Lösungen einen mehrsprachigen Internetauftritt mit WordPress umzusetzen.

Lösungen für Standalone-Sites

Premium-Plugin: WPML

Viele Jahre Erfahrung und Entwicklung stecken hinter diesem Flaggschiff und seinen Erweiterungen. Für eine Standalone-WordPress-Installation gibt es meines Wissens bis heute keine umfassendere Lösung. Sie ist jedoch nicht mehr kostenlos. Wer die regelmäßige Bezahlung von Abos scheut, für den gibt es eine leistbare Lifetime-Lizenz die es Kunden oder einem selbst erspart, sich alle Jahre wieder um die Erneuerung zu kümmern – die Lifetime-Lizenz wird aufgelassen. Bestehende erhalten weiterhin unbegrenzt Updates.

WPML bringt eigene Skripte, eigenes CSS (zusätzliche http-requests), 17 Datentabellen und eine Menge Queries mit sich (in einem Kurztest waren es ohne WPML 40 Queries in 28.5 MS, mit WPML 100 Queries in 45.6 MS), was sich unvermeidlich auf die Performance auswirkt.

In den Einstellungen hat man die Wahl zwischen Sprach-Parameter, Verzeichnisstruktur und Subdomain.

Praktisch jedes WordPress-API verwendendende Theme oder Plugin wird mit WPML mehrsprachenfähig. Mit breiter Kompatibilität zu zahlreichen Themes und Plugins darf also gerechnet werden.

Für überschaubare Projekte die ansonsten wenig pluginbeladen sind, stellt WPML eine bewährte und weitgehend intuitiv bedienbare Gesamtlösung dar. Vor allem hat man damit eine umfassende Lösung die alles berücksichtigt was man sich von einem Multilingual-System erwarten kann, bis hin zur Übersetzung des verwendeten Themes.

Freies Plugin: qTranslate (zwischenzeitlich nicht mehr verwendebar!)

Obwohl es nicht meine erste Wahl wäre, bin ich von diesem Plugin beeindruckt. Nicht nur die Art der Lösung finde ich reizvoll (gettext), sondern dass ein (meines Wissens) einzelner Entwickler bereits seit 2008 an diesem Plugin arbeitet und es fortlaufend pflegt.

Die Eigenheit von qTranslate ist, dass jede Sprachversion eines Posts dort gespeichert wird, wo bereits das Original liegt. Das verhindert jedoch nicht, dass ein Bild für jede Sprachversion eines Posts extra eingefügt werden muss (gilt nicht für das Artikelbild, dessen Anzeige über das Template veranlasst wird).

Jede Sprachversion wird von einem Language-Tag umgeben. Je nach gewählter Sprache, sieht man nur den Inhalt des Tags mit ihrer Sprachauszeichnung. Das funktioniert jedoch nur so lange das Plugin aktiv ist. Würde man es deaktivieren, hätte man alle Sprachversionen eines Posts auf einmal vor sich.

Was mich an qTranslate störte war, dass es nach jedem WordPress-Upgrade ausfiel (da die “richtige” WordPress-Version eine Bedingung war, dass das Plugin lief), und man dann entweder den Code modifzieren musste, oder vor der Aktualisierung von WordPress auf ein Update des Plugins warten. Metadaten wurden außerdem nicht übersetzt, dafür war ein eigenes Plugin erforderlich. Die Lösung war zwar umfangreich, aber nicht vollständig. Worin sich qTranslate nicht einhakte, musste manuell mit Sprachtags nachgezogen werden.

Freies Plugin: Polylang

Vor langer Zeit mal angesehen und beinahe vergessen hatte ich dieses Plugin. Für ein kleines Projekt würde ich es als Alternative zu WPML in Betracht ziehen, zumal es mir deutlich schlanker vorkommt. Polylang verfügt über einen eigenen Bereich um Blogtitel und Slogan sowie den Titel des Sprachumschalter-Widgets zu übersetzen.

Bei der Positionierung von Widgets steht zur Auswahl diese für eine Sprache oder alle zu verwenden. Auf diese Weise können mehrere Instanzen von Widgets angelegt und die Titel gleich vor Ort für die jeweilige Sprachversion übersetzt werden.

Nach Aktivierung des Plugins in einer bestehenden Site empfiehlt es sich, zuerst jene Sprache hinzuzufügen in der ggf. bereits Inhalte vorliegen, sie zur Standardsprache zu machen und vorhandene Inhalte dieser zuzuordnen.

Bei benutzerdefinierten Menüs führt die Einstellung “Neue Seiten der ersten Ebene automatisch zum Menü hinzufügen” zu einem sprachvermischten Menü (korrigierbar, diese Einträge einfach aus dem Menü entfernen und automatisches Hinzufügen abschalten). Für jede Sprache steht jedoch eine eigene Theme-Location zur Verfügung, und kann so ein eigenes Menü zusammengestellt werden (die richtige Sprache oder “Alle Sprachen” muss dafür ausgewählt sein). – Im Standardemnü werden Seiten und Übersetzungen automatisch am jeweils richtigen Ort platziert.

Wer sich mit einer Übersetzung vertan hat wird erfreut sein, dass auch eine nachträgliche Änderung der Zuordnung Seiten zu Übersetzungen zu den Features gehört.

Anderssprachgie Seiten und Artikel werden in eigenen Posts abgespeichert. Nach der Deaktivierung des Plugins bleibt man auf einer gemischtsprachigen Site sitzen, aber keiner neuen Tabelle. Nicht mehr benötigte anderssprachige Posts vor der Deaktivierung auf Privat oder Entwurf umzustellen ist allerdings mittels WordPress-eigener Stapelverarbeitung schnell vollbracht.

Vorteile einer Standalone-Lösung

  • Alle Sprachen befinden sich unter einer zentralen Verwaltung
  • Von der Sprachversion einer Seite zu einer ihrer Übersetzungen ist es nur ein Klick
  • Einmal hochgeladene Bilder stehen für alle Sprachversionen zur Verfügung

Nachteile einer Standalone-Lösung

  • Zum Teil signifikante Performance-Verluste
  • Invasiv und keine saubere Trennung der Sprachversionen
  • Hoher manueller Aufwand, wenn man sich für eine andere Lösung entscheiden möchte oder auf Mehrsprachigkeit doch lieber wieder verzichten.

Multilingual Multisite

WordPress selbst kann Dank Lokalisierung in beliebigen Sprachen betrieben werden. Eine Unterseite in einer WordPress-Multisite-Umgebung auch. So lässt es sich einrichten, auf einer Installation eine Site in englischer Sprache zu betreiben, eine andere hingegen auf Deutsch.

WordPress Multisite – eine eigene Site für jede Sprache

In einer Multisite-Umgebung ist jede Sprachversion eine eigene Site mit eigenen Datentabellen. Will man eine Sprache loswerden, löscht man die Site. Benötigt man eine zusätzliche Sprache, entsteht eine neue Site im Netzwerk mit einer entsprechenden (Sub-)-Domain.

Vorteile einer Multisite-Lösung

  • Funktioniert auf Basis nativer WordPress-Funktionalität und läuft daher ohne Performance-Einbußen
  • Inhalte jeder Sprache in eigenen Tabellen
  • Jede Sprachversion ist eine unabhängige Website-Instanz und kann entsprechend frei gestaltet werden (eigene Plugins, eigene User, eigene Widgets, eigenes Theme, eigene Inhaltsstruktur…)
  • Rückstandsfreies Löschen einer oder aller zusätzlicher Sprachen
  • Mehrsprachigkeit bleibt unabhängig von irgendeinem Plugin bestehen

Möglicherweise Nachteile einer Multisite-Installation

  • Jede Sprachversion hat ihr eigenes Dashboard und muss separat konfiguriert werden (z.B. Wahl des Themes, Positionierung von Widgets)
  • Jede Site nutzt ihre eigene Mediathek, d.h. ein -und dasselbe Bild muss für jede Übersetzung neu hochgeladen werden, dafür sind allerdings dann auch die Dateinamen übersetzt (wofür man auch in der Standalone-Lösung so viele Bildversionen wie Sprachen bräuchte).
  • Höherer Einrichtungs- und Verwaltungsaufwand

Plugins für Multilingual Multisites

*) Wer Custom Posts über ein Plugin erzeugen lässt müsste dies dann für jede Sprachversion tun. Ich schreibe hierfür individuelle Plugins in denen Custom Post Types, Taxonomies und Metaboxen mit Custom Fields angelegt werden. Netzwerkweit aktiviert stehen Custom Post Types und Taxonomies auf jeder Site zur Verfügung und müssen nicht in jeder Sprachversion neu aktiviert werden.

Für Kategorien, Schlagwörter und Taxonomy-Terms ist mit Multisite Language Switcher gesorgt.
Den Slug eines Posttypes bekommt man so übersetzbar:
$slug = __('mypostslug', 'mytextdomain');
'rewrite' => array( 'slug' => $slug );

Achtung: spätere Änderungen an den Sprachkatalogen können zu 404-Fehlern führen, wenn man versehentlich den Slug neu übersetzt.

Multisite Language Switcher wird zwar netzwerkweit aktiviert, muss dann jedoch für jede Sprachversion extra konfiguriert werden. Multisite Language Switcher macht einem das ein wenig einfacher, indem man auch in den Einstellungen mit nur einem Klick von einer Sprachversion zur nächsten navigieren kann. Nicht jede Site muss automatisch eine eigene Sprachversion sein, sondern kann auch unabhängig von den Sprachversionen laufen.

Multisite Language Switcher
Multisite Language Switcher wechselt zur gewählten Übersetzung (Klick auf Fähnchen)

Für jedes Post wird individuell festgelegt ob man dafür eine Übersetzung vorsehen möchte oder nicht. Über die getroffene Auswahl werden die Posts miteinander verbunden, und es kann zwischen Original und Übersetzungen navigiert werden. Multisite Language Switcher lässt es auch zu, eine einmal hergestellte Verknüpfung zu ändern oder aufzuheben. Als Übersetzungsversion verknüpfbar sind sowohl neue als auch bereits bestehende Seiten.

Welche Lösung für ein Projekt und seine Redakteure geeignet ist, hängt von so vielen Details ab, dass ich nicht generell von einer “besten Lösung” ausgehe, auch wenn meine bevorzugte Lösung ganz klar in Richtung Multisite mit Multisite Language Switcher geht. Je eigenständiger die einzelnen Sprachversionen sein dürfen (oder sollen), umso stärker empfiehlt sich eine Multisite-Variante.

Größere Projekte sehe ich generell sicherer mit einer Multisite-Lösung realisiert.

weiter schmökern

Schreibe einen Kommentar

Bitte Kommentarfunktion nicht für Supportanfragen nutzen. Dem kann hier nicht entsprochen werden.

Deine E-Mail-Adresse wird nicht veröffentlicht.