Internationalisierung (i18n) automatisiert testen

1. Warum i18n-Fehler oft erst spät und beim falschen Publikum auffallen

Die übliche Entwicklungs- und Reviewpraxis findet fast ausschliesslich in der Standardsprache eines Projekts statt, weshalb ein fehlender Übersetzungsschlüssel, ein falsch interpolierter Platzhalter oder ein zu kurz bemessenes Textfeld für längere Übersetzungen in dieser Sprache niemals auftaucht und dementsprechend auch von niemandem im Team bemerkt wird, obwohl derselbe Fehler in einer anderen Sprachversion für echte Kundinnen und Kunden sofort sichtbar ist.

Diese strukturelle Asymmetrie zwischen der intensiv geprüften Standardsprache und den selten manüll kontrollierten weiteren Sprachversionen macht i18n-Fehler zu einer der häufigsten Ursachen für schlechte Nutzererfahrung in internationalen Onlineshops, gerade weil sie im normalen Entwicklungsalltag praktisch unsichtbar bleiben, bis eine Kundin oder ein Kunde aus dem betroffenen Land sie zufällig meldet.

2. Store-Views und Sprachumschaltung automatisiert testen

Ein grundlegender i18n-Test iteriert über alle konfigurierten Magento-Store-Views, ruft für jede Store-View dieselbe zentrale Seite auf, etwa die Produktdetailseite eines Referenzprodukts, und prüft, dass die Seite tatsächlich in der erwarteten Sprache und mit der korrekten, store-view-spezifischen Basis-URL ausgeliefert wird, statt versehentlich auf den Inhalt der Standardsprache zurückzufallen.

Ein zusätzlicher, praxisrelevanter Testfall prüft das Fallback-Verhalten für Inhalte, die in einer bestimmten Store-View bewusst oder versehentlich nicht individüll gepflegt wurden, etwa einen CMS-Block ohne store-view-spezifische Übersetzung, wobei ein korrekt konfiguriertes System auf den Inhalt der Standardsprache zurückfallen sollte, statt den Block komplett leer oder mit einem sichtbaren Fehler anzuzeigen.

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

const storeViews = [
  { code: 'de_de', expectedLang: 'de', expectedText: 'In den Warenkorb' },
  { code: 'en_us', expectedLang: 'en', expectedText: 'Add to Cart' },
  { code: 'fr_fr', expectedLang: 'fr', expectedText: 'Ajouter au panier' },
];

for (const view of storeViews) {
  test(`Produktseite in Store-View ${view.code} zeigt korrekte Sprache`, async ({ page }) => {
    await page.goto(`/${view.code}/catalog/product/view/id/123`);
    await expect(page.locator('html')).toHaveAttribute('lang', view.expectedLang);
    await expect(page.locator('[data-testid="add-to-cart"]')).toHaveText(view.expectedText);
  });
}

3. Fehlende Übersetzungen automatisiert erkennen

Eine besonders wirkungsvolle, aber selten genutzte Testtechnik prüft nicht einzelne, konkrete Textstellen, sondern durchsucht den gesamten gerenderten Seiteninhalt systematisch nach unaufgelösten Übersetzungsschlüsseln, die typischerweise an einem erkennbaren Muster wie eckigen Klammern oder einem Punkt-Notation-Format erkennbar bleiben, wenn ein Übersetzungssystem einen fehlenden Schlüssel unverändert statt der eigentlich erwarteten, übersetzten Zeichenkette ausgibt.

Dieser generische Scan lässt sich auf jede Seite eines automatisierten Crawl-Durchlaufs anwenden, statt für jede einzelne Textstelle eine eigene, explizite Assertion schreiben zu müssen, und deckt dadurch systematisch auch Übersetzungslücken auf, die bei einer rein manüllen, stichprobenartigen Prüfung schlicht übersehen würden, weil niemand jede einzelne Seite in jeder Sprache tatsächlich durchklickt.

Ergänzend dazu lohnt sich ein regelmässig laufender, separater Abgleich zwischen der Menge aller in der Standardsprache tatsächlich verwendeten Übersetzungsschlüssel und der Menge der in jeder Zielsprache tatsächlich gepflegten Übersetzungen, um veraltete, nicht mehr benötigte Einträge ebenso aufzudecken wie neu hinzugekommene Schlüssel, die in einer Zielsprache schlicht noch fehlen.

test('Kategorieseite enthält keine unaufgelösten Übersetzungsschlüssel', async ({ page }) => {
  await page.goto('/fr_fr/catalog/category/view/id/5');
  const bodyText = await page.locator('body').innerText();

  const unresolvedKeyPattern = /\[\[.+?\]\]|\btranslate\.[a-z_]+\b/;
  expect(bodyText).not.toMatch(unresolvedKeyPattern);
});

4. Locale-abhängige Währungsformate prüfen

Währungsformatierung unterscheidet sich zwischen Locales nicht nur im verwendeten Symbol, sondern auch in Position des Symbols, Tausendertrennzeichen und Dezimaltrennzeichen, weshalb ein und derselbe Preis in unterschiedlichen Sprachversionen vollkommen unterschiedlich dargestellt werden muss, etwa als 1.234,56 EUR in der deutschen und als EUR 1,234.56 in der amerikanischen Darstellung, obwohl der zugrunde liegende Zahlenwert identisch bleibt.

Ein gezielter Test rendert einen bewusst gewählten, eindeutigen Testpreis für mehrere Locales und vergleicht die dargestellte Zeichenkette exakt gegen die für diese Locale erwartete Formatierung, wodurch sich sowohl ein falsch konfiguriertes Locale-Format als auch ein Regressionsfehler durch eine spätere Änderung an der Preisformatierungslogik zuverlässig aufdecken lässt.

In Magento-Shops mit mehreren Währungen pro Store-View, etwa einer zusätzlich wählbaren US-Dollar-Ansicht innerhalb eines europäischen Stores, sollte der Test zusätzlich prüfen, dass ein Wechsel der Währung unabhängig von der aktuell eingestellten Sprache korrekt funktioniert, da sich Sprache und Währung in der Konfiguration überschneiden, aber technisch unabhängig voneinander sind und sich entsprechend auch unabhängig voneinander fehlerhaft verhalten können.

5. Locale-abhängige Datumsformate testen

Ähnlich wie bei Währungsformaten unterscheidet sich die Darstellung eines Datums stark zwischen Locales, etwa Tag-Monat-Jahr im europäischen und Monat-Tag-Jahr im amerikanischen Format, wobei ein vertauschtes Format bei mehrdeutigen Datumswerten wie dem dritten Januar zu einer völligen Fehlinterpretation des Datums führen kann, was besonders bei Liefertermin- oder Bestelldatumsanzeigen zu handfester Verwirrung bei Kundinnen und Kunden führt.

Ein Test fixiert dafür sinnvollerweise ein konkretes, eindeutiges Testdatum, etwa den 25. Dezember, rendert es in jeder relevanten Locale und prüft die resultierende Zeichenkette exakt, statt sich auf ein mehrdeutiges Datum zu verlassen, bei dem ein vertauschtes Format zufällig trotzdem ein plausibel aussehendes Ergebnis liefern und der Fehler dadurch unbemerkt bleiben würde.

6. Automatisierte Screenshot-Vergleiche pro Sprache

Längere Übersetzungen, etwa im Deutschen oder Finnischen, sprengen häufig ein Layout, das ursprünglich für die kürzere englische Standardsprache entworfen wurde, ein Problem, das sich rein textüll kaum zuverlässig erkennen lässt, aber durch einen Visual-Regression-Test (siehe den separaten Artikel zu diesem Thema) pro Sprachversion sichtbar wird, sobald ein Button-Text plötzlich umbricht oder ein Navigationselement seine Zeilenhöhe unerwartet ändert.

Ein sinnvoller, ressourcenschonender Kompromiss beschränkt visülle Prüfungen pro Sprache auf wenige, tatsächlich kritische Seitentypen, etwa Kopfzeile, Produktdetailseite und Checkout, statt jede einzelne Seite in jeder Sprache visüll zu vergleichen, was den Pflegeaufwand der Screenshot-Baselines in einem vertretbaren Rahmen hält.

Bei rechts-nach-links geschriebenen Sprachen wie Arabisch oder Hebräisch reicht ein reiner Screenshot-Vergleich allein oft nicht aus, da zusätzlich gezielt geprüft werden sollte, ob die gesamte Seite tatsächlich korrekt gespiegelt wird, einschliesslich Navigationsreihenfolge, Icon-Ausrichtung und Textfluss, statt sich auf eine rein optische Ähnlichkeit mit der linksbündigen Standardversion zu verlassen.

7. CI-Strategie: eine Sprachmatrix statt Einzeltests

Statt für jedes einzelne Feature separate, sprachspezifische Testfälle zu schreiben, definiert eine effiziente CI-Strategie eine zentrale Sprachmatrix, über die die wichtigsten, gemeinsamen Testfälle automatisch für jede konfigurierte Sprache wiederholt ausgeführt werden, wodurch neue Sprachen sich mit minimalem Zusatzaufwand in die bestehende Teststruktur einfügen lassen.

Um die CI-Laufzeit trotz mehrfacher Ausführung derselben Tests in einem vertretbaren Rahmen zu halten, lohnt es sich, nur eine kleine, sorgfältig ausgewählte Kernmenge an Tests tatsächlich für jede Sprache zu wiederholen, während der Großteil der funktionalen Tests weiterhin nur in der Standardsprache läuft und die übrigen Sprachen ausschliesslich für die in diesem Artikel beschriebenen i18n-spezifischen Prüfungen genutzt werden.

8. Pluralisierungsregeln unterschiedlicher Sprachen automatisiert testen

Während im Englischen und Deutschen lediglich zwischen Singular und Plural unterschieden wird, verlangen Sprachen wie Polnisch oder Russisch je nach genauer Anzahl unterschiedliche grammatikalische Formen, etwa eine eigene Form für die Zahl Eins, eine weitere für kleine Zahlen wie Zwei bis Vier und eine dritte, allgemeine Form für alle übrigen Zahlen, weshalb eine korrekte Pluralisierung deutlich komplexer ist als ein simples Wenn-Dann für Singular und Plural.

Ein gezielter Test prüft deshalb nicht nur einen einzelnen Beispielwert, sondern eine bewusst gewählte Reihe von Grenzwerten wie null, eins, zwei, fünf und einundzwanzig Artikeln im Warenkorb, um sicherzustellen, dass die Pluralisierungsfunktion für jede dieser Zahlen in jeder unterstützten Sprache tatsächlich die grammatikalisch korrekte Form auswählt, statt nur den einfachsten, häufigsten Fall von genau einem Artikel abzudecken.

9. i18n-Testansätze im Überblick

Die folgende Tabelle fasst die vorgestellten Testansätze für Internationalisierung zusammen.

10. Zusammenfassung

11. FAQ: i18n-Testing: Das Wichtigste auf einen Blick