Die Checkliste für Lokalisierungstests: Alles, was über die Übersetzung hinaus zu prüfen ist

Ihre deutschen Nutzer sehen eine „Absenden“-Schaltfläche, die zu „Absend…“ abgeschnitten ist. Ihr arabischer Checkout kippt halb gespiegelt, wobei der Preis am falschen Rand ausgerichtet ist. Ihr japanisches Anmeldeformular lehnt jeden Namen ab, der länger als zehn Zeichen ist. Und jeder einzelne String in Ihrem Translation Memory ist korrekt.

Übersetzung ist ein Baustein beim Versand eines Produkts ins Ausland. Der Rest ist Verifizierungsarbeit, die das auffängt, was die Übersetzung allein defekt lässt. Der globale Markt für Softwarelokalisierung wird voraussichtlich 15,6 Milliarden US-Dollar bis 2032 bei einer jährlichen Wachstumsrate von 10,6 % erreichen, was bedeutet, dass mehr Teams mehr Strings schneller in mehr Sprachen übersetzen und sich die QA-Lücke vergrößert. Diese Checkliste für Lokalisierungstests geht die acht Verifizierungsebenen durch, die auffangen, was die Übersetzung defekt lässt, und zeigt, wo jede Ebene typischerweise versagt. Teams, die ihre Lokalisierung über eine Handvoll Sprachversionen hinaus skalieren, können sich auf dedizierte Lokalisierungstest-Services verlassen, um alle acht abzudecken, ohne die Release-Zyklen zu verlangsamen.

Übersetzungstests vs. Lokalisierungstests: Wo die Grenze liegt

Übersetzungstests beantworten eine Frage: Sind die Quell-Strings in der Zielsprache sprachlich korrekt? Das ist eine Aufgabe für Übersetzer, Glossare und linguistische Prüfer.

Lokalisierungstests beantworten sieben weitere. Folgen Datumsformate den lokalen Konventionen? Validieren Währungs-, Telefon- und Adresseingaben gegen lokale Regeln? Behält die UI ihre Form, wenn übersetzte Strings über die Länge der Quelle hinauswachsen? Stimmen Zahlungsmethoden, Steuerlogik und rechtliche Hinweise mit jeder Rechtsordnung überein? Klappt das Layout für Arabisch und Hebräisch sauber ins Rechts-nach-links um? Der Übersetzer liefert korrekte Strings. Das QA-Team verifiziert, dass das Produkt um diese Strings herum in der Zielsprachversion noch funktioniert.

Die beiden als eine einzige Aufgabe zu behandeln, ist die Stelle, an der die meisten Markteinführungen Budget verlieren. Übersetzung ist der Input. Verifizierung ist das, was beweist, dass das Produkt tatsächlich versandfertig ist.

Die 8-Ebenen-Checkliste für Lokalisierungstests

Jede der folgenden Ebenen behandelt, was nach Abschluss der Übersetzung kaputtgeht, samt der Verifizierungsarbeit, die es auffängt. Die Checkliste gilt für Softwarelokalisierungstests über Web-, Mobil- und SaaS-Produkte hinweg, mit sprachversionsspezifischen Abweichungen, die pro Ebene benannt werden.

Ebene 1: Linguistische Verifizierung im Kontext

Strings, die in einer Tabelle überprüft werden, sehen gut aus. Strings, die in der Live-UI überprüft werden, erzählen eine andere Geschichte. Ein eigenständiges „Save“ wird im Spanischen zu Guardar übersetzt, aber in einem Kontext, der „Geld sparen“ bedeutet, wird aus demselben Wort Ahorrar. Ein Tabellenprüfer kann das nicht erkennen. Ein muttersprachlicher Tester, der sich durch den tatsächlichen Bildschirm klickt, kann es.

Diese Ebene umfasst vier Prüfungen: Terminologiekonsistenz über Bildschirme, E-Mails und Push-Benachrichtigungen hinweg; Platzhalter und HTML-Tags, die über die Übersetzung hinweg intakt bleiben ({username}, <b>, %s); Register, das lokalen Normen entspricht (formelles vous vs. informelles tu im Französischen, die です/ます-Form im Japanischen); und Homonyme, die im Hinblick auf die Oberfläche geprüft werden, auf der sie erscheinen. Die Arbeit ist stark menschengetrieben, weshalb sie typischerweise über einen manuellen Testing-Workflow läuft statt über eine Automatisierungs-Suite.

Ebene 2: UI und Layout unter Belastung

Sprachen dehnen sich aus und ziehen sich zusammen. Deutsche Strings sind rund 30 % länger als englische. Finnisch kann um 40 % oder mehr wachsen. Chinesisch und Japanisch komprimieren erheblich, was hilfreich klingt, bis zentrierte Layouts ausgezehrt aussehen und Tap-Ziele unter die Daumengröße schrumpfen.

Pseudolokalisierung ist hier das Sicherheitsnetz. Indem Quell-Strings durch künstlich verlängerten, akzentuierten Platzhaltertext ersetzt werden (z. B. [!!! Áccöùnt §ëttîngş !!!]), bevor eine echte Übersetzung stattfindet, können Sie hartcodierte Strings, Container mit fester Breite und Lücken im Font-Fallback Wochen vor dem Go-live aufspüren. Dieselbe Technik deckt Tofu-Boxen für Devanagari-, Thai- oder koreanische Glyphen auf, die Ihr Font-Stack tatsächlich nicht abdeckt.

Rechts-nach-links-Unterstützung verdient einen eigenen Durchgang. Arabisch, Hebräisch, Persisch und Urdu benötigen gespiegelte Layouts, umgedrehte Fortschrittsbalken, umgekehrte Symbolrichtung und Formularbeschriftungen, die am gegenüberliegenden Rand ausgerichtet sind. RTL ist auch der Punkt, an dem sich Barrierefreiheit und Lokalisierung überschneiden, weshalb es sich lohnt, Frontend-Tests und Sprachversionsprüfungen gegen dieselben Builds durchzuführen.

Ebene 3: Sprachversionsgerechte Datenformate

Formatkonventionen sind deterministisch und leicht zu testen, weshalb sie auch die Ebene sind, die am häufigsten übersprungen wird. Eine kurze Referenz dessen, was pro Sprachversion zu prüfen ist:

Die Falle ist die teilweise Umsetzung. Teams lokalisieren das Anzeigeformat, lassen aber die Eingabevalidierung an die Quellsprachversion gebunden, sodass ein deutscher Nutzer 1.234,56 korrekt angezeigt sieht und dann beim erneuten Eintippen eine Fehlermeldung „keine gültige Zahl“ erhält.

Ebene 4: Pluralisierung, Geschlecht und ICU-Regeln

Englisch hat zwei Pluralformen: ein Element und mehr als eines. Polnisch hat sogar vier. Arabisch hat sechs. Die meisten Lokalisierungsfehler auf dieser Ebene lassen sich darauf zurückführen, dass Teams die englische Annahme in ihrer Codebasis hartcodieren: "You have " + count + " messages".

Die Lösung ist ICU MessageFormat mit vollständiger Abdeckung der Plural-Schlüssel (_one, _few, _many, _other) und Testfällen pro Form pro Sprachversion. Geschlecht fügt eine weitere Achse hinzu. Ein String wie „Mark sent his file“ setzt voraus, dass Possessivpronomen dem Subjekt folgen, was im Englischen zutrifft und in Sprachen zusammenbricht, in denen das Possessivum vom besessenen Nomen abhängt.

Die Verifizierungsarbeit hier ist gering, aber nicht verhandelbar: ein Testfall pro Pluralform pro unterstützter Sprachversion, plus Vertragstests für jede Variablenersetzung. Überspringen Sie diese Ebene, und Sie liefern den 1 messages-Fehler, den Ihre Nutzer als Screenshot posten werden.

Ebene 5: Kulturelle und visuelle Angemessenheit

Symbole, Farben, Bildsprache und Beispieldaten tragen eine Bedeutung, die einen Grenzübertritt nicht überlebt. Ein Thumbs-up-Symbol ist in den meisten westlichen Märkten positiv und beleidigend in Teilen des Nahen Ostens und Westafrikas. Rot signalisiert in China Glück, in den USA Gefahr und in Teilen Südafrikas Trauer. Eine Eule steht in einer Kultur für Weisheit und in einer anderen für Unglück.

Hier schließt auch das Formulardesign leise Nutzer aus. Namensfelder mit nur einem Eingabefeld scheitern bei spanischsprachigen Nutzern mit zwei Nachnamen. Für lateinische Schriften festgelegte Zeichenbegrenzungen schneiden arabische und CJK-Namen ab. Beispieldaten, die mit „John Smith“ und „4. Juli 1990“ vorausgefüllt sind, wirken in jeder Sprachversion außerhalb des US-Englischen nachlässig.

Kulturelle Verifizierung landet selten innerhalb einer automatisierten Suite. Sie braucht muttersprachliche Tester, die Oberfläche für Oberfläche anhand einer schriftlichen Checkliste zur kulturellen Überprüfung prüfen, die auf jeden Zielmarkt zugeschnitten ist.

Ebene 6: Funktionales Verhalten pro Sprachversion

Hier entdecken die meisten Launches, dass ihr Markteinführungsplan eher eine UI-Übung als eine Produktübung war. Die funktionale Oberfläche Ihres Produkts ändert sich pro Sprachversion, und jede Änderung braucht Verifizierung.

Lokale Zahlungsmethoden: iDEAL in den Niederlanden, Boleto in Brasilien, Konbini in Japan, UPI in Indien, SEPA in der gesamten EU. Stripe plus PayPal deckt nur einen Bruchteil der globalen Checkout-Realität ab. Steuer- und Mehrwertsteuerlogik: Sätze, inklusive vs. exklusive Preisgestaltung, lokal konforme Rechnungen. Rechtliche Texte und Einwilligungen: DSGVO in der EU, LGPD in Brasilien, PIPL in China, CCPA in Kalifornien, Altersschranken und Cookie-Banner, die lokalen Regeln entsprechen. Regionsspezifische Feature-Flags für Funktionen, die in bestimmten Rechtsordnungen gesperrt sind. Suche und Autovervollständigung: Tokenisierung für CJK-Sprachen ohne Leerzeichen, Umgang mit diakritischen Zeichen für Spanisch, Französisch und Vietnamesisch.

Jedes davon ist funktionale QA-Arbeit, die auf lokalisierten Daten aufbaut. Für SaaS-Teams, die parallel in mehrere Märkte ausliefern, sorgt der Abgleich mit einer umfassenderen SaaS-Testing-Checkliste dafür, dass diese Probleme nicht im größeren QA-Umfang untergehen.

Ebene 7: Leistung, Infrastruktur und Analytics pro Region

Eine saubere deutsche UI auf einem langsamen Server verliert den Nutzer trotzdem. Tests zur Website-Lokalisierung, die Latenz aus der Zielregion, CDN-Routing und Edge-Cache-Verhalten ignorieren, übersehen eine ganze Fehlerklasse, obwohl kein String beteiligt ist.

Drei Prüfungen gehören hierhin. CDN- und Routing-Latenz, getestet von tatsächlichen IPs der Zielregion, nicht von Ihrem Büro aus. SMS- und E-Mail-Zustellbarkeit pro Land, da manche Mobilfunkanbieter transaktionale Abläufe von unregistrierten Absendern blockieren. Zeitzonenbewusste Benachrichtigungen, damit ein „Guten Morgen“-Push nicht um 3 Uhr Ortszeit auslöst.

Die vierte Prüfung sind Analytics. Markieren Sie jedes Ereignis mit der Sprachversion, nicht nur der Sprache, damit schwächelnde Märkte in Ihren Dashboards sichtbar werden. en-US und en-GB müssen unterscheidbar sein, sonst versteckt sich Ihr Rückgang der Nutzerbindung in einem von beiden monatelang hinter aggregierten Zahlen.

Ebene 8: Regression und kontinuierliche Lokalisierungs-QA

Jedes Release liefert neue Strings, neue Bildschirme und neue Grenzfälle pro Sprachversion. Die Teams, die das richtig machen, behandeln Lokalisierung genauso wie Sicherheit: als festen Posten in jedem Sprint, mit einem Verantwortlichen, markiert in jedem Bug-Report.

Die Mechanik ist konkret. Screenshot-Diffing pro Sprachversion bei jedem Release erkennt Layout-Regressionen, bevor sie die Produktion erreichen. Sprachversions-Smoke-Tests in der CI decken die kritischen Abläufe (Login, Checkout, Einstellungen, Fehlerzustände) in jeder unterstützten Sprache ab. Translation-Memory-Hygiene markiert veraltete Strings und legt unscharfe Treffer zur Überprüfung offen. Stichprobenprüfungen durch Muttersprachler laufen bei jedem Release gegen die risikoreichen Oberflächen (Anmeldung, Zahlung, Fehlermeldungen). Jeder Fehler wird markiert mit locale:</code>, sodass marktspezifische Trends in Ihrem Bug-Tracker sichtbar werden.

Diese Ebene bricht als Erste zusammen, wenn Teams skalieren. Ein Produkt mit zwei Sprachversionen kann Regression von Hand durchführen. Ein Produkt mit zwölf Sprachversionen kann das nicht. Genau hier zahlt sich ein Partner aus, der Regressionstests in großem Maßstab übernimmt.

Ihre Momentaufnahme zur Lokalisierungs-QA vor dem Launch

Bevor Sie in einen neuen Markt starten, verraten fünf Bereitschaftssignale, ob die Sprachversion wirklich fertig ist. Ist auch nur eines rot, ist der Launch nicht bereit, egal wie gut die Übersetzungen sind.

• Strings werden im Kontext über Anmeldung, Checkout, Einstellungen und Fehlerabläufe hinweg korrekt dargestellt.
• Die UI behält ihre Form bei Textexpansion, RTL-Umkehrung und Font-Fallback auf echten Zielgeräten.
• Sprachversions-Datenformate (Datum, Zahl, Währung, Adresse, Telefon) entsprechen lokalen Konventionen sowohl bei der Anzeige als auch bei der Eingabe.
• Lokale Zahlungsmethoden, Steuerlogik und rechtliche Hinweise sind live und Ende-zu-Ende verifiziert.
• Die pro Sprachversion markierte Regressionssuite läuft in der CI grün durch.

Der Zweck dieser Momentaufnahme ist es, die Bereitschaftsentscheidung binär zu machen. Entweder sind alle fünf grün und Sie liefern aus, oder eines ist rot und Sie beheben es zuerst. Der Bericht von McKinsey ergab, dass 47 % der Verbraucher weltweit lokal ansässige Marken inzwischen als wichtig für ihre Kaufentscheidung einstufen, und derselbe Instinkt gilt auch für digitale Produkte. Ein Nutzer, der merkt, dass Ihr Produkt nicht für ihn gemacht wurde, wechselt zu einem lokalen Wettbewerber, der so aussieht, als wäre es das.

Jedes Release öffnet die Checkliste erneut

Lokalisierung ist ein wiederkehrender Arbeitsanteil, der sich jedes Mal neu öffnet, wenn Sie ein Feature ausliefern, einen Textstring ändern oder einen Markt hinzufügen. Forresters Prognosen für 2026 warnten, dass ein Drittel der Unternehmen das Kundenvertrauen beschädigen wird, indem sie GenAI-Erlebnisse vorzeitig in Kontexten einsetzen, in denen sie kaum erfolgreich sein können, und dieselbe Dynamik zeigt sich auch bei der Lokalisierung. Liefern Sie eine Sprachversion aus, bevor sie verifiziert ist, und der Nutzer zahlt für Ihre versäumten Testfälle.

Die acht Ebenen oben sind der Umfang. Die schwierigere Frage ist, wer sie bei jedem Release, in jedem Markt durchführt, ohne die Roadmap zu verlangsamen. Für die meisten Teams jenseits von zwei oder drei Sprachversionen spricht die Rechnung für einen Partner mit muttersprachlichen Testern und bereits CI-integrierter Regression. Falls das das Gespräch ist, das Sie erwägen, kontaktieren Sie uns, um zu sehen, wie es für Ihr Produkt funktionieren könnte.

Erfahren Sie, wie das QA-Team von QAwerk mehr als 40 lokalisierte Versionen über 8 Branchenbereiche hinweg für ein Hochschul-Suchportal mit 110 Millionen Besuchen jährlich stabil hält.

Bitte geben Sie Ihre Geschäfts-E-Mail ein ist keine Geschäfts-E-Mail

Fallstudie anfordern