Lokalisierungstests: Ein QA-Leitfaden für mehrsprachige Anw…

Lokalisierungstests: Ein QA-Leitfaden für mehrsprachige Anwendungen

Eine mehrsprachige Anwendung auszuliefern bedeutet mehr als Strings an eine Übersetzungsagentur zu übergeben und die Dateien wieder einzuspielen. Die Fehler, die Nutzer in lokalisierten Builds erreichen, sind selten Übersetzungsfehler — sie sind Integrationsfehler: ein Button, dessen Beschriftung auf Deutsch abgeschnitten wird, ein Datum, das in einem Rechts-nach-Links-Layout falsch herum angezeigt wird, eine Pluralform, die nur für Englisch fest kodiert wurde und auf Russisch versagt, ein Preis mit einem Punkt als Dezimaltrennzeichen in Deutschland, wo das Komma die Konvention ist. Das sind Engineering- und QA-Probleme, die einen strukturierten Testansatz erfordern, in den die meisten Teams zu wenig investieren.

Dieser Leitfaden richtet sich an QA-Engineers und Entwickler, die lokalisierte Builds rigoros validieren müssen. Er behandelt die Arten von Lokalisierungstests, die wertvollste automatisierte Technik (Pseudo-Lokalisierung), eine praktische Checkliste zur Fehlersuche und die Integration von Lokalisierungstests in CI-Pipelines.

TL;DR / Wichtigste Erkenntnisse

Lokalisierungstests unterscheiden sich von der Übersetzungsüberprüfung — sie verifizieren die funktionale und visuelle Korrektheit einer lokalisierten Anwendung, nicht die sprachliche Genauigkeit des übersetzten Textes.
Pseudo-Lokalisierung ist die wertvollste automatisierte Technik: Sie transformiert Strings in Ihrer Quellsprache in visuell markante Zeichen, die Layout- und Kodierungsfehler aufdecken, ohne echte Übersetzungen zu erfordern.
Die häufigsten Lokalisierungsfehler sind Textabschneidungen in Sprachen, die sich deutlich ausdehnen (Deutsch und Finnisch dehnen englischen Text um 30–50 % aus), fehlerhafte RTL-Layouts und hart kodierte String-Verkettungen, die in Sprachen mit anderer Wortstellung grammatisch ungültige Ausgaben erzeugen.
Automatisierte Screenshot-Vergleichstools (Percy, Chromatic) und Browser-Automatisierungs-Frameworks (Playwright, Cypress) können Lokalisierungsprüfungen in Ihrer CI-Pipeline erzwingen, ohne dass ein Mensch jede Sprachversion manuell überprüfen muss.
Lokalisierungstests sollten an drei Punkten stattfinden: in CI bei jedem Build mittels Pseudo-Lokalisierung, nach jedem Übersetzungsimport und als dedizierter Durchlauf vor jedem größeren Release.

Was sind Lokalisierungstests?

Lokalisierungstests sind der Prozess der Überprüfung, ob eine Softwareanwendung korrekt funktioniert und korrekt angezeigt wird, wenn sie für ein bestimmtes Gebietsschema, eine bestimmte Sprache oder eine bestimmte Region angepasst wurde. Es handelt sich ausdrücklich nicht um dasselbe wie eine Übersetzungsüberprüfung.

Bei der Übersetzungsüberprüfung wird gefragt: „Ist dieser String korrekt ins Französische übersetzt?" Das ist eine sprachliche Frage, die von einem fließend Sprechenden oder einem professionellen Übersetzer beantwortet wird.

Bei Lokalisierungstests wird gefragt: „Funktioniert der französisch lokalisierte Build der Anwendung korrekt?" Das ist eine Engineering-Frage, die von QA-Engineers und automatisierten Test-Suites beantwortet wird.

Eine Übersetzung kann perfekt korrekt sein und dennoch eine fehlerhafte Benutzeroberfläche erzeugen. „Benutzereinstellungen" ist die korrekte deutsche Übersetzung von „User Settings" — und ist gleichzeitig 40 % länger, was bedeutet, dass ein für 13 Zeichen dimensionierter Button es bei „Benutzereinstellun..." abschneidet, sofern das Layout nicht für Ausdehnung ausgelegt wurde. Das Übersetzungsteam hat nichts falsch gemacht. Der Layout-Entwickler hat die Zusammensetzung deutscher Wörter nicht berücksichtigt. Lokalisierungstests erkennen dies, bevor es einen Nutzer erreicht.

Der Umfang von Lokalisierungstests umfasst:

Layout und visuelle Darstellung über Sprachversionen hinweg
Funktionale Korrektheit (Datumseingaben, Formularvalidierung, Sortierung, Suche)
Gebietsschemaspezifische Datenformatierung (Zahlen, Währungen, Datumsangaben, Adressen)
Kodierung und Zeichendarstellung für nicht-lateinische Schriften
RTL-Layout-Korrektheit für Arabisch und Hebräisch
Pluralisierungsregeln und grammatische Korrektheit dynamischer Strings
Gebietsschemaspezifische Geschäftslogik (Steuerformate, Telefonnummernvalidierung, Postleitzahlenformate)

Arten von Lokalisierungstests

Linguistische Tests

Linguistische Tests sind die Schnittstelle zwischen Lokalisierungs-QA und Übersetzungsüberprüfung. Ein zweisprachiger Tester oder ein Muttersprachler geht mit dem aktiven Zielgebietsschema durch die Anwendung und prüft auf Strings, die technisch übersetzt, aber kontextuell falsch sind — UI-Strings, bei denen Kürze entscheidend ist, Button-Beschriftungen, bei denen die übersetzte Version mehrdeutig ist, oder Fehlermeldungen, bei denen der Ton für die Zielkultur unpassend ist.

Beispiel: Ein Bestätigungsdialog sagt auf Englisch „Are you sure?". Die spanische Übersetzung „¿Está seguro?" ist technisch korrekt, verwendet jedoch einen formellen Register. In einer lässigen Verbraucher-App für lateinamerikanische Nutzer wäre das informelle „¿Estás seguro?" angemessener. Das ist kein Fehler, den eine Test-Suite erkennt — es erfordert einen menschlichen Tester mit kulturellem Wissen.

Linguistische Tests sind in der Regel für die Vorab-Release-Validierung und für hochfrequentierte Sprachversionen reserviert. Sie lassen sich nicht in automatisierte Pipelines übertragen, bleiben aber unersetzlich für die Fehlerklasse, die für englischsprachige Entwickler unsichtbar ist.

Kosmetische und UI-Tests

Kosmetische Tests konzentrieren sich auf visuelle Korrektheit: Sieht die Benutzeroberfläche mit echtem übersetztem Inhalt korrekt aus? Dies umfasst:

Textabschneidungen oder Überlauf, wenn Übersetzungen länger als die Quelle sind
Layout-Brüche durch Strings, die unerwartet umbrechen
Symbol- und Bild-Platzhalter mit eingebettetem Text (der nie für die Übersetzung extrahiert wird)
Schriftarten-Rendering für nicht-lateinische Schriften (CJK-Zeichen, Arabisch, Devanagari)
Ausrichtungsprobleme beim Mischen von LTR- und RTL-Inhalten auf demselben Bildschirm

Kosmetische Fehler sind die häufigste Kategorie in lokalisierten Builds und eignen sich gut für automatisierte Screenshot-Vergleiche.

Funktionale Tests

Funktionale Tests überprüfen, ob das gebietsschemaspezifische Verhalten korrekt funktioniert, nicht nur ob die Benutzeroberfläche dargestellt wird. Beispiele:

Ein Datums-Picker, der für en-US im Format M/T/J und für en-GB im Format T/M/J angezeigt wird — erzeugt die Auswahl eines Datums im Picker den korrekten Wert?
Ein Telefonnummer-Eingabefeld mit einem Format-Validator — akzeptiert es korrekt deutsche Nummern (+49...) und lehnt US-formatierte Nummern ab, wenn das Gebietsschema de-DE ist?
Eine Sortierfunktion — sortiert sie alphabetisch mit den korrekten Sortierregeln für das Gebietsschema? Schwedisch behandelt „ä" als Buchstaben, der nach „z" sortiert; eine naive Unicode-Sortierung liefert falsche Ergebnisse.
Eine Suchfunktion — stimmt sie Strings ohne Berücksichtigung der Groß-/Kleinschreibung mit gebietsschemabewusstem Vergleich ab (Türkisches „I" vs. „i" ist ein bekannter Sonderfall)?

Funktionale Lokalisierungsfehler sind oft die schwerwiegendsten, weil sie Verhaltensfehler sind, keine visuellen.

Gebietsschemaspezifische Tests

Gebietsschemaspezifische Tests überprüfen die Korrektheit für eine bestimmte Region, nicht für eine Sprache. en-US und en-GB teilen eine Sprache, unterscheiden sich jedoch in Datumsformat, Währung, Schreibkonventionen und Postleitzahlenformat. fr-FR und fr-CA teilen eine Sprache, unterscheiden sich aber in Terminologie und Währung. Gebietsschemaspezifische Tests erkennen Annahmen, die für ein Gebietsschema gelten, für ein anderes aber versagen.

Pseudo-Lokalisierung

Pseudo-Lokalisierung ist die wertvollste automatisierte Technik bei Lokalisierungstests und wird zu wenig eingesetzt. Sie transformiert Strings in Ihrer Standardsprache programmatisch in visuell markante Zeichen, die die Eigenschaften übersetzten Textes simulieren — ohne echte Übersetzungen zu erfordern. Die Anwendung wird dann in diesem Pseudo-Gebietsschema ausgeführt und getestet.

Welche Probleme Pseudo-Lokalisierung findet

Eine gut konzipierte Pseudo-Gebietsschema-Transformation erledigt vier Dinge gleichzeitig:

Dehnt die Stringlänge aus, um Sprachen wie Deutsch und Finnisch zu simulieren, die längere Übersetzungen erzeugen
Ersetzt ASCII-Zeichen durch akzentuierte oder Nicht-ASCII-Äquivalente, um Kodierungsprobleme und Schriftarten-Rendering-Probleme aufzudecken
Umschließt Strings mit sichtbaren Trennzeichen, um Strings aufzudecken, die nie für die Übersetzung extrahiert wurden (hart kodierte Strings in der UI)
Verwendet nur gültige Unicode-Zeichen, damit keine echten Unicode-Rendering-Fehler verschleiert werden

Wie ein pseudo-lokalisierter String aussieht

Aus dem Quell-String "Submit Form" erzeugt eine Pseudo-Lokalisierungs-Transformation etwas wie:

[Ṡüḃṃïẗ Ḟöŕṃ !!!]

Die eckigen Klammern [ und ] machen es sofort sichtbar, wenn ein Zeichen des Strings verloren gegangen, abgeschnitten oder abgetrennt wurde. Die akzentuierten Zeichen (Ṡ, ü, ḃ, ṃ, ï, ẗ) testen die Schriftarten-Abdeckung und Kodierungs-Pipelines. Das abschließende !!! polstert den String, um Ausdehnung zu simulieren — ein 10-Zeichen langer englischer String wird zu einem 16-Zeichen langen pseudo-lokalisierten String, der die deutschen Ausdehnungsraten annähert.

Weitere Beispiele:

Quell-String	Pseudo-lokalisiert
`Save Changes`	`[Ṡàṽé Çḥàñġéš !!!]`
`Delete account`	`[Ḋéłéẗé àċċöüñẗ !!!]`
`Welcome, {name}!`	`[Ẇéłċöṃé, {name}! !!!]`
`Cancel`	`[Çàñċéł !!]`
`Settings`	`[Ṡéẗẗïñġš !!]`

Beachten Sie, dass {name} im letzten Beispiel unverändert bleibt. Eine gute Pseudo-Lokalisierungsimplementierung identifiziert und bewahrt Interpolations-Platzhalter, HTML-Tags und Format-Strings, damit die Laufzeit nicht bricht, wenn Werte eingesetzt werden.

Pseudo-Lokalisierung implementieren

In JavaScript/TypeScript-Projekten unterstützt die i18next-Bibliothek Pseudo-Lokalisierung über ein Post-Prozessor-Plugin. Sie konfigurieren ein pseudo-Gebietsschema, das die Transformation auf der String-Lookup-Ebene anwendet:

import i18next from 'i18next';

// Einfache Pseudo-Lokalisierungs-Transformationsfunktion
function pseudoLocalize(str: string): string {
  const charMap: Record<string, string> = {
    a: 'à', b: 'ḃ', c: 'ċ', d: 'ḋ', e: 'é', f: 'ḟ', g: 'ġ',
    h: 'ḣ', i: 'ï', j: 'ĵ', k: 'ķ', l: 'ł', m: 'ṃ', n: 'ñ',
    o: 'ö', p: 'ṗ', q: 'q', r: 'ŕ', s: 'š', t: 'ẗ', u: 'ü',
    v: 'ṽ', w: 'ẇ', x: 'x', y: 'ý', z: 'ż',
    A: 'À', B: 'Ḃ', C: 'Ç', D: 'Ḋ', E: 'Ė', F: 'Ḟ', G: 'Ġ',
    H: 'Ḣ', I: 'Ï', J: 'Ĵ', K: 'Ķ', L: 'Ĺ', M: 'Ṁ', N: 'Ñ',
    O: 'Ö', P: 'Ṗ', Q: 'Q', R: 'Ŕ', S: 'Ṡ', T: 'Ṫ', U: 'Ü',
    V: 'Ṽ', W: 'Ẇ', X: 'X', Y: 'Ý', Z: 'Ż',
  };

  // Platzhalter wie {name}, %s, {{count}} usw. bewahren
  const placeholderPattern = /(\{[^}]+\}|%[sdfi]|\{\{[^}]+\}\})/g;
  const parts = str.split(placeholderPattern);

  const transformed = parts
    .map((part) => {
      if (placeholderPattern.test(part)) {
        return part; // Platzhalter unverändert lassen
      }
      return part
        .split('')
        .map((char) => charMap[char] ?? char)
        .join('');
    })
    .join('');

  // Auffüll-Padding und umschließende Klammern hinzufügen
  const padding = '!'.repeat(Math.max(2, Math.floor(str.length * 0.4)));
  return `[${transformed} ${padding}]`;
}

Für React-Anwendungen können Sie das Pseudo-Gebietsschema injizieren, indem Sie NEXT_PUBLIC_LOCALE=pseudo (oder äquivalent) in Ihrer Testumgebung setzen und alle Übersetzungsschlüssel durch die Transformationsfunktion leiten, bevor sie zurückgegeben werden.

Für Android aktiviert das pseudolocales-Flag in build.gradle zwei eingebaute Pseudo-Gebietsschemata: en-XA (akzentuiertes Latein) und ar-XB (gespiegeltes RTL-Layout). Diese sind in die Android-Plattform integriert:

android {
    buildTypes {
        debug {
            pseudoLocalesEnabled true
        }
    }
}

Für iOS bietet Xcode Pseudo-Lokalisierung über die Optionen Accented Pseudolanguage und Bounded String Pseudolanguage im Schema-Editor (Product > Scheme > Edit Scheme > Options > App Language).

Tools, die Pseudo-Lokalisierung unterstützen

Android SDK: Eingebaute Pseudo-Gebietsschemata en-XA und ar-XB
Xcode: Eingebaute Optionen für akzentuierte und umgrenzte Pseudo-Sprachen in den Schema-Einstellungen
i18next (JavaScript): Plugin-basierte Post-Prozessor-Unterstützung
GNU gettext: msginit --no-translator mit benutzerdefinierter Gebietsschema-Konfiguration
Better i18n und ähnliche Plattformen: Einige i18n-Management-Plattformen bieten Pseudo-Gebietsschema-Export als eingebaute Funktion, sodass Sie eine pseudo-lokalisierte Version Ihrer Quell-Strings herunterladen können, ohne Transformationscode schreiben zu müssen

Pseudo-Lokalisierung sollte Teil Ihrer CI-Pipeline sein und bei jedem Build ausgeführt werden. Sie kostet nichts an Übersetzungsgebühren und erkennt eine Klasse von Fehlern — Abschneidungen, Kodierung, hart kodierte Strings — bevor überhaupt mit echten Sprachversionen begonnen wird.

Checkliste für Lokalisierungstests

Verwenden Sie diese Checkliste bei QA-Durchläufen an jedem lokalisierten Build. Als automatisierbar markierte Punkte können von Test-Suites erkannt werden; der Rest erfordert menschliche Überprüfung oder gebietsschemaspezifische Testfälle.

Textdarstellung

Kein sichtbarer Textabschnitt oder Ellipsis bei UI-Strings in Sprachversionen mit langer Ausdehnung (Deutsch, Finnisch, Niederländisch)
Kein Textüberlauf in benachbarte Elemente oder außerhalb von Container-Grenzen
Alle Strings sind übersetzt — keine Quellsprachen-Strings sichtbar im Zielgebietsschema (Pseudo-Lokalisierungs-Klammern sind die automatisierte Version dieser Prüfung)
Die Schriftart unterstützt alle Zeichen der Zielschrift (CJK, Arabisch, Devanagari, Armenisch prüfen)
Keine unleserlichen oder Ersatzzeichen (Box-Zeichen, Fragezeichen), die auf Kodierungsfehler hinweisen

String-Verkettung und -Komposition

Dynamische Strings aus Teilen erzeugen in der Zielsprache grammatisch korrekte Ausgabe — Deutsch und Russisch haben grammatische Kasusübereinstimmung; die Wortstellung unterscheidet sich in Japanisch und Koreanisch
Pluralformen sind korrekt für das Gebietsschema — Russisch hat vier Pluralkategorien; Arabisch hat sechs; Englisch hat zwei
Genusübereinstimmung ist korrekt für Sprachen, in denen das Substantivgeschlecht Adjektiv- und Verbformen beeinflusst (Französisch, Spanisch, Deutsch)
Platzhalter ({name}, %s, {{count}}) rendern den korrekten eingesetzten Wert und werden nicht durch die Übersetzung beschädigt

Datums-, Zeit- und Kalenderformatierung

Datumsangaben verwenden das gebietsschemakorrekte Format (TT/MM/JJJJ für en-GB, MM/TT/JJJJ für en-US, JJJJ-MM-TT für ISO-Kontexte)
Die Zeit verwendet das 12- oder 24-Stunden-Format, wie für das Gebietsschema angemessen
Die Zeitzonenangabe ist für das Gebietsschema angemessen
Der Kalender-Wochenstart ist korrekt (Montag in den meisten europäischen Ländern, Sonntag in den USA)
Relative Zeit-Strings („vor 2 Stunden", „morgen") sind korrekt lokalisiert

Zahlen- und Währungsformatierung

Das Dezimaltrennzeichen ist korrekt (Punkt in en-US, Komma in de-DE, fr-FR)
Das Tausendertrennzeichen ist korrekt
Die Position des Währungssymbols ist korrekt (vor dem Betrag in en-US: $10.00; nach dem Betrag in einigen europäischen Gebietsschemata: 10,00 €)
Das Währungssymbol ist korrekt für das Gebietsschema — gehen Sie nicht davon aus, dass alle englischen Gebietsschemata USD verwenden
Die Prozentformatierung ist korrekt (75% in den meisten Gebietsschemata, %75 in einigen türkischen Kontexten)

Right-to-Left (RTL) Layout

Das Seitenlayout spiegelt korrekt — Navigation, Seitenleisten und Spalten wechseln auf die rechte Seite
Die Textausrichtung ist für RTL-Inhalte rechtsbündig
Die Button-Reihenfolge kehrt sich um — der primäre Aktionsbutton verschiebt sich in RTL-Layouts nach links
Symbole mit Richtungsbedeutung (Pfeile, Chevrons, Zurück-Buttons) spiegeln korrekt
Formularfeld-Beschriftungen und Eingaben sind korrekt ausgerichtet
Gemischte LTR/RTL-Inhalte (eine arabische Seite mit einem englischen Produktnamen) werden mit korrekter bidirektionaler Textverarbeitung gerendert

Unicode und Kodierung

Alle Zeichen der Zielschrift werden korrekt von Ende zu Ende dargestellt, durch die gesamte Pipeline: Datenbank, API, Rendering-Schicht
Keine Doppelkodierungs-Artefakte (Zeichen erscheinen als HTML-Entitäten oder escapte Sequenzen)
Eingabefelder akzeptieren und speichern Unicode-Zeichen der Zielschrift korrekt
Suche und Filterung funktionieren korrekt mit Unicode-Strings

Platzhalter- und Variablenhandhabung

Alle Platzhaltervariablen sind in übersetzten Strings vorhanden (kein fehlendes {name} oder extra {0})
Platzhalterwerte werden in der korrekten Reihenfolge eingesetzt — die Reihenfolge kann sich zwischen Sprachen ändern
Übersetzte Strings mit HTML-Markup bewahren die korrekte Tag-Struktur

Gebietsschemaspezifisches Funktionsverhalten

Die Sortierreihenfolge ist gebietsschemakonform (die schwedische alphabetische Reihenfolge unterscheidet sich von der ASCII-Sortierung)
Die Eingabevalidierung akzeptiert gebietsschemagerechte Formate (Telefonnummern, Postleitzahlen, Ausweisnummern)
Adressformulare erfassen Felder in der korrekten Reihenfolge und mit den korrekten Beschriftungen für das Zielland

Automatisierte Testansätze

Screenshot-Vergleich und visuelle Regression

Visuelles Regressionstesting erstellt Screenshots Ihrer Anwendung in jedem Gebietsschema und vergleicht sie mit einer Baseline. Unterschiede werden zur menschlichen Überprüfung markiert. Dies ist der effektivste automatisierte Ansatz, um UI-level-Lokalisierungsfehler in großem Maßstab zu erkennen.

Percy (von BrowserStack) integriert sich mit den meisten Browser-Automatisierungs-Frameworks und CI-Systemen. Sie konfigurieren es, um ganzseitige Screenshots oder Snapshots auf Komponentenebene zu erfassen. Für Lokalisierungstests ist der Workflow:

Führen Sie Ihre Test-Suite gegen die en-US-Baseline aus — bestätigen Sie die Baseline-Screenshots
Führen Sie dieselbe Suite mit aktiven Gebietsschemata de-DE, ja-JP, ar-SA und anderen aus
Percy markiert Layout-Unterschiede — Überlauf, Abschneidungen, Fehlausrichtungen — als visuelle Diffs
Saubere Diffs bestätigen, markierte untersuchen

Chromatic (von Storybook) wendet dasselbe Prinzip auf Tests auf Komponentenebene an. Wenn Sie Storybook zur Entwicklung von UI-Komponenten verwenden, erfasst Chromatic Screenshots jeder Story über Gebietsschemata hinweg. Dies ist besonders effektiv, um Abschneidungsprobleme auf Komponentenebene zu erkennen, bevor sie in ganzseitigen Tests auftauchen.

Der Schlüssel, damit visuelles Regressionstesting für die Lokalisierung funktioniert, ist Konsistenz: Die Testdaten müssen über alle Gebietsschema-Durchläufe hinweg identisch sein, und dynamische Inhalte (Zeitstempel, nutzergenerierte Inhalte) müssen gemockt oder eingefroren werden, sodass legitime Gebietsschema-Unterschiede die einzige Quelle von Screenshot-Variation sind.

Browser-Automatisierung mit Playwright und Cypress

Playwright und Cypress unterstützen beide Gebietsschema-Wechsel über Browser-Kontext-Konfiguration. In Playwright setzen Sie das Gebietsschema beim Erstellen eines Browser-Kontexts:

import { test, expect } from '@playwright/test';

const locales = ['en-US', 'de-DE', 'fr-FR', 'ar-SA', 'ja-JP'];

for (const locale of locales) {
  test(`checkout form renders correctly in ${locale}`, async ({ browser }) => {
    const context = await browser.newContext({
      locale,
      timezoneId: localeToTimezone[locale],
    });
    const page = await context.newPage();

    await page.goto('/checkout');

    // Auf keinen Textüberlauf prüfen
    const submitButton = page.locator('[data-testid="submit-button"]');
    const buttonBox = await submitButton.boundingBox();
    const buttonText = await submitButton.textContent();

    // Verifizieren, dass Text nicht abgeschnitten ist (Button-Text sichtbar, kein Ellipsis)
    await expect(submitButton).toBeVisible();
    await expect(submitButton).not.toHaveCSS('overflow', 'hidden');

    // Screenshot für visuellen Vergleich
    await expect(page).toHaveScreenshot(`checkout-${locale}.png`);
  });
}

In Cypress erfolgt das Gebietsschema-Wechseln typischerweise durch Setzen des Accept-Language-Headers oder durch Manipulation des Gebietsschema-Zustands der Anwendung vor jedem Test:

// cypress/support/commands.js
Cypress.Commands.add('setLocale', (locale) => {
  cy.intercept('**', (req) => {
    req.headers['Accept-Language'] = locale;
  });
});

// In einem Test
describe('Datumsformatierung', () => {
  ['en-US', 'en-GB', 'de-DE'].forEach((locale) => {
    it(`zeigt Datumsangaben korrekt für ${locale} an`, () => {
      cy.setLocale(locale);
      cy.visit('/dashboard');
      cy.get('[data-testid="last-login-date"]')
        .invoke('text')
        .should('match', expectedDatePattern[locale]);
    });
  });
});

Linting für hart kodierte Strings

Statische Analyse kann hart kodierte Strings erkennen, bevor sie eine Testumgebung erreichen. ESLint-Plugins wie eslint-plugin-i18next markieren String-Literale in JSX und JavaScript, die in Übersetzungsdateien extrahiert werden sollten:

# Plugin installieren
npm install --save-dev eslint-plugin-i18next

# .eslintrc
{
  "plugins": ["i18next"],
  "rules": {
    "i18next/no-literal-string": "error"
  }
}

Für Android markiert die Lint-Regel hardcoded-text im Android SDK String-Literale in XML-Layout-Dateien, die nicht in einer String-Ressourcen-Referenz enthalten sind. Für iOS können die SwiftLint-Regel nslocalizedstring_require_bundle und Drittanbieter-Linter nicht lokalisierte String-Literale markieren.

Das Ausführen dieser Lint-Prüfungen in CI stellt sicher, dass neue hart kodierte Strings in der Code-Review-Phase erkannt werden und nicht erst beim QA-Durchlauf.

Häufige Fehler bei Lokalisierungstests

Deutschsprachiger Textüberlauf

Deutsch bildet Komposita, die deutlich längere Wörter als ihre englischen Entsprechungen erzeugen. „Checkbox" wird zu „Kontrollkästchen" (17 Zeichen). „Settings" wird zu „Einstellungen" (13 Zeichen). „Downloads" bleibt „Downloads" — aber „Upload failed" wird zu „Upload fehlgeschlagen" (20 Zeichen vs. 13). Feststehende Buttons, Tab-Beschriftungen und Navigationselemente, die für englischen Text dimensioniert wurden, laufen in Deutsch regelmäßig über.

Praxisbeispiel: Ein Navigations-Tab mit einer festen Breite von 120px, der auf Englisch „Dashboard" anzeigt, wird „Instrumententafel" (das deutsche Äquivalent) abschneiden oder — wenn die UI Text umbricht — das einzeilige Tab-Layout auf zwei Zeilen aufbrechen.

RTL Button-Reihenfolge

In Links-nach-Rechts-Layouts platzieren Dialoge konventionell den primären Aktionsbutton rechts und die sekundäre Aktion (Abbrechen) links: [ Abbrechen ] [ Speichern ]. In Rechts-nach-Links-Layouts (Arabisch, Hebräisch) sollte diese Reihenfolge gespiegelt werden: [ Speichern ] [ Abbrechen ] — wobei „Speichern" links steht (das visuelle Rechts in der Leserichtung). Anwendungen, die die Textausrichtung umkehren, aber vergessen, die Button-Reihenfolge umzukehren, erzeugen Layouts, bei denen der primäre Aktionsbutton für RTL-Nutzer visuell auf der falschen Seite ist.

Verkettete Strings erzeugen ungültige Grammatik

Ein häufiges Muster in englisch entwickelten Anwendungen ist das Zusammensetzen von Sätzen aus Teilen:

// Annahme im Quellcode
const message = `${count} ${itemLabel} selected`;
// Erzeugt: "3 items selected"

Auf Russisch ändert sich das Wort für „element" je nach Zahl und grammatischem Fall: 1 nimmt „элемент", 2–4 nehmen „элемента", 5+ nehmen „элементов". Im Arabischen gibt es sechs Pluralkategorien. String-Verkettungen, die für Englischs Zwei-Plural-System funktionieren, erzeugen in Dutzenden von Sprachen grammatisch ungültige Ausgaben. Die Lösung ist die Verwendung des ICU-Nachrichtenformats oder der Plural-API der Plattform:

// ICU message format — korrekter Ansatz
t('items_selected', { count, defaultValue: '{count} items selected' });
// Mit gebietsschemaspezifischen Pluralregeln in der Übersetzungsdatei definiert

Falsche Pluralform

Eine subtilere Variante des Verkettungsfehlers: Die Anwendung verwendet das ICU-Pluralsystem, aber die Übersetzungsdatei stellt nur zwei Formen bereit (one und other) für eine Sprache wie Polnisch, die vier erfordert (one, few, many, other). Die Übersetzung besteht die Überprüfung, weil die Datei syntaktisch gültig ist, aber „5 elementów" wird als „5 element" für Zahlen angezeigt, die einer nicht behandelten Pluralkategorie zugeordnet sind.

Zeitzonen-Anzeigefehler

Eine Anwendung, die Zeitstempel auf dem Server in UTC formatiert und sich dann auf den Browser verlässt, um sie in der lokalen Zeit des Nutzers anzuzeigen, funktioniert beim Testen korrekt — wenn Tester und Server in derselben Zeitzone sind. Sie schlägt in der Produktion für Nutzer in anderen Zeitzonen fehl und tritt als Lokalisierungsfehler beim regionalen QA auf, obwohl es technisch ein Zeitzonenverarbeitungsfehler ist.

Wann testen?

In CI bei jedem Build

Pseudo-Lokalisierungsprüfungen, Linting auf hart kodierte Strings und automatisierter Screenshot-Vergleich gegen das Pseudo-Gebietsschema sollten in CI bei jedem Build ausgeführt werden. Diese Tests erkennen eine breite Klasse von Fehlern — Abschneidungen, Kodierung, hart kodierte Strings — ohne Übersetzungskosten und mit schnellen Feedback-Schleifen. Ein fehlschlagender Pseudo-Gebietsschema-Screenshot-Test ist für den Entwickler sichtbar, der die Änderung eingeführt hat, nicht für einen QA-Engineer, der den Build Tage später überprüft.

Nach jedem Übersetzungsimport

Wenn ein neuer Batch von Übersetzungen aus einem Translation-Management-System importiert wird, führen Sie die vollständige gebietsschemaspezifische Test-Suite für die betroffenen Sprachen aus. Dies erkennt Fälle, in denen ein Übersetzer einen korrekt übersetzten, aber ungewöhnlich langen String erstellt hat, ein Platzhalter versehentlich gelöscht wurde oder eine Übersetzung Sonderzeichen eingeführt hat, die eine Kodierungslücke aufdecken. Der automatisierte Test-Run nach dem Import sollte automatisch erfolgen — ausgelöst durch die Import-Pipeline, nicht manuell geplant.

Vor größeren Releases

Vor jedem größeren oder regionalen Release führen Sie einen menschlich geleiteten Lokalisierungs-Test-Durchlauf für hochpriorisierte Gebietsschemata durch. Dies umfasst linguistische Tests durch Muttersprachler, funktionale Tests gebietsschemaspezifischer Funktionen und eine Überprüfung aller UI-Flows, die sich seit dem vorherigen Release geändert haben. Hochfrequentierte Gebietsschemata (die Sprachen, die Ihre größten Nutzerpopulationen repräsentieren) sollten diesen vollständigen Durchlauf erhalten; niedrigfrequentierte Gebietsschemata erhalten zwischen größeren Releases möglicherweise nur automatisierte Abdeckung.

FAQ

Was ist der Unterschied zwischen Lokalisierungstests und Internationalisierungstests?

Internationalisierung (i18n) Testing überprüft, ob die Anwendung für die Unterstützung mehrerer Gebietsschemata gebaut ist — dass sie Gebietsschema-APIs korrekt verwendet, alle Strings externalisiert, Unicode-Eingaben verarbeitet und hart kodierte Gebietsschema-Annahmen vermeidet. Lokalisierung (l10n) Testing überprüft, ob ein bestimmter lokalisierter Build für ein bestimmtes Zielgebietsschema korrekt funktioniert. i18n Testing findet einmal statt (beim Aufbau der Grundlage); l10n Testing findet für jedes Gebietsschema statt, das Sie ausliefern.

Brauche ich Muttersprachler für Lokalisierungstests?

Für linguistische Tests — die Überprüfung von Übersetzungsqualität, Ton und kultureller Angemessenheit — ja. Für funktionale und kosmetische Lokalisierungstests sind keine Muttersprachler erforderlich. Ein QA-Engineer, der kein Deutsch spricht, kann trotzdem überprüfen, ob deutschsprachiger Text nicht aus einem Button überläuft, ob Datumsangaben im korrekten Format angezeigt werden, und ob das RTL-Layout für Arabisch korrekt gespiegelt wird. Automatisierbare Prüfungen erfordern keine Sprachkenntnisse.

Wie viele Gebietsschemata sollte ich in CI testen?

Führen Sie Pseudo-Lokalisierung und Linting auf hart kodierte Strings bei jedem Build aus, unabhängig von der Gebietsschema-Anzahl. Für vollständige automatisierte Gebietsschema-Tests ist ein praktischer Ansatz, einen repräsentativen Satz zu testen: ein Rechts-nach-Links-Gebietsschema (Arabisch oder Hebräisch), ein Gebietsschema mit langer Ausdehnung (Deutsch), ein CJK-Gebietsschema (Japanisch oder Chinesisch) und ein Gebietsschema mit nicht-lateinischer Schrift (wenn Sie eines unterstützen). Dies deckt die vier Hauptkategorien von Lokalisierungsfehlern ab, ohne bei jedem Build jedes Gebietsschema zu testen.

Was ist der beste Weg, fehlende Übersetzungen vor dem Release zu erkennen?

Der zuverlässigste Ansatz ist, den Build fehlschlagen zu lassen, wenn ein Übersetzungsschlüssel in der Quellsprachendatei in einer als vollständig markierten Gebietsschemadatei fehlt. Die meisten i18n-Frameworks unterstützen dies durch Konfiguration (i18next hat missingKeyHandler; ICU-basierte Systeme können Vollständigkeit mit Befehlszeilen-Tools validieren). Visuelle Regressionstests gegen jedes Gebietsschema machen fehlende Übersetzungen auch als sichtbare Unterschiede sichtbar — wenn ein String in einem deutschen Build auf Englisch zurückfällt, zeigt der Screenshot englischen Text und der Diff wird markiert.

Wie sollte ich priorisieren, welche Gebietsschemata am gründlichsten getestet werden?

Priorisieren Sie nach Nutzerauswirkung: Gebietsschemata mit der höchsten aktiven Nutzerpopulation, Gebietsschemata für Märkte, in denen Ihr Unternehmen regulatorische Verpflichtungen hat, und Gebietsschemata, die sich strukturell am stärksten von Ihrer Quellsprache unterscheiden (RTL-, CJK- und komplexe Plural-Gebietsschemata erzeugen fast immer Fehler, die lateinschrift-Gebietsschemata nicht produzieren). Innerhalb dieser Prioritäts-Gebietsschemata wenden Sie den vollständigen Testing-Stack an — automatisiert, visuelle Regression und menschliche Überprüfung.

Fazit

Lokalisierungstests sind kein Schritt, der nach Abschluss der Übersetzung stattfindet. Es ist eine Engineering-Disziplin, die beginnt, wenn ein Entwickler den ersten externalisierten String schreibt, und sich durch jeden Release zieht. Die effektivsten Programme behandeln Pseudo-Lokalisierung als erstklassige CI-Prüfung, führen automatisierte Gebietsschema-Tests nach jedem Übersetzungsimport durch und reservieren menschliche QA-Aufwände für die sprachlichen und kulturellen Nuancen, die Automatisierung nicht beurteilen kann.

Der gemeinsame Nenner jedes Lokalisierungsfehlers — der Deutsche Überlauf, das fehlerhafte RTL-Layout, der grammatisch ungültige Plural, das falsche Datumsformat — ist eine Annahme, die in der Quellsprache gemacht wurde und erst von einem Gebietsschema aufgedeckt wurde. Pseudo-Lokalisierung stellt diese Annahmen automatisch in Frage, bevor ein Übersetzer beteiligt ist. Eine strukturierte Checkliste stellt sie während QA systematisch in Frage. Automatisierter Screenshot-Vergleich setzt sie kontinuierlich in Ihrer Pipeline durch.

Beginnen Sie mit Pseudo-Lokalisierung, wenn Sie sie noch nicht verwenden. Fügen Sie die Checkliste Ihrem Release-Prozess hinzu. Integrieren Sie Playwright- oder Cypress-Gebietsschema-Tests in CI. Diese drei Schritte werden den Großteil der Lokalisierungsfehler zu einem Bruchteil der Kosten erkennen, sie erst in der Produktion zu finden.

Referenzen

Zuletzt aktualisiert: März 2026

Lokalisierungstests: Ein QA-Leitfaden für mehrsprachige Anwendungen