Eine Website in mehreren Sprachen öffnet neue Märkte. Vielleicht betreuen Sie Kunden im Ausland, haben Standorte in mehreren Ländern oder wollen über den eigenen Sprachraum hinaus wachsen. Mit jeder zusätzlichen Sprache erreichen Sie mehr Menschen. Denn man kauft bei Unternehmen, die man versteht. Dasselbe gilt für Partnerschaften und Bewerbungen.
Bei uns selbst war das nicht anders. Unsere Website gab es lange nur auf Deutsch. Entsprechend kamen unsere Kunden fast ausschließlich aus Österreich und Deutschland. Vor einigen Jahren haben wir sämtliche Inhalte ins Englische übersetzt. Seitdem melden sich Interessenten bei uns, die uns vorher nie gefunden hätten. Einige davon sind heute Kunden.
Eine zweite Sprache ist kein Schalter
Mehrsprachigkeit klingt nach einer Funktion, die man einfach aktiviert. Tatsächlich ist jede weitere Sprache ein zweiter Bestand an Inhalten, den jemand schreiben, übersetzen, prüfen und aktuell halten muss. Wird die deutsche Seite laufend aktualisiert, die englische aber seit Jahren nicht mehr, schadet das unter Umständen mehr als gar keine englische Version zu haben. Internationale Besucher merken schnell, dass sie nicht ernst genommen werden.
Bevor Sie also eine weitere Sprache einplanen, sollte klar sein, wer diese Inhalte dauerhaft pflegt. Automatische Übersetzung und KI liefern inzwischen brauchbare erste Entwürfe. Gegenlesen und korrigieren muss sie unserer Erfahrung nach aber trotzdem ein Mensch, und zwar in jeder Sprache.
Steht die Entscheidung für Mehrsprachigkeit, kommt die Technik. Wer bereits ein CMS einsetzt, greift in der Regel zu dem, was dieses System mitbringt oder was es dafür an Erweiterungen gibt. Wer neu startet, kann sich das System aussuchen, das am wenigsten Kopfzerbrechen bereitet. In diesem Beitrag sehe ich mir drei Systeme genauer an: WordPress, ProcessWire und Statamic.
WordPress: Mehrsprachigkeit über Umwege
Von Haus aus spricht WordPress nur eine einzelne Sprache. Das hat historische Gründe: WordPress begann als schlichte Blogsoftware, und ein privater Blog wird nun einmal meist in einer Sprache geschrieben. Alles selbst zu übersetzen und doppelt zu pflegen, wäre für viele Blogger schlicht zu viel Aufwand. Inzwischen ist aus WordPress aber ein umfangreiches CMS geworden, das weit mehr als Blogs antreibt. Der Kern ist jedoch erstaunlich unverändert geblieben.
Mehrsprachigkeit im Core steht seit Jahren auf der Roadmap des WordPress-Projekts, offensichtlich aber nicht weit oben. Wer die Datenbankstruktur von WordPress kennt, ahnt auch, warum: Die Aufgabe ist alles andere als klein. Selbst das Team hinter WooCommerce, dem wichtigsten Shop-Plugin für WordPress, wollte sich irgendwann nicht mehr mit den bestehenden Tabellen herumschlagen. Es hat kurzerhand eigene angelegt.
Die Lücke füllen Plugins. Die beiden großen sind WPML (WordPress Multilingual) und Polylang.
WPML und Polylang
WPML ist das ältere und umfangreichere der beiden. Das Plugin ist kostenpflichtig und wird jährlich lizenziert. Dafür bekommt man ein komplettes Paket: WPML übersetzt Beiträge, Seiten, Menüs, Widgets und Theme-Texte. Ein eigenes Dashboard hilft, die Arbeit von Übersetzern zu koordinieren, und auf Wunsch lassen sich professionelle Übersetzungsdienste anbinden. Über ein eigenes Add-on arbeitet WPML auch gut mit WooCommerce zusammen – für Shops ein wichtiger Punkt.
Der Preis für diesen Funktionsumfang ist technischer Overhead. WPML legt eigene Datenbanktabellen an und erzeugt bei jedem Seitenaufruf zusätzlichen Rechenaufwand. Auf größeren Websites spürt man das im Backend deutlich und mehr Serverleistung ist gefragt.
Polylang ist schlanker aufgestellt. Das Basis-Plugin ist kostenlos und verknüpft Übersetzungen über das WordPress-eigene Taxonomie-System, statt eine separate Struktur danebenzustellen. Damit bleibt es näher an der Arbeitsweise von WordPress.
Für eine typische Unternehmenswebsite mit Seiten, Beiträgen und ein, zwei Menüs reicht die Gratisversion oft völlig aus. Übersetzbare URL-Slugs, das Duplizieren von Inhalten oder WooCommerce-Unterstützung gibt es allerdings nur mit Polylang Pro oder über Add-ons. Je mehr man braucht, desto kleiner wird also der Preisunterschied zu WPML.
Eine grundsätzliche Einschränkung haben beide gemeinsam. Sie liegt nicht an den Plugins, sondern an WordPress selbst: Jede Übersetzung wird als eigener Beitrag gespeichert und mit dem Original lediglich verknüpft. Für WordPress sind die deutsche und die englische „Über uns“-Seite zwei voneinander unabhängige Seiten.
Das funktioniert, hat aber Folgen. Bilder, benutzerdefinierte Felder oder Page-Builder-Layouts müssen oft für jede Sprache eigens angelegt oder synchronisiert werden. Dabei laufen die Versionen leicht auseinander. Beide Plugins arbeiten nach unserer Erfahrung zuverlässig. Dass Mehrsprachigkeit im ursprünglichen Konzept von WordPress nie vorgesehen war, können aber beide nicht ganz verbergen.
Andere Lösungen in WordPress
Das Theme Enfold eignet sich gut als Grundlage für individuelle WordPress-Designs. Ab Version 8, derzeit noch in der Closed Beta, bringt es Mehrsprachigkeit direkt mit. Wer ohnehin mit Enfold arbeitet, kann so ohne zusätzliches Plugin weitere Sprachen ergänzen. Enfold ist ausgereift und wird gut gepflegt, damit ist es für uns eine solide Alternative zu den Plugins.
Wer eine möglichst WordPress-eigene Lösung sucht, kann außerdem auf Multisite zurückgreifen. Damit lassen sich mehrere Websites über ein gemeinsames Backend betreiben: Themes und Plugins werden geteilt, die Inhalte bleiben getrennt. Das bietet sich an, wenn es eigene Websites für verschiedene Länder und Sprachen geben soll. Die Inhalte entwickeln sich dann allerdings unabhängig voneinander.
ProcessWire: Mehrsprachigkeit ab Werk
ProcessWire ist ein ausgereiftes CMS, das vor allem technisch versierte Leute anspricht, die gern selbst Hand anlegen. Mehr dazu haben wir in einem früheren Beitrag geschrieben. Fertige Themes gibt es keine, jede Website entsteht von Grund auf. Wer aber eine schlanke, maßgeschneiderte Website mit wirklich guter Mehrsprachigkeit will, ist hier richtig.
Anders als bei WordPress gehört die Sprachunterstützung zum Kern: ein paar Module, die man nur aktivieren muss. Sind die Sprachen angelegt, bekommt jedes Feld, das übersetzbar sein soll, einen mehrsprachigen Feldtyp. Im Editor bekommen diese Felder einen Reiter pro Sprache. Deutsche und englische Fassung stehen also direkt nebeneinander auf derselben Seite.
Jede Sprache bekommt ein eigenes URL-Präfix, etwa /en/ für Englisch und /de/ für Deutsch. Festgelegt wird es beim Anlegen der Sprache in den Einstellungen. Das lässt sich frei anpassen, die Standardsprache kommt meist ganz ohne Präfix aus. Einen Sprachumschalter bringt ProcessWire nicht mit. Die Dokumentation liefert aber Beispiele, die sich leicht in Navigation oder Footer einbauen lassen.
Hier liegt der größte Unterschied zu den WordPress-Plugins. Eine übersetzte Seite ist keine eigene, verknüpfte Seite, sondern ein und dieselbe Seite mit Inhalten in mehreren Sprachen. Bilder, Datumsangaben oder Verweise auf andere Seiten brauchen keine Übersetzung. Solche Felder werden einmal befüllt und gelten für alle Sprachen. Es gibt schlicht nichts, das synchron gehalten werden müsste. Damit fällt eine der häufigsten Ursachen für auseinanderlaufende Inhalte weg.
Auch mit Lücken geht ProcessWire vernünftig um. Ist ein Feld in einer Sprache leer, springt die Standardsprache ein. Statt eines Lochs im Layout sieht der Besucher dann eben einen deutschen Absatz auf einer sonst englischen Seite. Das ist so gewollt. Wer unübersetzte Inhalte lieber gar nicht zeigen will, kann eine Seite für einzelne Sprachen deaktivieren. Sie ist dann auf Englisch nicht erreichbar und taucht in dieser Sprache weder in der Navigation noch in der Suche auf.
Statamic: Kontrolle bis aufs einzelne Feld
Wenn Ihnen gute Unterstützung für Entwickler, eine angenehme Bedienung, Geschwindigkeit und Zuverlässigkeit wichtig sind, ist Statamic für viele Projekte die beste Wahl. Es basiert auf Laravel, einem der meistgenutzten PHP-Frameworks. Entwickler können Statamic also mit denselben Werkzeugen erweitern, die sie auch für individuelle Webanwendungen verwenden.
Mehrsprachigkeit löst Statamic über seine Multisite-Funktion. Die ist allerdings Teil der Pro-Lizenz und nicht in der kostenlosen Version enthalten. Die Lizenz ist aber durchaus leistbar, vor allem verglichen mit der Zeit, die sonst in die Pflege von Plugins fließt.
Mit Multisite in WordPress hat das wenig zu tun. Dort sind die Websites eines Netzwerks weitgehend eigenständig, ihre Inhalte stehen in keiner echten Beziehung zueinander. In Statamic sind die Sites deutlich enger gekoppelt. Jede Sprache ist eine eigene Site mit eigenem URL-Präfix wie bei ProcessWire, auf Wunsch auch mit eigener Domain. Jeder Eintrag hat pro Sprache eine Lokalisierung, die mit dem Original verbunden bleibt. Die deutsche Seite weiß, dass sie die Übersetzung der englischen ist, und Statamic behält diese Beziehung im Blick.
Für Teams entscheidend ist die Steuerung auf Feldebene. Eine neue deutsche Lokalisierung ist zunächst mit dem englischen Original synchronisiert: Jedes Feld zeigt den Originalinhalt, bis jemand es ändert. Sobald ein Feld bearbeitet wurde, gilt es als übersetzt und folgt dem Original nicht mehr. Manche Felder dürfen in keiner Sprache abweichen, etwa die Koordinaten eines Standorts oder das Veröffentlichungsdatum einer News. Sie lassen sich als nicht lokalisierbar markieren, werden dann einmal im Original gepflegt und können in den Übersetzungen nicht verändert werden.
Diese Einstellungen stecken in den Blueprints, die jeden Inhaltstyp definieren. Ein Entwickler richtet sie einmal ein, die Redaktion muss sich darum nicht mehr kümmern. Ebenso lässt sich festlegen, ob neue Einträge automatisch in allen Sprachen angelegt werden oder erst, wenn jemand eine Übersetzung erstellt. Das ist praktisch, wenn nicht alle Inhalte übersetzt werden müssen.
Auch Berechtigungen lassen sich pro Sprache vergeben. Die Redakteurin für Deutsch bekommt nur Zugriff auf die deutsche Site, der Texter für Englisch nur auf die englische. Wer mit externen Übersetzern zusammenarbeitet, hat damit einen echten Vorteil: Niemand kann versehentlich Inhalte in einer Sprache überschreiben, für die er nicht zuständig ist.
Statamic verbindet damit die strukturelle Trennung von WordPress Multisite mit dem eng verzahnten Ansatz von ProcessWire. Dazu kommen die redaktionellen Kontrollmöglichkeiten, die größere Teams brauchen.
Welches System passt zu Ihrer mehrsprachigen Website?
Das eine beste System für mehrsprachige Websites gibt es nicht. Es gibt nur das, das zu Ihren Inhalten, Ihrem Team und Ihren Plänen passt.
Läuft Ihre Website bereits auf WordPress und hält sich die Menge an Inhalten in zwei Sprachen in Grenzen, spricht wenig für einen Wechsel. WPML oder Polylang machen ihre Sache zuverlässig. Sie sollten nur von Anfang an einplanen, dass jede Übersetzung eine eigene Seite ist, und Ihre Abläufe danach ausrichten.
Starten Sie neu und soll jede Seite alle Sprachen an einem Ort bündeln, lohnt sich ein genauerer Blick auf ProcessWire. Es passt zu Teams, die ein wenig Technik nicht scheuen und Wert auf eine unkomplizierte Bearbeitung legen.
Soll Ihre Website wachsen, an Sprachen, an Redakteuren oder an Komplexität, bietet Statamic den meisten Spielraum. Steuerung auf Feldebene, Rechte pro Sprache und das solide Laravel-Fundament machen es besonders interessant, wenn sich mehrere Leute oder externe Übersetzer die Arbeit teilen.
Welches System es auch wird: Die wichtigste Frage ist keine technische. Wer kümmert sich um die zweite Sprache, wenn die Website online ist? Und um die dritte und vierte? Jede weitere Sprache ist ein zusätzlicher Bestand an Inhalten, der geschrieben, geprüft und aktuell gehalten werden muss. Das richtige CMS erleichtert diese Arbeit erheblich, abnehmen kann es sie Ihnen nicht.
Sie planen eine mehrsprachige Website oder wollen eine bestehende um eine Sprache erweitern? Ob das passende Übersetzungs-Plugin für WordPress oder eine individuelle Lösung mit ProcessWire oder Statamic: Wir besprechen das gern mit Ihnen. Nehmen Sie Kontakt mit uns auf.
