Entwicklung der Sprachversionen

Das Online-Magazin Tellerrand-Stories thematisiert internationale Reisziele und erfreut sich zunehmender Beliebtheit auch beim nichtdeutschen Publikum. Deshalb bietet es seit längerer Zeit auf jeder Internetseite Buttons, mit denen eine automatische Übersetzung in den Sprachen Englisch, Französisch, Spanisch, Ukrainisch, Japanisch, Türkisch, Isländisch, Bulgarisch, Ungarisch, Holländisch und Polnisch angezeigt werden kann.

Diese Übersetzung liegt jedoch nicht auf dem Server von Tellerrand-Stories sondern wird vermittelt durch das Plugin Gtranslate nach dem Laden einer deutschsprachigen Seite durch den Browser vom Google-Translate-Server heruntergeladen.

Diese Lösung hat Vor- und Nachteile. Bei den Sprachen, die wir beurteilen können, lässt die maschinelle Übersetzung sehr zu Wünschen übrig. Allerdings ist nach der Einbindung des Plugins keine Arbeit mehr nötig und es lassen sich sehr viele Sprachen auswählen.

Anforderungen für eine bessere Übersetzung

Alle Inhalte für die wichtigen Fremdsprachen Englisch, Französisch und Spanisch sollen auf eigenen Internetseiten mit der besseren sprachlichen Qualität der DeepL-Übersetzung vorliegen, die mit eindeutiger URL verlinkbar und mit Suchmaschinen auffindbar sind.

Recherche

Fertige Plugins, die Internetseiten mit DeepL für feste Internetadressen übersetzen, sind leider zu Beginn der Recherche nicht auf dem Markt. Also müssen Einzelkomponenten gefunden, installiert und aufeinander abgestimmt werden.

Für die Einrichtung einer WordPress-Multisite habe ich MultilingualPress ausgewählt. Damit kann jede deutschsprachige Ursprungs-Site als Übersetzungsseite geklont werden. Übersetzt ist damit leider aber noch nichts. Alle Seiten und Beiträge liegen lediglich mit neuer URL vor und können mit WordPress-Mitteln editiert werden. Zur Auswahl stehen professionelle Übersetzer oder die absatzweise Übersetzung durch copy & paste mit Online-Übersetzungsdiensten.

Um das Verfahren zu automatisieren, habe ich das Plugin WPAutoTranslate Pro installiert. Aber auch damit ist noch lange nichts übersetzt. Das Add-on versteht sich als Verbindung zwischen den APIs verschiedener Übersetzungsdienste wie DeepL, Amazon, Google, IBM, Microsoft, Softcatalà oder Yandex mit dem Plugin MultilingualPress.

Der Weg zum Ziel

Die Einrichtung ist nicht trivial und nirgendwo umfassend beschrieben. Die Ursprungswebsite https://tellerrandstories.de/ funktionierte auf einem IONOS shared Server als Singlesite-Wordpress-Installation mit guten Geschwindigkeitswerten. Nach den verfügbaren Anleitungen habe ich diese Installation zu einer Multisite-Installation gemacht und mit MultilingualPress die erste (englische) Subdomain https://en.tellerrandstories.de/ eingerichtet. Immerhin funktionierte die Originalsite danach noch. Die neue Site hatte die gewünschte neue Subdomain in der URL. Sie war jedoch eine lückenhafte Kopie mit einer ganzen Menge Fehler. Es fehlten die meisten (aber nicht alle) Bilder und im Administrationsbereich gab es eine ganze Menge Fehlermeldungen. Da die Ursprungswebsite weiterhin funktionierte, habe ich noch in das Add-on WPAutoTranslate Pro den Authentifizierungsschlüssel für die DeepL-API, die ich mir zuvor einrichten musste, eingetragen.

Folgende Komponenten müssen zusammenwirken.

• WordPress-Installation als Live-Präsenz
• Provider
• Übersetzungsdienst
• MultilingualPress
• WPAutoTranslate Pro

Die Komponenten haben jeweils einen eigenen Support, der bei Fragen nur seine eigene Komponente erklärt/verteidigt. Ich kann aber als Nicht-Programmierer meine Website nur als Gesamtsystem verstehen.

Erfahrungsprotokoll

Meine Erfahrungen habe ich Schritt für Schritt erweitert. Die Einrichtung der zweiten (französische) Website hatte andere Komplikationen als die der englischen Website. Beispielsweise gab es nur in der französischen Subsite keine der fünf default Userrollen. Ich hatte keine andere Wahl, als mit dem zusätzlichen Plugin Reset Roles and Capabilities eine Reparatur vorzunehmen. Sie ging folgendermaßen:

1. Netzwerweit installieren
2. nur auf der betroffenen (französischen) Subsite aktivieren
3. Plugin deaktiviert sich danach von selbst
4. die Rollen Administrator, Redakteur, Autor, Mitarbeiter und Abonnent sind wieder da
5. Plugin kann gelöscht werden

Ich kann nur hoffen, dass sich die Unterschiede noch im Betrieb modifizieren lassen. Jedenfalls läuft keine Einrichtung reibungslos. Während ich die dritte (spanische) Version mit Inhalten fülle, beginne ich mit diesen Aufzeichnungen.

Ich bin Journalist und war lange Jahre Medienentwickler beim Westdeutschen Rundfunk (WDR). Programmierkenntnisse habe ich zwar keine, kann aber auf viele Jahre Web Publishing zurückblicken.

Bei der Einrichtung der ersten Fremdsprachenseite war mir die Technik von Multisites noch nicht geläufig. Vorher habe ich zwar schon viele WordPress Sites aufgesetzt und in config.php-Dateien und .htaccess-Dateien Code eingepasted. In der 35-teiligen Dokumentation zum Plugin MultilingualPress habe ich viel gelesen und bin dann gemäß dem Tutoral Erste Schritte mit MultilingualPress 3 vorgegangen. Dazu muss man wissen, dass ich das zu der Zeit verfügbare MultilingualPress als Version 4 heruntergeladen hatte. Eine Dokumentation der Änderungen oder eine Anleitung, ob die Installation von Version 4 anders zu bewerkstellingen ist, lag nicht vor.

Für Erstbenutzer wäre es besser, wenn klarer beschrieben würde, was bei der Einrichtung wichtig ist und später evtl. nicht mehr geändert werden kann. Das Tutorial setzt eigentlich schon voraus, dass ein User weiß was passiert. Schaue ich mir dieses Dokument mit den gemachten Erfahrungen jetzt noch mal an, verstehe ich es besser als vor meinen ersten Schritten. Es beschreibt sehr ausführlich, welche Einstellungen man nach der Einrichtung noch vornehmen kann.

In keiner Anleitung habe ich lückenlos und in der richtigen Reihenfolge alle notwendigen Schritte lesen können. 

So war es also ein Blindflug, als ich bei meinem Provider die Subdomain eingerichtet habe. Aber hätte ich das schon vor der Einrichtung machen sollen? Und hätte ich vor der Einrichtung der neuen WordPress-Site die Subdomain schon mit einem SSL-Zertifikat versehen müssen? Möglicherweise hätte ich mir dadurch einige Komplikationen erspart, mit denen ich mich jetzt immer noch herumschlage. Auf gut Glück (weil es nirgendwo steht) habe ich die Subdomain mit demselben Webspace verbunden, den auch meine bisherige Haupt-Site hatte. Warten. Warten. Geht das wohl gut? Wird meine bisherige Site wohl weiterexistieren? Warten. Keine Antwort war zu diesem vermeintlich simplen Problem zeitnah zu bekommen. Weder von meinem Provider noch vom MultilingualPress-Support.

Als dann nach einer langen Viertelstunde trotz aller Befürchtungen sowohl meine bisherige Site als auch die neue Subdomain funktionierten, fiel mir der erste Stein vom Herzen.

Das Testen war eher ein unstrukturiertes Ausprobieren. Das veränderte Admin-Menü zeichnete sich im Wesentlichen durch ergänzte Menüpunkte heraus. Viele Einstellungen und auch Plugins können nur netzwerkweit vorgenommen werden.

Warum ich das aufschreibe?

Dave Winer ist eine Entwickler-Legende, dessen Produkte ich seit 1988 verwende. Er hat kürzlich die ober zitierte Bemerkung gemacht, die meine Erfahrungen auch bei diesem Projekt bestätigt.

Nicht dass ich unzufrieden mit der Unterstützung durch die Entwickler meiner beiden Plugins oder meines Providers wäre. Schon die Tatsache, dass MultilingualPress und WPAutoTranslate von zwei unabhängigen Teams in Deutschland und Spanien entwickelt wird, gefällt mir gut. Bei meinen Fragen erhalte ich online ungefähr nach einem Tag eine freundliche Antwort. Leider hält sich die Kommunikation aber immer zu stark an punktuellen Fragestellungen auf. Oft wird auch eine Grenze gezogen zwischen dem eigenen und dem anderen Plugin. Bei mir wird vorausgesetzt, dass ich wissen sollte, an wen ich welche Fragen stellen soll.

Böser Wille ist es nicht. Aber bei mir erwächst der Eindruck, dass es den Gesprächspartnern vom Support hauptsächlich um das fehlerfreie Funktionieren geht. Man versucht herauszufinden, ob der Fehler auf meinem System oder in der gelieferten Software liegt. Das ist schon in Ordnung – reicht aber nicht. Mir geht es nicht nur um die richtigen Einstellungen oder um die Isolierung bestimmter Fehlfunktionen. Mir geht es darum, dass man versteht, welche Anforderungen ich habe und dass das System noch weiter entwickelt werden muss. Die jetzige Version wird ja hoffentlich nicht die letzte sein.

Ich stelle diese meine Aufzeichnung auch deshalb ins Netz, damit die beiden Entwickler-Teams in Deutschland und Spanien das lesen und über die Kommentare ein Austausch über Lösungsmöglichkeiten stattfinden kann.

Fehler und Change Requests

Mediadateien

Ein großes Problem stellen Mediadateien dar. Fotos, die in der deutschsprachigen Site eingebunden sind, werden in den Übersetzungen nur zum Teil eingesetzt. Auf dem Server bildet sich nicht die gleiche Upload-Struktur ab. D.h. die Dateien sind nicht in denselben Datumsordnern, wie in der deutschsprachigen Master-Version. Das macht die nachträgliche Editierung aufwändiger. Mit ftp habe ich mühsam die Ordner, die nach Jahr und Monat sortiert sind nachgebildet. Bei Übersetzungen mit der Mehrfachbearbeitung sind einige Bilder wie im Original mit den Alamy-Links versehen. Die jüngsten Übersetzungen hatten das nicht. Außerdem sind bei der jüngsten Übersetzung die Bilder der deutschen Fassung eingebunden.

Eine Mediendatenbank für alle Fassungen (Change Request)

Mit einem Third Party Plugin funktionierte leider das Featured Image nicht in Teasern, die mit Query Loop gebaut sind.

Übersetzung bei jeder Aktualisierung

Ein sehr gravierender Fehler ist die erneute komplette Übersetzung in die drei Sprachversionen, wenn in der deutschsprachigen Version nur eine Kleinigkeit verändert wurde. Dann wird in der Übersetzung der eventuell manuell angepasste fremdsprachige Text erneut in eine ungeeignete Formulierung geändert und – besonders schlimm – der Dateiname erneut übersetzt, obwohl das grundsätzlich abschaltbar sein sollte.

Vermutlich im Einflussbereich von MultilingualPress ist mit höchster Priorität eine Default-Einstellung nötig, die jegliche Übersetzung beim Abspeichern einer Datei verhindert. Jetzt gibt es die nicht und es ist vorgekommen, dass zahlreiche manuelle Editierungen in fremdsprachigen Artikeln überschrieben worden sind, nur weil in der deutschen Fassung ein Satzzeichen korrigiert wurde. Aus diesem Grund existiert dieser Beitrag nur auf Deutsch.

Slug soll übernommen und nie übersetzt werden

Bei den Entwicklern von WP Autotranslate habe ich schon gemeldet, dass es die Option geben muss, die Übersetzung für einzelnen Seitenbestandteile einzeln aktivieren zu können. Die nicht abschaltbare Übersetzung des Slug muss z.B. immer wieder manuell rückgängig gemacht werden.

Slug, Kategorien, Schlagworte

Bei der Übersetzung aus der Beitragsübersicht mit Mehrfachaktionen passieren zwei Fehler und ein ungewollter Effekt

• Kategorien werden falsch zugeordnet
• Schlagworte werden nicht übersetzt
• Slug wird übersetzt. Er soll aber übernommen werden

Lösung nur durch manuelles Nachbessern möglich.

Seite

Fehler beim automatischen Übersetzen wenn es schon eine Seite gibt, wird die nicht mit der Übersetzung überschrieben, sondern es wird eine zusätzliche Seite angelegt mit übersetztem Slug

Betrieb

Der Alltag sieht für jede Redaktion unterschiedlich aus. Die hier verwendeten Übersetzungs-Plugins müssen in einigen Punkten noch Verbesserungen bekommen, damit sie sich nahtlos in die Abläufe bei Tellerrand-Stories einfügen.

Erforderlich ist, dass mehrere Rollen gleichzeitig arbeiten können und dabei folgende Aufgaben erledigen.

• Neue Artikel entstehen zunächst in einer aktuellen Kurzfassung und werden danach kontinuierlich ergänzt.
• Auf deutsch bestehende Artikel werden in Fremdsprachen übersetzt.
• Die automatisch unterstützte Übersetzung wird überprüft und manuell verbessert.
• Mehrsprachige Artikel werden in der deutschen Fassung inhaltlich aktulisiert.
• Fehler in deutschen oder fremdsprachigen Fassungen werden korrigiert.
• Fotos werden ergänzt oder ausgetauscht.

All das ist derzeit nicht möglich, wenn WP Autotranslate aktiv ist, denn dann werden bei jedem Abspeichern der deutschen Fassung alle Komponenten in allen Sprachfassungen erneut übersetzt. Die Nachteile davon sind neben dem unnötigen und Kosten verursachenen Datenverbrauch vor allem, dass jegliche manuell erzeugte Sprachfassung überschrieben wird und sich der Slug ändert, weil auch er erneut übersetzt wird.

Arbeiten mehrere Autoren und Übersetzer gleichzeitig am System, muss WP Autotranslate derzeit komplett abgeschaltet bleiben, damit es keine Kollateralschäden gibt. Während der Übersetzung mit aktiviertem WP Autotranslate darf nicht redaktionell gearbeitet werden.

Diese Installation verwendet sehr viele Bilder und andere Mediendateien, die in allen Sprachfassungen in gleicher Weise verwendet werden. MultilingualPress ist in der Grundeinstellung so vorgesehen, dass jede Sprachfassung auf eigene Mediendateien zurückgreift, die deshalb auch mehrfach auf dem Server vorkommen, was weder datenökonomisch noch elegant ist. Von einer möglichen Fehleranfälligkeit im Betrieb konnte ich nichts bemerken. Von den in der deutschen Ursprungsfassung verwendeten ca 19.000 Dateien sind bei der Erstellung der Sprachversionen ohne reproduzierbare Ähnlichkeiten höchstens 20 % im neuen Verzeichnis erzeugt worden. Eine 1:1 Kopie durch ftp hat als Workaround geholfen. Von Haus aus kann MultilingualPress nicht, wie in diesem Fall erstrebenswert, für alle Sprachversionen auf eine einzige Datenbank zurückgreifen. Es gibt aber das Plugin Network Media Library. Mit diesem konnte ich zwar mit allen Sprchversionen auf die zentrale Mediendatenbank zugreifen. Allerdings lassen sich keine Beitragsbilder (Featured Images) anzeigen. Um Beitragsbilder mit dem Query Loop Block in Teaser einbinden zu können ist das auch noch keine befriedigende Lösung.