Text-zu-Sprache mit TranslatePress: Was funktioniert

11 Min. lesen 22 Min. anhören
Text-zu-Sprache mit TranslatePress: Was funktioniert

TranslatePress übersetzt das gerenderte HTML einer Seite zur Laufzeit und speichert alle Übersetzungen in lokalen Datenbanktabellen. Es gibt eine einzige Beitrags-ID pro Artikel, und der Sprachwechsel erfolgt über trp_translate(), nicht durch duplizierte Beiträge. Genau das verändert, wie Text-zu-Sprache auf einer TranslatePress-Website funktionieren muss.

Dies ist der fünfte und letzte Beitrag unserer Reihe zu mehrsprachigem TTS. Bisher haben wir WPML, Polylang, Weglot und GTranslate behandelt. TranslatePress liegt technisch gesehen zwischen diesen Lösungen, und die Audio-Einrichtung spiegelt das wider.

Wie sich TranslatePress von WPML, Polylang und Weglot unterscheidet

WPML und Polylang erstellen für jede Sprache einen eigenen Beitrag. Jede Übersetzung hat eine eigene Beitrags-ID, einen eigenen post_content und einen eigenen Permalink. Die Audiogenerierung ist unkompliziert, weil jede Sprache ein eigenständiges WordPress-Objekt ist.

Weglot verfolgt den gegenteiligen Ansatz. Übersetzungen liegen auf Weglots Servern und werden über einen Proxy oder eine Subdomain in die Seite eingebunden. Die originale WordPress-Datenbank sieht den übersetzten Text nie, weshalb serverseitiges TTS bei Weglot ohne JavaScript-Hooks kaum möglich ist.

TranslatePress ist die Zwischenlösung. Es gibt einen Beitrag pro Artikel, also enthält post_content nur die Standardsprache. Alle Übersetzungen sind aber lokal in Ihrer WordPress-Datenbank gespeichert, in den wp_trp_-Tabellen. Sie können sie lesen, abfragen und an eine TTS-Engine übergeben. Das ändert den Audio-Ansatz im Vergleich zu allen anderen vier Plugins.

Wo die Übersetzungen tatsächlich gespeichert sind

TranslatePress speichert Übersetzungen in eigenen Tabellen mit dem Präfix wp_trp_. Jedes Sprachpaar bekommt eine eigene Wörterbuchtabelle, benannt nach dem Schema wp_trp_dictionary_<source>_<target>. Dazu gibt es wp_trp_original_strings für die Quellstrings und Gettext-Tabellen für Theme- und Plugin-Übersetzungen.

Die Speicherung ist gerichtet. Eine deutsche Übersetzung einer englischen Website liegt im Englisch-Deutsch-Wörterbuch. Zum Abrufen wird dieselbe Richtung benötigt. Die relevante öffentliche Funktion ist trp_translate(). Sie nimmt einen Inhaltsstring und einen Sprachcode entgegen und gibt die übersetzte Version zurück.

if ( function_exists( 'trp_translate' ) ) {
    $translated = trp_translate( $post->post_content, 'de_DE' );
    // Pass $translated to the TTS engine, not $post->post_content.
}

Für eine TTS-Integration ist diese Funktion die einzig verlässliche Quelle. Wer post_content direkt ausliest, erhält immer die Standardsprache, unabhängig davon, welche URL der Besucher aufruft. In den TranslatePress-Integrationsdokumenten ist beschrieben, wie TTSWP das auf unserer Seite handhabt.

Diagramm: trp_translate() wandelt einen post_content in drei lokalisierte Audio-Ausgaben um
Eine Beitrags-ID, ein post_content, viele übersetzte Audio-Ausgaben über trp_translate().

Die Locale-Code-Falle

TranslatePress verwendet vollständige Locale-Codes, keine Slugs. Deutsch ist de_DE, nicht de. Französisch ist fr_FR. Brasilianisches Portugiesisch ist pt_BR. Jede Integration, die Polylang-typische zweistellige Slugs erwartet, schlägt bei TranslatePress stillschweigend fehl.

Die Entwicklerdokumentation von TranslatePress ist da eindeutig. Der Sprachcode, der an trp_translate() übergeben wird, ist der Locale-Wert aus den Einstellungen unter TranslatePress, Allgemein. Er stimmt nicht zwingend mit dem Sprachslug in der URL überein. Ein einfacher Slug wie de findet kein Wörterbuch, sodass die Funktion auf den Originalstring zurückfällt, ohne eine Warnung auszugeben. Bei eigenem Code sollten Sie Sprachcodes vor dem Aufruf von trp_translate() normalisieren und dasselbe Locale-Format zusammen mit den Audiodateien speichern, um sie später zuordnen zu können.

URL-Struktur und Caching

TranslatePress verwendet standardmäßig ein Unterverzeichnis pro Sprache. Ihre englische Seite liegt unter site.com/blog/post, die deutsche Version unter site.com/de/blog/post. Es gibt auch die Option, ein Unterverzeichnis für die Standardsprache zu verwenden, wodurch alle Sprachen symmetrisch strukturiert sind.

Das ist der ideale Fall für Caching. Unterschiedliche URLs bedeuten unterschiedliche Cache-Keys pro Sprache. WP Rocket, LiteSpeed und CDN-Edge-Caches behandeln /de/blog/post als eigenständige Ressource getrennt von /blog/post. Dadurch wird die deutsche Audiodatei mit der deutschen Seite ausgeliefert und die englische Audiodatei mit der englischen. Unsere Caching-Integrationsdokumentation erklärt die nötigen Ausschlussregeln.

Ein Risiko besteht beim kostenpflichtigen Add-on zur automatischen Spracherkennung. Es leitet Besucher anhand der Browsersprache weiter, was mit dem Seiten-Cache kollidieren und Weiterleitungen an die falschen Nutzer ausliefern kann. Dasselbe Muster haben wir im Polylang-Beitrag behandelt. Da das Add-on kostenpflichtig ist, setzen es weniger TranslatePress-Websites ein. Wer es nutzt, sollte die Weiterleitungslogik vom Cache ausschließen.

Das Problem mit der Übersetzung der Player-Oberfläche

Dieses Problem ist spezifisch für TranslatePress. Das Plugin erkennt und übersetzt Strings, die per JavaScript eingefügt werden, was ungewöhnlich ist. Die meisten Übersetzungstools ignorieren JS-gerenderte Inhalte. TranslatePress fängt sie nach dem Rendern im DOM ab und bietet an, sie zu übersetzen.

Der Nebeneffekt: Player-Beschriftungen wie „Abspielen", „Pause" und „Diesen Artikel anhören" erscheinen im TranslatePress-Editor als übersetzbare Strings. Werden diese maschinell übersetzt ohne manuelle Prüfung, kann der Player mit unpassenden oder falschen Schaltflächentexten enden. Noch schlimmer: Falsch übersetzte Barrierefreiheits-Labels können Screenreader verwirren.

Innerhalb von TranslatePress gibt es zwei Lösungsansätze. Fügen Sie dem Element, das ausgeschlossen werden soll, das Attribut data-no-translation hinzu. Oder nutzen Sie die Ausschluss-Selektoren unter den erweiterten Einstellungen, um ganze Container per CSS-Selektor auszuschließen. Beide Methoden sind in den TranslatePress-Einstellungen dokumentiert. Für den TTSWP-Player konkret: Schließen Sie den Player-Container per Klasse aus, damit die übersetzten Player-Beschriftungen aus den eigenen Sprachdateien des Plugins kommen.

Was ausgeschlossen werden sollte

  • Das Container-Element des Audioplayers
  • ARIA-Labels für Abspielen, Pause und Fortschrittssteuerung
  • Zeitanzeigen und Daueranzeigen
  • Alle Sprach- oder Stimm-Bezeichnungen, die von TTSWP gerendert werden

Wenn Sie den Player nach dem Ausschließen neu gestalten möchten, erläutern unsere Custom-CSS-Dokumente die relevanten Selektoren.

Das Problem der inhaltlichen Desynchronisierung

TranslatePress verknüpft jede Übersetzung mit dem genauen Quellstring. Wird das Original bearbeitet, erstellt TranslatePress einen neuen Quellstring und trennt die bestehende Übersetzung ab. Das Translation Memory schlägt die alte Übersetzung vor, aber bis ein Mensch sie bestätigt, fällt die Zielsprache auf den Quelltext zurück.

Für Text-zu-Sprache bedeutet das: Audio kann nach jeder Bearbeitung nicht mehr mit dem übersetzten Text übereinstimmen. Ein hinzugefügtes Komma im Englischen trennt die Übersetzung für diesen String in jeder Sprache ab. Die deutsche Audiodatei spricht noch den alten Satz, aber der sichtbare deutsche Text zeigt bereits den neuen.

Checkliste nach einer Inhaltsbearbeitung:

  1. Den neuen Quellstring im TranslatePress-Editor für jede aktive Sprache bestätigen.
  2. Audio zuerst für den Beitrag in der Standardsprache neu generieren.
  3. Audio für jede Sprache neu generieren, dann auf jeder lokalisierten URL abspielen und prüfen, ob die neue Datei mit dem sichtbaren Text übereinstimmt.
  4. Den Seiten-Cache für jede lokalisierte URL leeren, nicht nur für die Standardsprache.

TTSWP auf einer TranslatePress-Website einrichten

So sieht der aktuelle Ablauf aus. Die Integrationsdokumentation beschreibt stets das aktuelle Verhalten.

  1. TTSWP installieren aus dem WordPress.org-Plugin-Verzeichnis. Die Installationsanleitung führt Schritt für Schritt durch den Prozess.
  2. Das Plugin mit dem TTSWP-Backend verbinden. Kostenlose Konten enthalten Startguthaben, damit Sie den gesamten Ablauf vor dem ersten Kauf testen können. Weitere Infos unter Website verbinden.
  3. Sicherstellen, dass TranslatePress aktiv ist und mindestens eine Zielsprache mit vollständigem Locale-Code konfiguriert wurde.
  4. Pro Sprache eine Stimme zuweisen über das Sprache-Stimme-Mapping. Eine deutsche Stimme für de_DE, eine französische für fr_FR und so weiter. Das Stimmenkatalog listet alle verfügbaren Stimmen.
  5. Einen Beitrag veröffentlichen oder aktualisieren. Audio wird zuerst für die Standardsprache generiert.
  6. Audio auf jeder übersetzten URL abspielen. Die Generierung erfolgt bei Bedarf. Beim ersten Abspielen auf einer sekundären Sprachversion teilt TranslatePress TTSWP mit, welche Sprache aktiv ist. TTSWP generiert daraufhin die Audiodatei und speichert sie im Cache. Jede spätere Wiedergabe nutzt die gecachte Datei.
  7. Den Player von TranslatePress ausschließen über data-no-translation oder einen Selektor in den erweiterten Einstellungen, damit die Player-Beschriftungen aus TTSWPs eigenen Übersetzungsdateien stammen.

TTSWP speichert eine Audiodatei pro Beitrag und Sprache. Der Player lädt die Datei passend zur Sprache der URL, auf der sich der Besucher befindet. Auf /de/blog/post lädt der Player die deutsche Datei, auf der Standard-URL die standardsprachige Datei. Bei aktiver automatischer Übersetzung liest TTSWP den übersetzten Text direkt aus TranslatePress aus, bevor er an ElevenLabs gesendet wird. Das Audio stimmt so mit dem überein, was der Besucher auf der Seite sieht.

Kostenlose vs. kostenpflichtige Version von TranslatePress für TTS

Die kostenlose Version unterstützt eine zusätzliche Sprache, enthält 2.000 KI-übersetzte Wörter über TranslatePress AI und ermöglicht die Nutzung von Google Translate mit eigenem API-Schlüssel. Das reicht für einen zweisprachigen Blog mit passendem Audio in beiden Sprachen.

Die kostenpflichtige Version fügt unbegrenzte Sprachen, das SEO-Pack für übersetzte Slugs, Meta-Daten und hreflang-Steuerung, DeepL-Unterstützung, Übersetzer-Konten, das Add-on zur automatischen Spracherkennung und verschiedene Domains pro Sprache hinzu. Wer mehr als zwei Sprachen, hreflang-Tags für Suchmaschinen oder DeepL-Übersetzungsqualität vor der TTS-Generierung benötigt, kommt an der kostenpflichtigen Version nicht vorbei. Die Audioqualität selbst hängt nicht vom Tarif ab.

SEO und AEO mit sprachspezifischem Audio

Das SEO-Pack erlaubt die Konfiguration von hreflang-Tags pro Sprache, wahlweise länderspezifisch, sprachspezifisch oder beides. Für Suchmaschinen und KI-Antwortsysteme ist das das Signal, das Audio einer bestimmten Region zuordnet.

Fügen Sie pro Sprach-URL einen AudioObject-Schema-Eintrag mit dem passenden inLanguage-Wert ein, der dem hreflang entspricht. Google und Bing erkennen die Sprachzuordnung. In unseren eigenen Tests zitieren KI-Systeme wie Perplexity und ChatGPT Search Artikel mit Audio häufiger, wenn das Schema sauber ist und die Audio-URL auflösbar ist. Mehr dazu haben wir im Beitrag zu AEO und Audio beschrieben.

Häufige Probleme und Lösungen

ProblemUrsacheLösung
Audio wird in der falschen Sprache abgespieltText wird aus post_content statt aus trp_translate() bezogenText über trp_translate( $content, $locale ) mit vollständigem Locale-Code leiten
Player-Schaltflächen falsch übersetztTranslatePress hat die JS-gerenderten Player-Beschriftungen erfasstdata-no-translation zum Player-Container hinzufügen oder per CSS-Selektor in den erweiterten Einstellungen ausschließen
Audio fehlt nach einer InhaltsbearbeitungBearbeitung des Quellstrings trennt Übersetzungen und damit auch das sprachspezifische Audio abÜbersetzungen im TranslatePress-Editor bestätigen, dann Audio pro Sprache neu generieren
Locale-Code stimmt nicht übereinIntegration übergibt de statt de_DEVor dem Aufruf von trp_translate() auf vollständige Locale-Codes normalisieren
RTL-Layout für Arabisch oder Hebräisch fehlerhaftPlayer-CSS nicht RTL-fähigCustom CSS verwenden, um Player-Steuerung für RTL-Locales zu spiegeln
Cache liefert falsche SprachweiterleitungAdd-on zur automatischen Spracherkennung interagiert mit dem Seiten-CacheWeiterleitung vom Cache ausschließen oder automatische Erkennung deaktivieren

Hinweis zur Barrierefreiheit

Audio-Vertonung unterstützt mehrere WCAG-Erfolgskriterien, wenn der Player per Tastatur bedienbar und korrekt beschriftet ist. Wenn Sie den Player von TranslatePress ausschließen, achten Sie darauf, die ARIA-Labels in TTSWPs eigenen Übersetzungen intakt zu lassen. Unser WCAG-Audio-Leitfaden erläutert die Kriterien im Detail. Die Einrichtungsanleitung ist ein guter Einstiegspunkt.

Häufig gestellte Fragen

Funktioniert TranslatePress mit Text-zu-Sprache?

Ja. TranslatePress speichert Übersetzungen lokal in wp_trp_-Datenbanktabellen, und die Funktion trp_translate() gibt übersetzten Inhalt serverseitig zurück. Eine TTS-Integration kann den übersetzten Text auslesen und sprachspezifisches Audio generieren, solange Audio nach Beitrags-ID und Locale getrennt gespeichert wird und vollständige Locale-Codes wie de_DE statt Slugs verwendet werden.

Benötige ich die kostenpflichtige TranslatePress-Version für Audio?

Nein. Die kostenlose Version unterstützt eine zusätzliche Sprache und ermöglicht Übersetzungen über TranslatePress AI, Google Translate mit eigenem Schlüssel oder manuelle Bearbeitung. Das reicht für eine zweisprachige Website mit passendem Audio. Die kostenpflichtige Version fügt unbegrenzte Sprachen, das SEO-Pack, DeepL und Erkennungs-Add-ons hinzu, was bei mehr als zwei Sprachen oder hreflang-Steuerung sinnvoll ist.

Warum werden meine Player-Schaltflächen falsch übersetzt?

TranslatePress erkennt JS-eingefügte Strings, daher erscheinen Player-Beschriftungen in seinem Editor und können maschinell übersetzt werden. Das lässt sich beheben, indem Sie dem Player-Container data-no-translation hinzufügen oder den Player-Container in den erweiterten Einstellungen per CSS-Selektor ausschließen. Die Player-Beschriftungen kommen dann aus TTSWPs eigenen Sprachdateien.

Warum stimmt mein Audio nicht mehr mit der Übersetzung überein?

Wird der Originalstring in TranslatePress bearbeitet, entsteht ein neuer Quellstring und die bestehende Übersetzung wird abgetrennt. Das Translation Memory schlägt sie vor, aber bis zur manuellen Bestätigung fällt die Zielsprache auf den Quelltext zurück. Nach jeder Inhaltsbearbeitung Audio für den Standardbeitrag und jede Sprache neu generieren, dann den Cache für alle lokalisierten URLs leeren.

Wie unterscheidet sich TranslatePress von Weglot für TTS?

Weglot speichert Übersetzungen auf eigenen Servern und fügt sie in die Seite ein, sodass WordPress den übersetzten Text serverseitig nie sieht. TranslatePress speichert alle Übersetzungen in der lokalen Datenbank und stellt trp_translate() für den serverseitigen Zugriff bereit. Das macht die sprachspezifische Audiogenerierung mit TranslatePress direkter als mit Weglot.

Nächste Schritte

Installieren Sie Text-zu-Sprache - TTSWP aus dem WordPress.org-Plugin-Verzeichnis, verbinden Sie es mit Ihrem Konto und weisen Sie jeder Sprache, die Sie in TranslatePress verwenden, eine Stimme zu. Veröffentlichen Sie einen Beitrag, spielen Sie das Audio auf jeder übersetzten URL ab und prüfen Sie, ob es mit dem sichtbaren Text übereinstimmt. Wenn etwas nicht stimmt, sind die TranslatePress-Integrationsdokumente die erste Anlaufstelle.