WordPress-Formulare übersetzen: Felder sind nur die halbe Miete

Warum die Formularübersetzung breiter ist als Feldbezeichnungen

Ein Formular ist kein statischer Block sichtbarer Eingabefelder. Es ist ein kleiner Arbeitsablauf, der Daten erfasst, auf Benutzerentscheidungen reagiert, Eingaben validiert und oft sowohl dem Website-Betreiber als auch dem Besucher Nachrichten sendet. Jede dieser Phasen kann sprachspezifischen Text offenlegen.

Das bedeutet, dass ein Formular auf der Seite übersetzt aussehen kann, während es in Fehlermeldungen, Bestätigungstexten, Platzhaltertext oder ausgehenden E-Mail-Inhalten dennoch die Ausgangssprache preisgibt. In der Praxis ist die Benutzererfahrung nur so mehrsprachig wie der am wenigsten übersetzte Teil des Formularablaufs.

Die nutzerseitig sichtbaren Zeichenfolgen, die übersetzt werden müssen

Sichtbare Feldbezeichnungen sind nur eine Ebene. Formulare enthalten häufig Platzhalter, Hilfetexte, Hinweise zu Pflichtfeldern, Validierungsmeldungen, Erfolgsbestätigungen und Fehlermeldungen. Diese Zeichenfolgen sind Teil der Interaktion, nicht bloße Dekoration.

Wenn ein Besucher ein unvollständiges Formular absendet und die Validierungsantwort in der falschen Sprache erscheint, hat das Formular seinen mehrsprachigen Zweck bereits verfehlt. Dasselbe gilt, wenn eine Bestätigungsmeldung oder ein Weiterleitungsziel nicht zur Sprache der Seite passt, auf der das Formular abgesendet wurde.

Warum Platzhalter und Validierungstexte technisch wichtig sind

Platzhalter und Validierungsmeldungen beeinflussen, wie Nutzer das Formular vor und nach dem Absenden interpretieren. Platzhalter können das Eingabeformat vorgeben, während Validierungstexte erklären, was schiefgelaufen ist und was zu korrigieren ist. Wenn diese Zeichenfolgen unübersetzt bleiben, funktioniert das Formular zwar möglicherweise weiterhin, aber die Interaktion wird inkonsistent.

Das ist besonders wichtig, wenn das Formular auf präzise Eingaben angewiesen ist. Eine übersetzte Bezeichnung allein hilft nicht, wenn die Validierungsmeldung sich auf einen Feldnamen oder eine Formatregel in einer anderen Sprache bezieht. Der Nutzer muss sowohl das Feld als auch die Regel verstehen, die es steuert.

Bestätigungsmeldungen und E-Mail-Benachrichtigungen gehören zur gleichen Übersetzungsfläche

Eine erfolgreiche Übermittlung löst in der Regel eine Bestätigungsmeldung auf dem Bildschirm und oft eine oder mehrere E-Mail-Benachrichtigungen aus. Diese Nachrichten sind nutzerseitig sichtbare Inhalte, auch wenn sie erst nach dem Absenden des Formulars erzeugt werden.

Wenn der Bestätigungstext übersetzt ist, die E-Mail-Benachrichtigung jedoch nicht, bricht die mehrsprachige Erfahrung beim Übergang vom Browser zum Posteingang ab. Dasselbe Problem tritt auf, wenn Betreffzeilen, Textkörper oder dynamische Feldwerte in der Ausgangssprache bleiben. Das Formular hat die Übermittlung zwar korrekt angenommen, aber die Kommunikationsebene zeigt weiterhin unübersetzten Inhalt.

Bedingte Logik verändert, was übersetzt werden muss

Bedingte Logik macht Übersetzung zu mehr als einem reinen Ersetzen von Zeichenfolgen. Wenn eine Antwort ein anderes Feld, eine andere Meldung oder einen anderen Zweig sichtbar macht, kann jeder Zweig eigene Bezeichnungen, Hilfetexte und Validierungsregeln enthalten.

Dadurch entsteht eine Abhängigkeit zwischen Sprache und Verhalten. Wenn die Logik inkonsistent übersetzt ist, sehen Nutzer möglicherweise einen Zweig, der technisch korrekt, aber sprachlich unvollständig ist, oder sie stoßen auf eine Meldung, die sich auf ein Feld bezieht, das sie in ihrer Sprache nie gesehen haben. In mehrsprachigen Formularen müssen der Logikbaum und der Textbaum synchron bleiben.

Dynamische Werte können die falsche Sprache preisgeben, selbst wenn das Formular übersetzt ist

Formulare fügen häufig dynamische Werte wie Seitentitel, ausgewählte Optionen, vom Nutzer eingegebene Daten oder andere kontextabhängige Inhalte in Bestätigungen und Benachrichtigungen ein. Diese Werte sind nicht immer statische Zeichenfolgen und müssen daher getrennt von übersetzten Bezeichnungen betrachtet werden.

Ein übersetztes Formular kann dennoch gemischtsprachige Ausgaben erzeugen, wenn der dynamische Wert aus einer Quelle stammt, die nicht sprachbewusst ist. Das ist besonders in Bestätigungsmeldungen und E-Mails sichtbar, wo das Formular übersetzten Vorlagentext mit unübersetzten oder nicht passenden dynamischen Inhalten kombinieren kann.

Operative Konsequenz: Die Übersetzung muss dem Lebenszyklus des Formulars folgen

Die praktische Erkenntnis für WordPress-Implementierer ist, dass die Übersetzung über den gesamten Lebenszyklus des Formulars bewertet werden sollte: Anzeige, Eingabehilfe, Validierung, Übermittlung, Bestätigung und Benachrichtigung. Jede Phase kann einen anderen Satz von Zeichenfolgen und Werten offenlegen.

Für WordPress-Betreiber bedeutet das, nicht nur zu prüfen, was im Editor erscheint, sondern auch, was erzeugt wird, wenn das Formular ausgeführt wird. Ein Formular kann visuell lokalisiert sein und in der Produktion dennoch scheitern, weil eine nachgelagerte Meldung, ein Zweig oder ein dynamischer Wert nie übersetzt wurde.