WordPress Language: Die einsprachige Sprachkonfiguration richtig einstellen
Erfahren Sie, wie Site Language, Backend-Sprache, Sprachdateien und html-lang zusammenspielen und wie Sie Fehler in Single Site und Multisite beheben.
Wenn eine WordPress-Website plötzlich in der falschen Sprache erscheint oder sich das Backend anders verhält als das Frontend, liegt das selten an einem einzigen defekten Schalter. Das System kennt mehrere unabhängige Sprachebenen, die sich gegenseitig überlagern. Zu diesen Ebenen gehören die generelle Sprache der Website, die persönliche Sprache eines jeden Benutzerkontos, die Übersetzungsdateien von Themes und Plugins sowie das Sprachattribut im HTML-Quelltext. Wer den Zweck der einzelnen Ebenen verstanden hat, findet die Ursache für Sprachprobleme in wenigen Minuten, statt durch blindes Ausprobieren Zeit zu verlieren.
Die vier Ebenen der WordPress-Sprache im Überblick
Sprache der Website. Diese Ebene bestimmt, in welcher Sprache das Frontend und die Standardtexte von WordPress ausgegeben werden. Dazu gehören Datumsformate, Bezeichnungen wie “Weiterlesen” oder Beschriftungen von Standardformularen. Das ist die Sicht, die ein normaler Besucher der Website erhält.
Benutzersprache. Jedes angelegte Konto kann das Backend in einer eigenen Sprache anzeigen lassen. Ein englischsprachiger Entwickler arbeitet so in einem englischen Dashboard, während die Website für die Besucher weiterhin auf Deutsch erscheint. Diese Einstellung wirkt sich ausschließlich auf die Administrationsoberfläche aus.
Theme- und Plugin-Übersetzungen. Der WordPress-Kern ist vollständig übersetzt. Themes und Plugins sind jedoch nur so weit in anderen Sprachen verfügbar, wie ihre Entwickler und die Community sie übersetzt haben. Fehlt ein passendes Sprachpaket, bleiben einzelne Beschriftungen englisch, obwohl die Website korrekt konfiguriert ist.
Das Sprachattribut im HTML. Im Quelltext steht im einleitenden <html>-Tag eine Sprachkennzeichnung, die Suchmaschinen und Screenreader auswerten. Sie wird direkt von der eingestellten Sprache der Website gespeist.
Die Sprachkonfiguration direkt im Dashboard setzen
Der Standardweg für die Konfiguration führt über das Backend. Die Sprache der Website wird im Backend unter Einstellungen > Allgemein > Sprache der Website gesetzt. Im englischsprachigen Dashboard lautet die Bezeichnung “Settings > General > Site Language”. Die Auswahlliste zeigt automatisch alle Sprachen an, für die ein offizielles Sprachpaket verfügbar ist. Ab WordPress 4.0 lassen sich diese Sprachdateien direkt aus dem Admin-Dashboard installieren. Sobald eine Sprache gespeichert wird, lädt das System die benötigten Dateien automatisch herunter. Ein manueller Datei-Upload per FTP ist dafür nicht mehr nötig.
Regelmäßig für Verwirrung sorgt die persönliche Backend-Sprache, da sie an einer völlig anderen Stelle liegt. Sie steht im eigenen Profil unter Benutzer im Feld “Sprache”. Steht dort die Option “Voreinstellung der Website”, übernimmt das Konto automatisch die allgemeine Einstellung. Wer an dieser Stelle eine abweichende Sprache wählt, ändert nur seine persönliche Ansicht und beeinflusst die Darstellung für die Besucher nicht.
Der alte Weg über die wp-config.php
Ältere Installationen und viele Anleitungen im Netz beschreiben einen anderen Weg zur Sprachfestlegung. In WordPress 3.9.2 und älter wurde die Sprache stattdessen über die Konstante WPLANG in der Datei wp-config.php gesetzt. Dazu gehörte das manuelle Hochladen einer .mo-Datei in das Verzeichnis wp-content/languages. In aktuellen Installationen ist diese Konstante überflüssig, weil die komfortable Dashboard-Einstellung sie vollständig ersetzt.
Praktisch relevant bleibt ein Blick in die wp-config.php dennoch in zwei Fällen. Erstens bei gewachsenen Projekten, in denen noch eine alte WPLANG-Zeile in der Konfiguration steht und niemand mehr weiß, warum dies so ist. Zweitens bei Installationen, die per Skript oder Deployment ausgerollt werden und deren Sprache schon vor dem ersten Login feststehen soll. In beiden Fällen gehört die Prüfung der wp-config.php zur Fehlersuche dazu, bevor andere Einstellungen umgestellt werden.
Sprachfestlegung in WordPress Multisite
Für Multisite-Installationen dokumentiert WordPress ein eigenes Vorgehen zur Sprachfestlegung, getrennt von Single-Site-Installationen. Der Hintergrund ist eine zusätzliche Ebene: Das Netzwerk besitzt eine eigene Standardsprache, die für alle neu angelegten Websites gilt. Jede einzelne Website im Netzwerk kann jedoch eigenständig davon abweichen. Wer nur die Einstellung einer bestehenden Unterseite ändert, beeinflusst nicht die Sprachen der Sites, die später hinzukommen. Umgekehrt wirkt eine geänderte Netzwerksprache nicht rückwirkend auf bereits bestehende Sites innerhalb des Netzwerks.
Woher die Übersetzungen kommen und wie man Fehler eingrenzt
Übersetzungen für den WordPress-Core, für Themes und für Plugins werden zentral über die Plattform translate.wordpress.org gepflegt. Diese auf GlotPress basierende Übersetzungsplattform der Community stellt die Sprachpakete zentral zur Verfügung. Deshalb erscheinen nach einem Sprachwechsel der Kern und viele verbreitete Erweiterungen sofort in der gewünschten Sprache, während kommerzielle oder wenig genutzte Plugins weiterhin englisch bleiben können.
Bleiben einzelne Texte unübersetzt, hilft eine schrittweise Eingrenzung des Problems. Betrifft es die Standardtexte von WordPress selbst, ist das Sprachpaket möglicherweise unvollständig installiert oder wurde durch ein Update überschrieben. Betrifft es nur Elemente eines bestimmten Plugins oder Themes, fehlt schlichtweg dessen Übersetzung. Und wenn die Texte fest im Theme-Code stehen, statt über die WordPress-Übersetzungsfunktionen ausgegeben zu werden, hilft keine Spracheinstellung der Welt. In diesem Fall hilft nur eine direkte Änderung im Theme-Code selbst.
Das html-lang-Attribut prüfen
Im Header eines intakten Themes steht üblicherweise die Template-Funktion language_attributes(). Sie gibt die Sprachattribute im <html>-Tag automatisch aus und wird von der eingestellten Website-Sprache gespeist. Ein schneller Test funktioniert so: Seite im Browser öffnen, den Quelltext anzeigen lassen und die erste Zeile nach dem <html>-Befehl prüfen. Steht dort eine andere Sprache als erwartet, ist entweder die Website-Sprache im Backend falsch gesetzt, oder das Theme schreibt einen festen Wert in den Header, anstatt die WordPress-Funktion zu verwenden. Das Attribut ist keine reine Kosmetik. Suchmaschinen und Vorlesewerkzeuge für blinde Nutzer nutzen es zwingend, um die Sprache eines Dokuments zu bestimmen.
Wann die eingebaute Sprachsteuerung an ihre Grenzen stößt
Die Sprachsteuerung von WordPress ist bewusst einsprachig aufgebaut. Sie beantwortet die Frage, in welcher Sprache eine Website existiert, und nicht die Frage, in welchen Sprachen es diesen Inhalt zusätzlich gibt. Es gibt drei ziemlich eindeutige Anzeichen dafür, dass der eingebaute Weg nicht mehr ausreicht:
- Derselbe Inhalt soll parallel in mehreren Sprachen erreichbar sein, jeweils unter einer eigenen URL.
- Besucher sollen aktiv zwischen Sprachversionen wechseln können, und die Navigation soll dabei in der passenden Sprache mitwandern.
- Suchmaschinen sollen die verschiedenen Sprachversionen einander korrekt zuordnen. Das setzt hreflang-Tags und eine bewusst gewählte URL-Struktur voraus, also eine eigene Top-Level-Domain, eine Subdomain oder ein Unterverzeichnis.
Sobald einer dieser Punkte zutrifft, geht es nicht mehr um eine simple Einstellung im Backend, sondern um eine funktionale Erweiterung. Diesen Bereich decken Mehrsprachigkeits-Plugins ab. WPML positioniert sich dabei als meistgenutztes Plugin für Mehrsprachigkeit und deckt unter anderem komplexe WooCommerce-Shops ab. Polylang wird als kostenlose Alternative beschrieben, um eine kleinere mehrsprachige WordPress-Website aufzusetzen. Ein Sonderfall ist das Plugin Easy Language. Es stellt Seiten und Beiträge zusätzlich in Einfacher oder Leichter Sprache dar, manuell oder per KI, und beantwortet damit eher eine Frage der Barrierefreiheit als der klassischen Fremdsprachigkeit.
Für alles darunter gilt: Sprache der Website prüfen, Benutzersprache prüfen, Übersetzungspakete prüfen und das HTML-Attribut prüfen. Diese vier Blicke erklären die meisten Sprachprobleme in einer einsprachigen WordPress-Installation zuverlässig.
