Ein Tag, 13 Seitenpaare: was passiert, wenn man das eigene Plugin auf eine echte Seite lässt

Es gibt eine Sorte Satz, die wir über eigene Produkte nicht schreiben wollen: „In unseren Tests funktioniert das zuverlässig." Tests sind Behauptungen über Bedingungen, die man selbst gebaut hat. Wimpel hatte 333 davon, alle grün, und trotzdem wusste niemand, wie sich das Plugin auf einer Seite anfühlt, die jemandem gehört.

Am 14. September 2026, einen Tag nach der Freigabe im WordPress-Verzeichnis, haben wir das nachgeholt. Der interne Name dafür ist Golden Path: einmal den ganzen Weg gehen, den ein fremder Mensch gehen würde, auf einer echten Seite, mit Inhalten, die nicht für diesen Zweck erfunden wurden. Sechzehn Schritte, jeder mit einer Bedingung. Bricht ein Schritt, ist der Weg dort zu Ende, und der Befund ist das Ergebnis.

Die Seite

Gewählt wurde die Beta von vielfalt-begleiten.nrw, einem Projekt zur Integrationsbegleitung in Nordrhein-Westfalen. WordPress 7.1, 22 Seiten, 67 Beiträge. Auf der Seite lagen zu dem Zeitpunkt acht weitere Plugins aktiv, darunter unsere eigenen für Formulare, Weiterleitungen und Galerien. Das ist wichtig: Ein Plugin allein auf einer leeren Installation beweist wenig.

Der Auftrag vom Seitenbetreiber war eng gefasst: zweisprachig Deutsch und Englisch, aber ohne die sieben interaktiven Werkzeugseiten und ohne zwei interne Seiten. Blieben 13 Seiten. Installiert wurde über die REST-Schnittstelle direkt aus dem Verzeichnis, ohne Datei-Upload. Das ging nur, weil das Plugin seit dem Vortag dort steht.

Der Prüfstein: eine Kopie, die nichts verändert

Wer eine Seite übersetzen will, drückt bei Wimpel einen Knopf und bekommt einen Entwurf: Titel, Inhalt und Auszug der Quelle, bereits mit ihr verknüpft. Klingt banal. Ist es nicht.

WordPress schickt Inhalte beim Speichern durch eine Funktion namens wptexturize, die aus geraden Anführungszeichen typografische macht und aus zwei Bindestrichen einen Gedankenstrich. Für Fließtext ist das eine Wohltat. In einem Inline-Skript oder einer HTML-Insel ist es ein Sabotageakt. Genau daran ist Wimpel in Version 1.0.0 einmal gescheitert, damals verschwanden iframes.

Deshalb wurden sieben Seitenpaare nach dem Kopieren nicht angeschaut, sondern verglichen, Zeichen für Zeichen:

Die Startseite ist der interessante Fall: 191 Blöcke, zwei HTML-Inseln, drei Inline-Skripte und eine interaktive Standortkarte. Also genau das Markup, bei dem eine Textkorrektur normalerweise zuschlägt. Sie kam unversehrt heraus.

Drei Lücken, die kein Testfall gefunden hätte

Und dann kam der Teil, für den man solche Durchläufe macht.

Die Seitenvorlage fährt nicht mit

Alle 13 Entwürfe kamen mit der Standardvorlage heraus, obwohl 12 der 13 Quellseiten auf einer eigenen Landingpage-Vorlage stehen. Der Kopiervorgang nimmt Titel, Inhalt und Auszug mit, die Vorlagenzuweisung aber nicht. Sichtbar wird das sofort: Die englische Seite sieht anders aus als die deutsche, obwohl derselbe Inhalt darin steht. Behebbar von Hand in zwanzig Sekunden pro Seite, bei 13 Seiten also eine Viertelstunde stumpfe Arbeit, die niemand machen sollte.

Die Elternseite fährt auch nicht mit

Am Tag darauf der Zwilling desselben Fehlers: Die englische Fassung der Seite „Das Team" landete auf oberster Ebene, statt unter der Transferstelle zu hängen wie ihr Original. Bei einer Seitenhierarchie ändert das den Permalink. Aus einer erwarteten Adresse wird eine andere, und wer den Fehler erst nach der Indexierung bemerkt, braucht eine Weiterleitung.

Der Sprachumschalter kennt nur eine Größe

Der Umschalter gibt immer beides aus, Kürzel und Sprachname: „DE Deutsch EN English". Im Seitenkopf dieser Seite hat das die Navigation in die zweite Zeile gedrückt, „Kontakt" rutschte nach unten. Der Block nimmt zwar Einstellungen entgegen, verwirft sie aber intern wieder. Für die nächste Version ist eine Anzeigeoption vorgesehen: nur Kürzel, nur Name, oder beides.

Dazu kam ein vierter Punkt, der keine Lücke im Code ist, aber trotzdem stört: Die Verzeichnisfassung liefert keine Übersetzungsdateien mehr mit, die Oberfläche steht deshalb auf einer deutschen Installation auf Englisch. Der richtige Weg dafür führt über die Übersetzungsplattform von WordPress, und dort werden wir die deutsche Fassung einreichen.

Was am Ende stand

13 Seitenpaare live, jede englische Seite erreichbar, auf allen 26 Seiten genau drei hreflang-Verweise: Deutsch, Englisch, x-default. Auf der einen bewusst einsprachig gelassenen Seite gibt Wimpel kein hreflang aus, so wie es die Beschreibung verspricht. Das ist der Unterschied zwischen einer Zusage im Text und einer Zusage, die man im Quelltext einer laufenden Seite nachsehen kann.

Die Slugs sind übersetzt, nicht durchnummeriert. Das ist Absicht und es ist der Punkt, an dem sich Mehrsprachigkeit von Sprachschaltern unterscheidet: Eine englische Seite unter /about-the-project/ ist eine Seite, die in englischen Suchergebnissen etwas zu suchen hat. Eine unter /ueber-das-projekt/?lang=en ist es nicht. In unserem eigenen Blog in sieben Sprachen gilt dieselbe Regel.

Offen geblieben ist einiges, und das gehört hierhin: Die HTML-Inseln blieben deutsch, interne Links zeigen teilweise noch auf deutsche Ziele, der Betreff eines Mailto-Links ist deutsch, und das Menü ebenfalls. Letzteres ist kein Fehler, sondern eine bewusste Grenze des Plugins. Menüs, Kategorien und Theme-Texte übersetzt Wimpel nicht. Wer das braucht, findet die Grenzen der übrigen Wege in unserem Vergleich der kostenlosen WPML-Alternativen.

Der Tag danach, oder: der erste Pflegefall

Am 15. September hat der Seitenbetreiber die deutsche Fassung umgebaut. Vier Seiten geändert, eine neu angelegt. Die Startseite wuchs von 88.963 auf 96.061 Zeichen, „Über das Projekt" von 9.292 auf 13.904.

Das ist der eigentliche Test für ein Mehrsprachigkeits-Plugin. Der erste Aufbau gelingt fast jedem Werkzeug. Interessant wird es, wenn Inhalte weiterleben.

Die Verknüpfungen hielten. Alle 14 Paare zeigten nach dem Umbau weiter aufeinander, hreflang stimmte, und für die neue Seite genügte ein Klick auf den Anleger in der Seitenliste. Beim erneuten Kopieren: 168 von 168 Blöcken identisch, die Standortkarte byte-genau, in der Video-Insel genau ein geändertes Zeichenkettenpaar.

Was fehlt, ist der Hinweis. Wimpel sagt nicht, dass eine Übersetzung veraltet ist. Pikant daran: Die Funktion, die das feststellen könnte, existiert bereits im Code. Sie vergleicht eine gespeicherte Prüfsumme des Originals gegen dessen heutigen Inhalt. Herausgeschnitten wurde sie, weil sie zur kostenpflichtigen Übersetzungslinie gehörte. Der Golden Path hat gezeigt, dass diese Zuordnung falsch war: Die Veraltet-Markierung gehört nicht zur KI, sie gehört zur Mehrsprachigkeit.

Der Nebenbefund, der uns am meisten gefreut hat

Beim Übersetzen ist ein Fehler aufgefallen, der nichts mit dem Plugin zu tun hatte. Auf der deutschen Startseite stand ein Absatz dreimal. Ein Hilfsskript hatte irgendwann angehängt statt ersetzt, und über Monate hatte es niemand gesehen.

Das ist die unterschätzte Nebenwirkung von Mehrsprachigkeit: Eine Übersetzung ist ein zweiter Blick auf den eigenen Text, und zwar ein unbestechlicher. Wer 13 Seiten Satz für Satz in eine andere Sprache bringt, findet dabei Dopplungen, tote Verweise und Sätze, die nie jemand zu Ende gedacht hat.

Was davon für Ihre Seite gilt

• Prüfen Sie die Kopie, nicht das Versprechen. Öffnen Sie nach dem ersten Übersetzungsentwurf den Code-Editor beider Fassungen und vergleichen Sie die Blockzahl. Fehlt ein Block, hören Sie an dieser Stelle auf und suchen Sie ein anderes Werkzeug.
• Nehmen Sie eine Seite mit Skripten als Testfall, nicht die einfachste. Wenn eine Karte, ein Video-Embed oder ein Formular die Kopie übersteht, überstehen Ihre Textseiten sie auch.
• Rechnen Sie den Aufwand in Text, nicht in Klicks. Die Technik war in einer Stunde fertig. Die Übersetzungen sind die Arbeit.
• Lassen Sie eine Seite bewusst einsprachig und sehen Sie im Quelltext nach, ob Ihr Plugin dafür hreflang ausgibt. Wenn ja, verspricht es Google eine Seite, die es nicht gibt.
• Übersetzen Sie die Slugs. Ein Sprachparameter an einer deutschen Adresse ist keine englische Seite.

Und der Kern der Sache

Wir hätten diesen Durchlauf auch machen und darüber schweigen können. Drei Lücken in einem frisch veröffentlichten Plugin sind kein Werbematerial.

Nur ist die Alternative schlechter. Ein Plugin, das nie auf einer echten Seite lief, ist ein Versprechen ohne Deckung, und davon stehen im WordPress-Verzeichnis reichlich. Wir haben Ende August nachgezählt: 58,4 Prozent der gelisteten Plugins hatten seit über einem Jahr kein Release. Wie wir die WordPress-Plugins gezählt haben, steht in einem eigenen Beitrag. Der Unterschied zwischen einem gepflegten und einem liegengebliebenen Plugin zeigt sich nicht am Veröffentlichungstag. Er zeigt sich daran, was vier Wochen später passiert, wenn jemand einen Fehler meldet.

Die drei Lücken von oben stehen auf der Liste für Version 1.1.2 und 1.2. Was daraus wird, steht hier, wenn es soweit ist.

Häufige Fragen