Antwort.

Die erste Welle der Automatisierungstests betraf praktisch nicht die Überprüfung der Lokalisierung (i18n), da die Hauptmärkte auf eine englischsprachige Benutzeroberfläche ausgerichtet waren. Mit der Globalisierung von Anwendungen stiegen jedoch die Anforderungen an die Qualität der Lokalisierung: Die Benutzeroberfläche muss korrekt in allen unterstützten Sprachen angezeigt werden, und textuelle Ressourcen sowie formatierte Zeichenfolgen müssen je nach gewählter Locale korrekt geladen werden.

Das Hauptproblem besteht darin, dass die manuelle Überprüfung sehr kostspielig ist und automatisierte Tests aufgrund der Variabilität des Formats, des Kontexts und der spezifischen Merkmale der Sprachen (z. B. von rechts nach links oder grammatikalische Besonderheiten) kompliziert sind. Es kann fehlen, dass ein Fragment übersetzt wurde, Formatierungsfehler oder Layoutverstöße gibt es.

Die Lösungen umfassen die Arbeit mit Testdaten für jede Locale, die Verwendung von Snapshot-Tests, den Vergleich von UI-Elementen mit Referenzen, die Einführung von Prüfwerkzeugen nach dem Prinzip "Schlüssel-Wert" für Ressourcendateien, automatisierte Extraktion und den Vergleich von Zeichenfolgen über APIs sowie regelmäßiges Ausführen von Lintern auf Ressourcendateien.

Schlüsselfeatures:

Überprüfung der Verfügbarkeit und korrekten Anzeige aller unterstützten Sprachen.
Vergleich von Referenzübersetzungen mit der aktuellen Anzeige in der Benutzeroberfläche.
Validierungswerkzeuge für die Länge und Formatierung von Texten, um Layoutverstöße zu vermeiden.

Trickfragen.

Kann man einen universellen Test erstellen, der jede Locale mit einem Skript validiert?

Teilweise ja, aber die Nuancen der Sprachen (Fälle, Geschlecht, Eingabeverlauf) erfordern häufig manuelle Anpassungen oder zusätzliche Bedingungen in solchen Tests. 100% Universabilität ist nicht möglich.

Wenn die Übersetzungsdatei vorhanden ist und erfolgreich geladen wurde, bedeutet das, dass der i18n-Test bestanden wurde?

Nein. Die Datei kann möglicherweise nicht korrekt im Anwendungscode verlinkt sein, es kann einen Fehler im Schlüssel geben, der Kontext der Übersetzungsnutzung kann verletzt sein, es können nicht berücksichtigte Sonderzeichen auftreten usw.

Hat es Sinn, das Testen der Lokalisierung für Sprachen mit < 1% Nutzern zu automatisieren?

Ja, wenn die Geschäftskritikalität auch für einen einzigen Nutzer hoch ist, beispielsweise bei der Erfüllung vertraglicher Verpflichtungen oder für Märkte mit besonderen Anforderungen. Automatisierung spart erheblich Ressourcen im Vergleich zu manuellen Überprüfungen.

Typische Fehler und Anti-Patterns

Nur das Vorhandensein der Datei überprüfen, aber nicht die tatsächliche Anzeige im UI.
Strikte Vergleiche von Zeichenfolgen, ohne die Besonderheiten der Grammatik und des Formats der Sprache zu berücksichtigen.
Blindes Kopieren des Tests von einer Locale auf andere ohne Anpassung.

Beispiel aus dem Leben

Negativer Fall

Das Team implementierte automatisierte Tests zum Vergleich von Schlüsseln in der .po-Datei mit dem ursprünglichen englischen Text und glaubte, dass dies ausreiche. UI-Tests wurden nicht geschrieben – im Release der arabischen Version stellte sich heraus, dass der gesamte Text außerhalb der Schaltflächen verrutscht war und einige Zeilen aufgrund falscher Schlüssel gar nicht übersetzt wurden.

Vorteile:

Schnelle Implementierung von Automatisierung im i18n.

Nachteile:

Niedriges Niveau der Abdeckung realer Nutzungsszenarien.
Wesentliche UX-Fehler blieben unbemerkt.

Positiver Fall

Es wurde eine Kombination aus Linting von Ressourcen und automatisierten Tests implementiert, die die Benutzeroberfläche in allen Sprachen durchgegangen sind, Screenshots gemacht haben und diese mit dem Referenzlayout verglichen haben. Durch die Entdeckung von Mischungen von RTL/LTR-Elementen fand das Team die Wurzel des Problems und behebe es vor dem Release.