Die harte Arbeit der Internationalisierung einer Webanwendung ist erledigt. Strings wurden extrahiert, Übersetzungen verarbeitet, und nun gilt es zu prüfen, ob alles für den Zielmarkt funktioniert. Die gute Nachricht: Ein großes, dediziertes QA-Setup ist nicht nötig, um die häufigsten Lokalisierungsprobleme zu erkennen. Lokalisierungstests lassen sich durchführen und die Grundlagen direkt im Browser validieren.
Dieser kurze Leitfaden richtet sich an Entwickler und Hobby-Coder, die ihre Lokalisierungsarbeit schnell überprüfen müssen. Wir überspringen die Theorie und gehen direkt zu den praktischen Schritten, wie sich Browser-Entwicklertools zum Testen lokalisierter Web-Apps nutzen lassen. Diese Checks helfen dabei, peinliche UI-Bugs, Formatierungsfehler und andere Probleme zu entdecken, bevor die Zielgruppe darauf stößt.
4 Schritte zum Testen der Lokalisierung im Browser
Die leistungsstärkste Funktion für diese Aufgabe ist in den Entwicklertools jedes modernen Browsers integriert. Ob Chromium-basiert (wie Google Chrome und Edge), Gecko (Firefox) oder WebKit (Safari) – alle bieten Möglichkeiten, das Verhalten eines Nutzers aus einem anderen Teil der Welt zu simulieren. Da Chromium-basierte Browser am weitesten verbreitet sind, nutzen wir in den folgenden Beispielen Chrome.
In Google Chrome:
Chrome DevTools bietet ein „Sensors"-Panel, das die geografische Position und das System-Locale überschreiben kann. Das ist der schnellste Weg, um zu testen, wie die Web-App auf verschiedene internationale Einstellungen reagiert.
- DevTools öffnen: Rechtsklick auf die Seite und „Untersuchen" wählen.
- Sensors-Tab öffnen: Drücken Sie
Befehl+Umschalt+P(Mac) oderStrg+Umschalt+PWindows), um das Command Menu zu öffnen. „Sensors" eingeben und „Show Sensors" auswählen. - Ort und Locale überschreiben:
- Ort: Das Dropdown nutzen, um eine voreingestellte Stadt wie Tokyo oder London auszuwählen. Damit lassen sich Features testen, die von der geografischen Position abhängen.
- Locale: Das ist am wichtigsten. Es lässt sich ein anderer Locale-Code wählen, wie
en-USfür Englisch (Großbritannien) oderja-JPfür Japanisch (Japan). Dies simuliert denAccept-Language-Header des Browsers und die Spracheinstellungen des Geräts.
- Neu laden und prüfen: Mit dem neuen Locale die Seite neu laden. Nun auf Änderungen achten. Hat sich der UI-Text auf die neue Sprache umgestellt? Ist das Datumsformat für die Region korrekt (z. B. MM/TT/JJJJ für
en-US)? Stimmen Zeitformat und Währungssymbol? So lässt sich schnell prüfen, ob die Internationalisierungsbibliothek die Browser-Einstellungen korrekt erfasst.
Was zu prüfen ist:
- UI-Text: Offensichtlich, aber wichtig. Erscheint der gesamte Text in der Zielsprache?
- Textexpansion/-kontraktion: Darauf achten, dass das Layout nicht bricht. Text in manchen Sprachen ist deutlich länger als in anderen – finnische Übersetzungen können zum Beispiel viel Platz brauchen und Container sprengen.
- Formatierung: Besondere Aufmerksamkeit auf Zahlen-, Datums- und Zeitformate richten. Hier verstecken sich viele Lokalisierungsprobleme.
- Hartcodierte Strings: Wenn ein Text beim Locale-Wechsel unverändert bleibt, liegt wahrscheinlich ein hartcodierter String vor, der nicht internationalisiert wurde.
Ein wichtiger Testfall: RTL-Layouts überprüfen
Beim Testen der Lokalisierung für Rechts-nach-Links-Sprachen wie Hebräisch oder Urdu muss das RTL-Layout der App geprüft werden. Dies lässt sich im Inspector erzwingen, ohne die gesamte Browser-Konfiguration zu ändern.
- Das Elements -Panel in DevTools öffnen.
- Den
<html>-Tag oben im DOM-Baum finden. - Das Attribut
dir="rtl"hinzufügen.
Das gesamte Seitenlayout sollte sich umkehren. Dieser schnelle Test deckt sofort CSS-Probleme auf, bei denen left und right statt logischer Properties wie start und endverwendet wurden. Es ist ein kritischer Schritt, um sicherzustellen, dass die UI für einen großen Teil der globalen Zielgruppe nicht kaputt geht.
Best Practice: Die Web-App in langsamen Netzwerken testen
Eine lokalisierte Version einer Webanwendung muss oft sprachspezifische Ressourcen laden. Bei einer langsamen Verbindung kann dies zu einem kurzen Aufblitzen von unübersetztem Content führen, bei dem die Standardsprache kurz sichtbar ist, bevor die lokalisierte Version erscheint.
Dies lässt sich im Network -Tab der Browser-DevTools simulieren.
- Zum „Network"-Tab wechseln.
- Das Dropdown „No throttling" finden und auf „Slow 3G" ändern.
- Die Seite neu laden.
Beobachten, wie der Content lädt. Falls z. B. deutschsprachiger Text eine Sekunde lang zu sehen ist, bevor er zu Spanisch wechselt, muss möglicherweise die Ladestrategie angepasst werden, um eine bessere User Experience zu bieten.
Anmerkung zu automatisierten Lokalisierungstests
Diese manuellen Browser-Checks eignen sich hervorragend für schnelle sog. Sanity Checks und Debugging. Für einen robusten Testprozess empfiehlt sich jedoch mittelfristig die Automatisierung. Tools wie Selenium oder Cypress lassen sich nutzen, um diese Checks zu skripten. Beispielsweise lässt sich ein Testfall schreiben, der den Browser startet, den Accept-Language Header für ein bestimmtes Locale setzt und dann prüft, ob ein bestimmtes Element auf der Seite den korrekten übersetzten Text enthält.
Automatisierte Tests sind besonders nützlich für Regressionstests, damit neue Code-Commits nicht versehentlich ein zuvor funktionierendes lokalisiertes Feature zerstören. Während manuelle Tests sich gut zum Erkennen visueller Probleme eignen, ermöglicht Testautomatisierung die Skalierung der Lokalisierungsbemühungen.
Häufig gestellte Fragen
Wie unterscheidet sich das von linguistischen Tests?
In diesem Leitfaden liegt der Fokus auf der technischen Umsetzung. Linguistische Tests werden dagegen von Muttersprachlern durchgeführt, um zu überprüfen, ob die Übersetzung korrekt ist, kulturell angemessen und den richtigen Ton trifft.
Warum wechselt die Web-App die Sprache nicht, wenn das Locale in DevTools geändert wird?
Das passiert oft, wenn die Anwendungslogik eine andere Quelle für das Locale priorisiert. Beispielsweise könnte die Sprachpräferenz aus einem Benutzerprofil gelesen werden, das in einem Cookie oder localStorage gespeichert ist. Am besten im Inkognito-Fenster testen, um sicherzustellen, dass die Experience für neue Nutzer getestet wird.
Lässt sich die Lokalisierung von mobilen Apps so testen?
Nicht direkt. Die hier beschriebenen Techniken gelten für eine Webanwendung, die in einem Desktop-Browser läuft. Chrome DevTools hat jedoch einen Geräte-Emulator, der dabei hilft zu sehen, wie die lokalisierte UI der responsiven Web-App auf verschiedenen Bildschirmgrößen aussieht. Für eine native mobile App wären Emulatoren in Xcode (iOS) oder Android Studio erforderlich. Emulatoren in Xcode (iOS) oder Android Studio.
Dev Tools für Lokalisierungstests: ein Fazit
Es braucht kein Lokalisierungs-Profi, um effektive Checks für Web-Apps durchzuführen. Mit den leistungsstarken Tools, die bereits im Browser integriert sind, lassen sich die häufigsten Lokalisierungsprobleme in Bezug auf UI, Formatierung und Funktionalität schnell erkennen und beheben.
Werden browserbasierte Checks zu einem regelmäßigen Teil des Entwicklungsprozesses, hilft das beim Launch eines professionelleren Softwareprodukts für ein internationales Publikum. Es ist eine einfache Methode mit großer Wirkung, um die UX für Zielnutzer in verschiedenen Locales zu verbessern und sicherzustellen, dass sich Ihre Lokalisierungsbemühungen auszahlen.
