Text-zu-Sprache für Polylang-Websites: Was wirklich funktioniert

13 Min. lesen 25 Min. anhören
Text-zu-Sprache für Polylang-Websites: Was wirklich funktioniert

Text-zu-Sprache mit Polylang bedeutet: eine Audiodatei pro übersetztem Beitrag, in der richtigen Sprache und mit der richtigen Stimme. Da Polylang jede Übersetzung als eigenständigen WordPress-Beitrag mit eigener ID speichert, funktioniert die beitragsbasierte Audiogenerierung von Haus aus. Die eigentlichen Stolperfallen sind Stimmauswahl, Cookie-Weiterleitungen und Seiten-Caching, nicht die Audiodatei selbst.

Dies ist der vierte Beitrag unserer mehrsprachigen TTS-Reihe. Wir haben bereits WPML, Weglot und das GTranslate-3.3.0-Release behandelt. Polylang ähnelt WPML in seiner Architektur am meisten, hat aber eigene Besonderheiten. Hier ist, was wir getestet haben und was auf Produktiv-Websites mit Text-zu-Sprache - TTSWP tatsächlich funktioniert.

Warum Polylang für Text-zu-Sprache relevant ist

Polylang betreibt mehr mehrsprachige WordPress-Websites als jedes andere kostenlose Plugin. Es verzeichnet über 800.000 aktive Installationen und ist damit die meistinstallierte kostenlose Lösung unter den mehrsprachigen Allzweck-Plugins. Die erste Version erschien 2011, und das Plugin wird bis heute aktiv gepflegt. Die Anzahl der Sprachen ist unbegrenzt, und WordPress-Sprachpakete werden automatisch heruntergeladen. Die meisten Polylang-Websites sind Blogs, kleine Verlage und budgetbewusste Agenturen, die das Plugin wegen seines kostenlosen Kerns und seiner sauberen Architektur gewählt haben.

Genau diese Verbreitung ist das Problem für TTS-Plugins. Viele behaupten, Polylang zu unterstützen, testen aber nur die Standardsprache. Sie hängen eine einzige Audiodatei an einen Beitrag und liefern dieselbe Datei für jede Übersetzung aus. Die spanische Version spielt englisches Audio. Die deutsche Version bleibt stumm. Besucher verlassen die Seite.

Die Lösung liegt in der Struktur. Polylang fügt keine zusätzlichen Datenbanktabellen und keine Shortcodes hinzu. Es baut auf WordPress-Taxonomien auf, demselben Kernmechanismus, der Kategorien und Tags antreibt. Jede Übersetzung ist ein echter Beitrag. Daher passt die beitragsbasierte Audiogenerierung, wie TTSWP sie umsetzt, perfekt zur Art, wie Polylang Inhalte speichert.

Wie sich Polylang von Weglot und GTranslate unterscheidet

Polylang dupliziert Beiträge. Weglot und GTranslate übersetzen beim Rendern. Dieser eine Unterschied entscheidet über alles, was TTS-Unterstützung ausmacht.

Auf einer Polylang-Website ist die deutsche Übersetzung von „Über uns” ein eigenständiger WordPress-Beitrag mit der Post-ID 412, dem Sprachkürzel „de” und eigenem Datenbankinhalt. WordPress erkennt ihn, die REST API erkennt ihn, und jedes TTS-Plugin, das sich in save_post oder wp_insert_post einhängt, erkennt ihn ebenfalls. Die Audiogenerierung läuft einmal pro Übersetzung, in der Sprache dieser Übersetzung, und die Datei wird gegen die jeweilige Post-ID gecacht.

Weglot und GTranslate funktionieren anders. Der übersetzte Text existiert nur dann, wenn ein Benutzer die Seite aufruft. Es gibt keinen zweiten Beitrag, an den Audio gehängt werden könnte. Die Workarounds für Weglot und GTranslate haben wir in früheren Beiträgen beschrieben. WPML verwendet dasselbe Duplikationsmodell wie Polylang, weshalb unser WPML-Leitfaden hier mit kleinen Anpassungen gilt.

Für Text-zu-Sprache ist das eine gute Nachricht. Polylang liefert genau das, was benötigt wird: eine stabile Post-ID pro Sprache, ein bekanntes Sprachkürzel und einen Permalink, der sich beim Rendern nicht ändert.

Diagramm, das die Beitragsduplizierung von Polylang mit der Übersetzung beim Rendern durch Weglot vergleicht
Polylang erstellt pro Sprache einen echten Beitrag, was genau der Voraussetzung für beitragsbasierte TTS-Generierung entspricht.

Die vier URL-Strukturen von Polylang und ihre Auswirkungen auf TTS

Polylang bietet vier URL-Modi. Jeder verändert, wie Caches, CDNs und Spracherkennungscode Ihre Seiten sehen. Der falsche Modus führt dazu, dass die richtige Audiodatei hinter der falschen URL landet.

1. Sprache nur aus dem Inhalt (kein Sprachkürzel in der URL)

Dies ist der schwierigste Fall. Die URL example.com/about liefert einem Besucher Englisch und einem anderen Deutsch, abhängig von Cookie oder Browser-Erkennung. Seiten-Caches sehen eine URL und speichern nur eine Variante. Welche Sprache der Cache zuerst erwischt hat, gewinnt.

Für TTS ist die Audiodatei selbst unproblematisch, da sie an die Post-ID gebunden ist, nicht an die URL. Das Problem ist die Seite, die den Player einbettet. Wenn die gecachte englische Seite mit dem deutschen Audio-Embed geladen wird, spielt der Player trotzdem Deutsch, aber die Besucher erwarteten englischen Text. Wir empfehlen diesen URL-Modus auf keiner gecachten Website.

2. Verzeichnis-URLs (/en/, /de/)

Dies ist die Standardeinstellung und die Konfiguration, die wir empfehlen. Jede Sprache hat ihren eigenen Pfad. Caches behandeln /en/about und /de/about als separate Schlüssel. Die richtige Seite lädt mit dem richtigen Player und der richtigen Audiodatei. Keine Cookie-Tricks nötig.

Beachten Sie die Option „URL-Sprachinformationen für die Standardsprache ausblenden”. Wenn aktiviert, entfällt das Präfix für die Standardsprache. /about wird zu Englisch und /de/about bleibt Deutsch. URL-basierte Spracherkennung in Drittanbieter-Code schlägt dann bei Standardsprachen-Pfaden fehl, weil kein Kürzel zu sehen ist. Wenn Sie diese Option nutzen, verlassen Sie sich lieber auf pll_current_language() statt auf URL-Parsing.

3. Subdomain (en.example.com, de.example.com)

Subdomains geben jeder Sprache einen eigenen Host und einen eigenen Cache-Namensraum. TTS-Player laden sauber pro Sprache. Der Preis ist DNS, SSL-Zertifikate pro Subdomain und etwas aufwändigeres Analytics. Skaliert gut bei größeren Projekten.

4. Separate Domain pro Sprache

Vollständige Trennung. example.com für Englisch, example.de für Deutsch. TTS bindet Audio weiterhin an die Post-ID innerhalb der jeweiligen WordPress-Installation, und der Player funktioniert auf dieselbe Weise. Dieser Modus ist üblich für Marken, die bereits ccTLDs besitzen.

Das Cookie-Weiterleitungs-Problem

Polylang kann beim ersten Besuch der Startseite die Browsersprache eines Besuchers erkennen. Dann setzt es das Cookie pll_language und leitet den Besucher zur passenden Sprachversion weiter. In Kombination mit Seiten-Caching entsteht hier das Problem mit falscher Audio-Sprache.

Hier ist die Fehlerabfolge, die wir reproduziert haben. Ein französischer Besucher landet auf der Startseite. Polylang erkennt Französisch, setzt das Cookie pll_language und leitet auf /fr/ weiter. Der Cache speichert diese Weiterleitungsantwort unter der Startseiten-URL. Der nächste Besucher, ein englischsprachiger Nutzer, ruft die Startseite auf und erhält die gecachte Weiterleitung zu /fr/. Er landet auf der französischen Seite, hört französisches Audio und verlässt die Seite.

Bei Verzeichnis-URLs bleibt der Schaden auf die Startseite begrenzt, weil alle anderen Seiten einen eigenen Cache-Schlüssel pro Sprache haben. Im Modus „Sprache nur aus dem Inhalt” breitet sich dasselbe Problem auf alle URLs der Website aus.

Drei Lösungen funktionieren. Die einfachste ist, die Browser-Spracherkennung auf gecachten Websites zu deaktivieren und Besuchern die Wahl per Sprachumschalter zu überlassen. Die zweite ist, Ihrem Cache-Plugin mitzuteilen, dass es auf das Cookie pll_language variieren oder es umgehen soll. Die dritte ist, die Startseite vom Seiten-Cache auszuschließen, damit die Erkennungs-Weiterleitung immer live ausgeführt wird.

Wenn Sie WP Rocket, W3 Total Cache oder LiteSpeed nutzen, lesen Sie unsere Caching-Integrationsdokumentation für die Cookie-Konfiguration. Polylang arbeitet mit diesen Cache-Plugins zusammen, aber Koexistenz bedeutet nicht automatisch Sprachbewusstsein. Die Cache-Konfiguration müssen Sie selbst vornehmen.

AJAX-Verhalten im Frontend

Polylang erkennt die aktuelle Sprache bei Frontend-AJAX-Anfragen automatisch und lädt Zeichenketten für diese Sprache. Sie können auch eine explizite Variable lang in der Anfrage übergeben, um eine bestimmte Sprache zu erzwingen. Für TTS ist das relevant, wenn der Audio-Player oder ein Widget für ähnliche Beiträge einen AJAX-Aufruf abfeuert, um einen anderen Beitrag zu laden.

In unseren Tests hat Polylang das sauber gelöst. Wir haben die AJAX-Sprachfehler, die wir im WPML-Beitrag dokumentiert haben, hier nicht beobachtet. Wenn eine benutzerdefinierte Integration einen Beitrag in einer nicht-aktuellen Sprache abrufen muss, übergeben Sie lang explizit und prüfen Sie mit function_exists('pll_current_language'), bevor Sie das Ergebnis auslesen.

Text-zu-Sprache - TTSWP auf einer Polylang-Website einrichten

Diese Schritte setzen voraus, dass Polylang bereits installiert ist und mindestens eine Übersetzung existiert.

  1. Text-zu-Sprache - TTSWP installieren über die WordPress.org-Plugin-Seite. Plugin aktivieren. Bei einem Berechtigungsfehler lesen Sie die Installationsdokumentation.
  2. Das Plugin mit TTSWP verbinden, indem Sie dem Verbindungsleitfaden folgen. Der kostenlose Plan enthält Startguthaben, damit Sie vor der Entscheidung für ein kostenpflichtiges Paket testen können.
  3. Den Beitrag in der Originalsprache öffnen und Audio generieren. Bestätigen Sie, dass der Player im Frontend erscheint.
  4. Zur übersetzten Version wechseln über den Polylang-Sprachumschalter im Beitragseditor. Audio erneut generieren. Polylang hat eine andere Post-ID geladen, daher behandelt TTSWP dies als neue Generierung und speichert eine separate Datei.
  5. Die Stimme für jede Übersetzung auswählen. Die Stimmauswahl erfolgt auf Beitragsebene. Lesen Sie die Dokumentation zur Stimmauswahl für die beitragsweise Überschreibung.
  6. Im Frontend überprüfen. Öffnen Sie /en/beitragsname und /de/beitragsname in verschiedenen Tabs. Beide abspielen. Stimmen und Sprachen sollten übereinstimmen.

Aktuell deckt die sprachspezifische Standard-Stimmzuweisung in TTSWP zunächst WPML und Weglot ab. Bei Polylang liegt die Stimmauswahl auf Beitragsebene, und die sprachspezifische Standardstimme greift über die unten beschriebene Beitragssprachen-Erkennung. Für die meisten Polylang-Websites reicht das aus, da jede Übersetzung ein echter Beitrag ist und die Stimme einmal pro Beitrag gesetzt wird. Aktuelle Details finden Sie in der Polylang-Integrationsdokumentation.

WordPress-Beitragseditor mit Polylang-Sprachumschalter und TTSWP-Audio-Panel nebeneinander
Jede Polylang-Übersetzung ist ein separater Beitrag, daher erfolgen Audiogenerierung und Stimmauswahl pro Übersetzung.

Wie die Stimmauswahl die Beitragssprache ermitteln sollte

Die korrekte API zum Auslesen der Sprache eines Beitrags in Polylang ist pll_get_post_language(). Prüfen Sie immer, ob die Funktion existiert, bevor Sie sie aufrufen, wie es die offizielle Polylang-Entwicklerdokumentation empfiehlt. Das Muster sieht so aus:

if ( function_exists( 'pll_get_post_language' ) ) {
    $lang = pll_get_post_language( $post_id, 'slug' );
    // $lang ist jetzt 'en', 'de', 'fr' usw.
}

Im Frontend-Kontext gibt pll_current_language() die Sprache der aktuellen Anfrage zurück. Beide Funktionen sind stabil und seit Jahren Teil der öffentlichen Polylang-API. Die Stimm-Mapping-Logik sollte immer die Beitragssprache auslesen, nie die Website-Standardsprache, sonst erben Übersetzungen die falsche Stimme.

Polylang Free vs. Polylang Pro für TTS

Für Audio ist nichts aus Polylang Pro erforderlich. Die kostenlose Version von Polylang bietet alles, was TTSWP braucht: beitragsweise Duplizierung, Sprachkürzel und die oben genannten öffentlichen API-Funktionen.

Polylang Pro fügt DeepL-Maschinenübersetzung, REST-API-Unterstützung, übersetzte URL-Slugs und XLIFF-Export für ausgelagerte Übersetzungsarbeit hinzu. Nichts davon ändert etwas an der TTS-Situation für Blogbeiträge und Seiten. Polylang für WooCommerce ist ein separates kostenpflichtiges Add-on, das Shop-Seiten, Produktkategorien, Attribute und transaktionale E-Mails verwaltet. Wenn Sie Vertonungen auf Produktbeschreibungen möchten, lesen Sie unseren WooCommerce-TTS-Leitfaden.

SEO und AEO mit Audio pro Sprache

Polylang verwaltet hreflang automatisch, was den Großteil der SEO-Arbeit für mehrsprachige Websites übernimmt. Fügen Sie AudioObject-Schema pro Sprachversion hinzu, verweisen Sie jede auf die Datei der jeweiligen Übersetzung, und Sie geben Suchmaschinen ein klares Signal.

In unseren eigenen Tests werden Artikel mit Audio und AudioObject-Schema häufiger von KI-Suchmaschinen zitiert. Die Methode und die Ergebnisse haben wir in unserem AEO-und-Audio-Beitrag dokumentiert. Kurz gefasst: eine Audiodatei pro Übersetzung, Schema pro Übersetzung, und der AEO-Vorteil folgt.

Häufige Probleme und Lösungen

SymptomWahrscheinliche UrsacheLösung
Übersetzung wird in der falschen Stimme abgespieltStimme global gesetzt, nicht pro BeitragÜbersetzten Beitrag öffnen, Stimme für diesen Beitrag setzen, neu generieren
Eine Sprache hat kein AudioAudio wurde für diese Übersetzung nie generiertÜbersetzten Beitrag im Editor öffnen, auf „Generieren” klicken
Gecachte Seite zeigt Player in falscher SpracheCache speichert die Erkennungs-Weiterleitung oder nur eine SeitenvarianteBrowser-Spracherkennung deaktivieren oder Cache auf das Cookie pll_language variieren lassen
Arabisches oder hebräisches Player-Layout sieht falsch ausRTL-CSS nicht auf den Player angewendetRTL-Überschreibungen über benutzerdefiniertes CSS hinzufügen
Player-UI-Texte bleiben in der StandardsprachePlugin-Zeichenketten nicht für Übersetzung registriertPlayer-Zeichenketten mit pll_register_string registrieren, damit Polylang sie im Zeichenketten-Übersetzungsbereich anzeigt
Audio wird für alle Beiträge in der Standardsprache generiertStimm-Mapping liest Website-Locale statt BeitragsspracheBeitragssprache über pll_get_post_language($post_id, 'slug') prüfen
Illustration von drei Sprachpfaden, jeweils mit eigenem Cache-Schlüssel und eigener Audiodatei, einschließlich RTL-Layout für Arabisch
Verzeichnis-URLs geben jeder Übersetzung einen eigenen Cache-Schlüssel und verhindern so, dass falsches Audio auf der falschen Seite landet.

Hinweis zur Barrierefreiheit

Vertonung pro Sprache ist auch ein Gewinn für die Barrierefreiheit. Besucher, die in ihrer Muttersprache besser lesen, aber lieber zuhören, bekommen jetzt beides. Wenn Ihre Website unter WCAG 2.2 oder den Europäischen Barrierefreiheitsanforderungen liegt, lesen Sie unseren WCAG-Audio-Compliance-Leitfaden für die relevanten Kriterien. Einen umfassenderen Überblick zum Hinzufügen von TTS in WordPress 2026 bietet das Haupt-Tutorial mit den grundlegenden Schritten.

Häufig gestellte Fragen

Funktioniert Polylang mit Text-zu-Sprache?

Ja. Polylang speichert jede Übersetzung als eigenständigen WordPress-Beitrag mit eigener ID, was genau der Architektur entspricht, die TTSWP für beitragsbasiertes Audio verwendet. Generieren Sie Audio für jede Übersetzung und Sie erhalten eine Datei pro Sprache mit der gewählten Stimme. Die kostenlose Version von Polylang reicht aus. Es ist keine besondere Konfiguration über die Standard-TTSWP-Einrichtung hinaus erforderlich.

Benötige ich Polylang Pro für Audio?

Nein. Die kostenlose Version von Polylang stellt alles bereit, was TTSWP braucht: sprachspezifische Beitragsduplizierung, Sprachkürzel und die öffentlichen API-Funktionen pll_get_post_language() und pll_current_language(). Polylang Pro fügt DeepL-Maschinenübersetzung, REST-API-Unterstützung und übersetzte URL-Slugs hinzu. Nichts davon ändert, wie Audiogenerierung oder -wiedergabe funktioniert.

Kann jede Sprache eine eigene Stimme haben?

Ja. Da jede Übersetzung ein separater Beitrag ist, erfolgt die Stimmauswahl auf Beitragsebene. Wählen Sie für die deutsche Übersetzung eine deutsche Stimme, für die spanische Übersetzung eine spanische Stimme und so weiter. TTSWP speichert die Auswahl pro Beitrag und verwendet sie bei jeder erneuten Generierung. Aktuelle Details finden Sie in der Dokumentation zur Sprach- und Stimmzuweisung.

Warum wird mein Audio in der falschen Sprache abgespielt?

Der häufigste Grund ist Seiten-Caching in Kombination mit der Browser-Spracherkennung von Polylang. Der Cache speichert die Startseiten-Weiterleitung oder eine einzige Sprachvariante und liefert sie an alle Besucher aus. Die Audiodatei selbst ist korrekt für die Post-ID. Die Seite, die sie lädt, ist es nicht. Deaktivieren Sie die Browser-Erkennung auf gecachten Websites oder konfigurieren Sie Ihr Cache-Plugin so, dass es auf das Cookie pll_language variiert. Verzeichnis-URLs (/en/, /de/) begrenzen den Schaden auf die Startseite, weil alle anderen Seiten einen eigenen Cache-Schlüssel haben.

Wie unterscheidet sich Polylang von WPML für TTS?

Beide duplizieren Beiträge pro Sprache, daher funktioniert beitragsbasiertes Audio auf beiden gleich. Die Unterschiede liegen im AJAX-Handling, im Cookie-Verhalten und in den Entwickler-API-Namen. Polylang nutzt Funktionen mit dem Präfix pll_ und ist generell schlanker. WPML hat mehr integrierte WooCommerce-Funktionen, aber einen größeren Plugin-Fußabdruck. Unser WPML-Beitrag deckt diese Seite ab.

Kann ich die Player-Beschriftungen übersetzen?

Ja, mit einem zusätzlichen Schritt. Polylang stellt einen Zeichenketten-Übersetzungsbereich für Plugins bereit, die ihre UI-Zeichenketten mit pll_register_string() registrieren. Wenn der Play-Button, die Zeitanzeige oder andere Player-Texte mit der Sprache wechseln sollen, registrieren Sie diese Zeichenketten in Ihrem Child-Theme oder einem kleinen website-spezifischen Plugin. Sie erscheinen dann unter Sprachen, Zeichenketten-Übersetzungen.

Nächste Schritte

Öffnen Sie einen Ihrer übersetzten Beiträge im WordPress-Editor und schauen Sie sich das Audio-Panel an. Wenn es bereits die richtige Sprache anzeigt, ist die Einrichtung abgeschlossen. Falls nicht, setzen Sie die Stimme für diese Übersetzung, generieren Sie neu und prüfen Sie das Frontend. Sobald eine Übersetzung funktioniert, folgen alle anderen demselben Muster.

Wenn Sie Text-zu-Sprache - TTSWP noch nicht installiert haben, laden Sie es von WordPress.org herunter und verbinden Sie es mit Ihrem kostenlosen TTSWP-Konto. Testen Sie mit einer Übersetzung, hören Sie sich das Ergebnis an und entscheiden Sie, ob Sie es auf alle anderen ausrollen möchten.