Testen der Lokalisierung mobiler Apps: Die iOS- und Android-Checkliste für weltweite Veröffentlichungen

Ihre App funktioniert einwandfrei auf Englisch. Dann bucht das Marketing einen Launch in Deutschland, Japan und Brasilien, und plötzlich wird der „Weiter“-Button zu „Weitermachen“, die Push-Benachrichtigung trifft um 3 Uhr morgens Ortszeit ein, und die App-Store-Screenshots zeigen immer noch US-Dollar-Preise. Das ist kein Übersetzungsproblem. Es ist ein Mobile-QA-Problem, und es sieht überhaupt nicht wie das QA aus, das Sie für den englischen Build durchgeführt haben.

Mobile-App-Lokalisierungstesting verifiziert, dass eine übersetzte App auf iOS- und Android-Geräten in jedem Zielmarkt korrekt gerendert wird, funktioniert und gefunden wird. Dieser Artikel konzentriert sich darauf, was sich tatsächlich ändert, wenn Lokalisierungs-QA den Desktop verlässt und auf ein Telefon wechselt: die Plattform-APIs, die zwei Stores, den Push-Payload, die Tastatur und die physische Gerätematrix. Die allgemeinen Definitionen und der End-to-End-Prozess werden separat in unserem Überblick über Lokalisierungs-QA-Testing behandelt. Alles darunter ist nur für Mobile.

Der Einsatz ist es wert, benannt zu werden. Sensor Tower berichtet, dass der globale In-App-Kaufumsatz im Jahr 2025 167 Milliarden Dollar erreichte, ein Plus von 10,6 % im Jahresvergleich, getrieben durch nicht-englischsprachige Märkte in Westeuropa, LATAM und APAC. Ein Lokalisierungsfehler in einem Top-Markt schlägt sich direkt in der Umsatzzeile nieder.

Was wir im Mobile-Lokalisierungs-QA prüfen

Übersetzungsqualität ist eine Eingabe für Lokalisierungs-QA, und für sich allein deckt sie vielleicht ein Viertel dessen ab, was kaputtgehen kann. Wenn ein Build auf unseren Geräten landet, betrachten wir vier Oberflächen gleichzeitig, und ein Fehler in einer davon kann einen Launch zum Scheitern bringen. Hier findet auch der Großteil der Arbeit in unserem Lokalisierungstest-Service statt.

Sprachliche Genauigkeit im Kontext

Eine Zeichenkette, die in einer Tabelle perfekt klingt, kann falsch sein, sobald sie in einem Button sitzt. „Speichern“, übersetzt als das spanische „Guardar“, ist auf einer Einstellungsseite in Ordnung und auf einem Warenkorb verwirrend, wo „Guardar“ „für später aufbewahren“ statt „betätigen“ impliziert. Unsere Tester verifizieren Zeichenketten in ihrem tatsächlichen UI-Kontext, auf einem echten Bildschirm, mit echten durchfließenden Daten. Platzhalter wie {username} und {count} erhalten besondere Aufmerksamkeit, weil eine defekte Variable oft wie ein Tippfehler aussieht, bis jemand bemerkt, dass sie sich nie auflöst.

UI-Integrität nach dem Einfügen der Zeichenketten

Übersetzter Text hat eine Länge. Deutsch ist etwa 30 % länger als Englisch, Finnisch liegt knapp dahinter, und CJK-Schriften beanspruchen weniger horizontalen Platz, haben aber eine höhere Zeilenbreite. Auf einem 375-Pixel-iPhone-Canvas bricht dieser Unterschied entweder elegant um oder zerstört Tab-Bars, Nav-Header und Call-to-Action-Buttons. Wir prüfen Text-Trunkierung, Button-Überlappung, Safe-Area-Kollisionen auf Geräten mit Notch und wie das Layout Dynamic Type auf iOS und Font Scale auf Android übersteht.

Locale-bewusstes Verhalten

Daten, Währungen, Telefonnummernformate, Maßeinheiten und sogar die Sortierreihenfolge ändern sich mit der Region des Nutzers. Ein Preis, der in Deutschland “1,000.00 EUR” anzeigt, sollte lokal als “1.000,00 €” gerendert werden, mit dem Symbol nach der Zahl. Auf iOS und Android 13 und höher ist die Region von der Sprache unabhängig, sodass ein Nutzer die App auf Englisch lesen kann, während er metrische Einheiten und 24-Stunden-Zeit erwartet. Hier wird Lokalisierungstesting für mobile Anwendungen nicht offensichtlich: der falsche Formatter ist ein funktionaler Fehler.

Store-Oberflächen, die Nutzer vor der Installation sehen

Die erste lokalisierte Oberfläche, die die meisten Nutzer treffen, ist die Store-Listing, nicht die App. Titel, Untertitel, Beschreibung, Screenshots und Vorschau-Video müssen mit der In-App-Sprache übereinstimmen, in der sie landen, nachdem sie auf Installieren getippt haben. Wenn die App-Store-Seite Deutsch verspricht und die App auf Englisch öffnet, füllt sich der Bewertungsbereich innerhalb von 48 Stunden mit Ein-Stern-Beschwerden.

Wo iOS- und Android-Lokalisierung auseinandergehen

Android hält bis 2026 rund 71–73 % der globalen Smartphone-Lieferungen, während iOS den Großteil der Verbraucher-App-Ausgaben ausmacht, laut IDCs Worldwide Quarterly Mobile Phone Tracker. Sie brauchen beides, und die beiden Plattformen handhaben Locale auf wirklich unterschiedliche Weise.

iOS-Locale-Mechanik

iOS speichert Übersetzungen in .strings-Dateien für flache Schlüssel-Wert-Paare und .stringsdict-Dateien für Pluralformen und Geschlechtsformen. Info.plist deklariert, welche Locales das Bundle über CFBundleLocalizations unterstützt. NSLocalizedString ruft die richtige Zeichenkette zur Laufzeit basierend auf den bevorzugten Sprachen des Nutzers ab, aufgelöst durch das Bundle. Seit iOS 13 können Nutzer in Einstellungen → App → Sprache eine andere Sprache pro App auswählen, ohne das gesamte Gerät zu ändern, was bedeutet, dass QA während der Sitzung Sprachen wechseln und verifizieren muss, dass gecachte Zeichenketten aktualisiert werden.

Android-Locale-Mechanik

Android verwendet qualifizierte Ressourcenordner: values/, values-fr/, values-b+es+419/ für lateinamerikanisches Spanisch. Zeichenketten leben in strings.xml, Pluralformen in plurals.xml, und Android durchläuft eine Fallback-Kette, wenn ein Locale fehlt. Seit Android 13 (API 33) ermöglichen LocaleManager und AppCompatDelegate.setApplicationLocales() eine sprachliche Auswahl pro App. Rechts-nach-links-Unterstützung erfordert android:supportsRtl=”true” im Manifest und start/end Layout-Attribute statt left/right.

Eine schnelle Gegenüberstellung für Ihr QA-Whiteboard:

Die nur-Mobile-QA-Checkliste

Hier sind sechs Prüfungen, die nur auf einem Telefon wichtig sind. Überspringen Sie eine davon, und der Launch wird es zeigen. Die folgenden Abschnitte variieren in der Form, weil die Prüfungen selbst es tun; einige passen in Prosa, und einige gehören in eine Liste.

Texterweiterung auf einem 375-Pixel-Canvas

Pseudo-lokalisieren Sie, bevor die echten Übersetzungen eintreffen. Ersetzen Sie englische Zeichenketten durch verlängerte lateinische Varianten („Sëttîngß“ statt „Settings“), um Layout-Stress in jedem Build zu erzwingen. Querausrichtung, Split-View auf iPad und Font-Scale auf 200 % für Barrierefreiheit verifizieren. Buttons, die auf Englisch eng aussehen, werden am Tag, an dem Übersetzungen eintreffen, auf Deutsch brechen, und dann ist der Sprint vorüber.

RTL-Layout auf Touch-UI

Arabisch, Hebräisch, Urdu und Persisch drehen die gesamte Schnittstelle um. Navigationsgesten kehren sich um, Chevrons spiegeln sich, Fortschrittsbalken füllen sich vom entgegengesetzten Rand, und Video-Scrubber bewegen sich in die entgegengesetzte Richtung. Symbole, die Bewegung implizieren, müssen gespiegelt werden, während Markenzeichen und Logos so bleiben, wie sie sind. Verifizieren Sie, dass das Gerät tatsächlich auf Arabisch eingestellt ist, und testen Sie die Oberflächen, die die meisten Teams vergessen: Transaktionsverlauf, Chat-Nachrichten-Ausrichtung, Formularvalidierungsfehler und alle benutzerdefinierten Diagramme.

Push-Benachrichtigungen pro Locale

Push-Benachrichtigungs-Lokalisierung bricht auf Weisen, die ohne dedizierte Tests schwer zu erfassen sind. APNs unterstützt loc-key und loc-args, und FCM unterstützt title_loc_key und body_loc_args, die beide dem Betriebssystem ermöglichen, Benachrichtigungen in der aktuellen Sprache des Geräts zu rendern, statt in der Sprache, die der Server zur Sendezeit angenommen hat. Das ist wichtig, weil ein Nutzer die App-Sprache ändern kann, nachdem er seinen Push-Token registriert hat. Tester sollten verifizieren:

• Trunkierung des Benachrichtigungs-Body auf dem Sperrbildschirm, ca. 60 Zeichen auf iOS und 65 auf Android, je nach Gerät.
• Zeitbasierte Sends richten sich nach der Zeitzone des Empfängers statt nach UTC. Ein „Guten Morgen“-Push, der für 8 Uhr UTC geplant ist, trifft Tokio um 17 Uhr.
• Ruhestunden-, Nicht-Stören- und Fokus-Modus-Verhalten pro Region.
• Rich-Notification-Bilder mit locale-spezifischem Inhalt, wenn verwendet.

OS-Level-Formatter, keine fest kodierten Zeichenketten

Überall, wo Sie ein Datum, eine Währung, eine Telefonnummer oder eine Maßeinheit in der UI sehen, verifizieren Sie, dass es durch den Plattform-Formatter geht. Auf iOS bedeutet das DateFormatter, NumberFormatter, und MeasurementFormatter. Auf Android, DateFormat.getDateInstance() und NumberFormat.getCurrencyInstance(). Fest kodierte Formatierung wie String.format(“$%.2f”, price) ist die häufigste Quelle von Locale-Fehlern und eine der einfachsten, die im Code-Review zu erkennen sind, bevor sie jemals QA erreichen.

Tastaturen, Autokorrektur und Diktat

Japanische, chinesische und koreanische IMEs ändern die Höhe des Eingabefelds, wenn die Vorschlagsleiste erscheint, was einen Absende-Button auf kleineren Bildschirmen hinter der Tastatur verstecken kann. Kyrillisch und Devanagari benötigen andere Zeichenvalidierungs-Regex als lateinische Schriften. Autokorrektur kann stillschweigend einen Eigennamen in einer Sprache verstoppeln und ihn in einer anderen unberührt durchlassen. Testen Sie jedes Formularfeld mit der tatsächlichen Tastatur, die der Zielnutzer verwenden wird, nicht dem englischen Standard.

Locale-Wechsel auf dem Gerät ohne Neustart

Sowohl iOS 13+ als auch Android 13+ erlauben Nutzern, die App-Sprache zu wechseln, ohne das Gerät neu zu starten. Wenn Ihre App Zeichenketten beim Start cachet und sie nie neu liest, bleibt die Hälfte der UI in der alten Sprache, bis der Nutzer die App zwangsweise beendet. Wechseln Sie die Sprachen während der Sitzung in QA, navigieren Sie durch jeden wichtigen Flow und bestätigen Sie, dass jeder Bildschirm aktualisiert. Dieser Fehler ist häufig, still und taucht nur auf echten Geräten mit echten Nutzern auf. Dieselbe echte Gerätelücke zeigt sich über den breiteren Satz von Mobile-Testing-Herausforderungen, wo sich Locale-Fehler und OEM-Eigenheiten tendenziell zusammenballen.

App-Store- und Play-Store-Listing-Lokalisierungs-QA

Store-Metadaten sind nicht die App, aber sie sind die erste lokalisierte Oberfläche, die ein Nutzer sieht. Zwei Stores, zwei Workflows, zwei Sätze von Fallstricken, und beide Einreichungen können aus Gründen abgelehnt werden, die QA hätte zuerst erkennen sollen.

App Store Connect

App-Store-Lokalisierung auf iOS läuft über App Store Connect, wo jedes Locale seinen eigenen Titel (30 Zeichen), Untertitel (30), Keyword-Feld (100), Werbetext (170), Beschreibung (bis zu 4000), Screenshots pro Gerätegröße, Vorschauvideos und “Was ist neu” pro Release erhält. App-Store-Connect-Lokalisierung hat eine spezifische Falle: Zeichenzahlen werden nach Code-Punkten berechnet, sodass japanische Katakana oder chinesische Hanzi in einem Titel still die visuelle Breite überlaufen können, auch wenn sie in die Zahl passen. Verifizieren Sie, dass die Screenshots jedes Locales die tatsächlich lokalisierte In-App-UI verwenden, statt der englischen UI mit einem übersetzten Caption obendrauf.

Google Play-Konsole

Play-Store-Lokalisierung auf Android wird in der Google Play Console unter Store Listing verwaltet, mit Titel (30), Kurzbeschreibung (80), vollständiger Beschreibung (4000), Feature-Grafik, Screenshots und Promo-Video pro Sprache. Benutzerdefinierte Store-Listings erlauben es Ihnen, verschiedene Inhalte nach Land, Vorregistrierungszustand oder Installationszustand bereitzustellen. Das Datensicherheitsformular muss ebenfalls lokalisiert werden. Eine bewusste Prüfung: Bestätigen Sie, dass die automatische Übersetzung von Google Play deaktiviert ist, wenn Sie menschliche Übersetzungen geliefert haben, da automatisch übersetzte Metadaten über menschlich erstelltem Text inkonsistenten nutzerseitigen Text erzeugt und die Konversion beeinträchtigt.

Eine Store-Listing, die vollständige Lokalisierung verspricht, während die App selbst halb übersetzt bleibt, wird Ein-Stern-Bewertungen schneller einheimsen als jeder andere Launch-Fehler. Bewertungen fallen, und ASO-Rankings folgen.

Das Problem der echten Gerätematrix

Emulatoren lügen über Locale-Rendering. Xiaomi liefert MIUI mit eigenem Font-Stack, der Devanagari- und Arabisch-Glyphen verstoppeln kann. Samsungs One UI überschreibt einige Dynamic-Type-Verhaltensweisen. Ältere iPhones ohne Notch haben andere Safe-Area-Mathematik, die lokalisiertem Banner-Text auf dem Startbildschirm brechen kann. Font-Fallback-Ketten unterscheiden sich zwischen Herstellern, und eine chinesische Zeichenkette, die auf einem Pixel sauber rendert, kann auf einem Vivo-Telefon seltsam aussehen, das in diesem genauen Markt beliebt ist.

Eine pragmatische Gerätematrix für einen Launch in Deutschland, Japan und Brasilien sieht in etwa so aus:

• iPhone 15, iPhone 13, iPhone SE (2. Gen.) für aktuelle und Legacy-iOS-Layouts
• Pixel 8 als Referenz-Android
• Samsung Galaxy S23 für One-UI-Verhalten
• Xiaomi Redmi Note 12 für MIUI-Font-Rendering
• Ein Tablet pro Plattform (iPad und ein beliebiges 10-Zoll-Android-Tablet)

Wir testen genau aus diesen Gründen nur auf echten Geräten, und es ist in unser Mobile-Anwendungs-Testing-Vorgehen über 300+ Produkte eingebettet. Simulatoren können keine OEM-Font-Stacks, echtes Tastaturverhalten oder die Art und Weise reproduzieren, wie ein bestimmtes Gerätemodell eine Benachrichtigung auf seinem Sperrbildschirm rendert. Wenn ein Fehler in einem Fünf-Sterne-Markt auftaucht, ist er fast immer gerätespezifisch, und fast nie ist es etwas, das der Emulator entdeckt hätte.

Bevor Sie auf Einreichen drücken

Mobile-Lokalisierungs-QA ist der Ort, an dem Übersetzung, Plattform-APIs, Store-Einreichungen und Geräte-Fragmentierung alle am selben Launch-Datum zusammentreffen. Wenn eine Schicht falsch liegt, wird der Markt, in den Sie investiert haben, kalt gegenüber Ihnen. Wenn alle vier richtig sind, fühlt sich die App in dem Moment nativ an, in dem ein Nutzer sie öffnet, was der ganze Grund für die Lokalisierung ist. Wenn Sie ein Multi-Markt-Rollout planen und QA möchten, das diese Fehlermodi bei Hunderten von Produkten gesehen hat, kontaktieren Sie uns, und wir werden es rund um Ihre Zielmärkte und Ihr Geräteprofil abstecken.

FAQ

Wie testet man Mobile-App-Lokalisierung?

Beginnen Sie damit, ein echtes Gerät auf das Ziel-Locale umzustellen, anstatt ein Flag auf einem Emulator zu ändern. Verifizieren Sie Übersetzungen im Kontext auf jedem Bildschirm, prüfen Sie die UI auf Texterweiterung und Trunkierung, bestätigen Sie, dass Daten, Währungen und Telefonnummernformate Plattform-Formatter verwenden, testen Sie Push-Benachrichtigungen und deren Timing pro Zeitzone, und arbeiten Sie die Store-Listing separat in App Store Connect und Google Play Console durch. Tun Sie all dies auf den tatsächlichen Geräten, die im Zielmarkt beliebt sind, nicht auf der Hardware, die auf Ihrem Schreibtisch steht.

Was ist Lokalisierungstesting für eine Mobile-App?

Es ist eine QA-Disziplin, die verifiziert, dass eine übersetzte Mobile-App für Nutzer in einer bestimmten Sprache, Region und Geräteumgebung korrekt funktioniert. Sie deckt sprachliche Genauigkeit im Kontext ab, UI-Integrität nach dem Erweitern oder Schrumpfen von Zeichenketten, locale-bewusstes Formatieren für Daten und Währungen, Push-Benachrichtigungsverhalten, Store-Listing-Metadaten und Rendering auf echten Geräten von den in diesem Markt beliebten OEMs. Übersetzung allein ist nur ein Teil davon.

Was ist der Unterschied zwischen iOS- und Android-Lokalisierungstesting?

Die Plattformen handhaben Locale durch verschiedene Dateiformate, APIs und Store-Workflows. iOS verwendet .strings- und .stringsdict-Dateien mit NSLocalizedString und reicht pro-Locale-Metadaten über App Store Connect ein. Android verwendet qualifizierte Ressourcenordner und strings.xml mit getQuantityString und verwaltet pro-Sprach-Listings in der Google Play Console. Pro-App-Spracheinstellungen kamen in iOS 13 und Android 13. Die Fragmentierung ist auf Android tiefer, weil OEM-Skins wie MIUI und One UI das Font-Rendering ändern, sodass die Gerätematrix größer läuft.

Brauche ich echte Geräte für Lokalisierungs-QA?

Ja. Emulatoren können keine OEM-Font-Stacks, Tastaturverhalten, Notification-Rendering auf echten Sperrbildschirmen oder die Art und Weise reproduzieren, wie regionsspezifische Geräte Glyph-Fallback handhaben. Eine chinesische Zeichenkette, die auf einem Pixel-Emulator sauber rendert, kann auf einem Vivo-Telefon, das diesen Markt dominiert, kaputt aussehen. Jeder Lokalisierungsfehler, der App-Store- oder Play-Store-Bewertungen erreicht, ist fast immer gerätespezifisch, weshalb echtes Geräte-Testing eine harte Anforderung für einen globalen Launch ist.