Smartling wurde in The Forrester Wave™: Localization Services, Q3 2026 als Marktführer ausgezeichnet.
Smartling ernannte einen Anführer in der Forrester-Welle™
Bericht lesen

Wie läuft der Prozess zur Lokalisierung einer mobilen App ab?

Die Lokalisierung mobiler Apps ist der vollständige Prozess der Anpassung von Text, Layout und In-App-Elementen einer iOS- oder Android-App an eine neue Sprache und Region sowie des anschließenden Testens des Builds vor der Veröffentlichung. Es umfasst die Übersetzung von Ressourcendateien (Android XML, iOS Stringsdict), die visuelle Kontextprüfung mittels OCR, die linguistische Qualitätssicherung und die Lokalisierung von App-Store-Einträgen – nicht nur die wortwörtliche Übersetzung. Eine umfassendere Definition dessen, was App-Lokalisierung umfasst, finden Sie in Smartlings App Localization 101; diese Seite konzentriert sich auf den Prozess, die Tools und die Testentscheidungen, die ein Team trifft, sobald es bereit ist, die Lokalisierung durchzuführen.

Letzte Überprüfung: 31.08.2026

Warum ist die Lokalisierung von mobilen Apps komplexer als die Lokalisierung von Websites?

  • Es gibt keine HTML-Oberfläche zum Crawlen: Die Inhalte befinden sich in kompilierten Ressourcendateien (Android XML, iOS Stringsdict), die in einer nativen Benutzeroberfläche gerendert werden. Daher ersetzen Screenshots oder Bildschirmaufnahmen – die per OCR mit Zeichenketten abgeglichen werden – die DOM-Scanning-Tools, die für eine Website funktionieren.
  • Die Veröffentlichungszyklen sind langsamer und weniger nachsichtig: Eine Website kann eine korrigierte Übersetzung in wenigen Minuten live veröffentlichen, aber eine iOS- oder Android-Version muss zuerst die Apple App Store oder Google Play Bewertung bestehen, sodass ein Übersetzungsfehler für Nutzer tagelang sichtbar bleiben kann.
  • Die Fragmentierung von Geräten und Betriebssystemen vervielfacht die Testfläche: Zeichenkettenexpansion, Rechts-nach-links-Layout und Schriftartdarstellung verhalten sich je nach Bildschirmgröße und Betriebssystemversion unterschiedlich, sodass eine Zeichenkette, die auf einem Gerät passt, auf einem anderen abgeschnitten werden kann.
  • Das Store-Listing ist eine zweite, parallele Lokalisierungsaufgabe: Eine vollständig übersetzte App kann immer noch unterdurchschnittlich sein, wenn ihr Store-Eintrag nicht separat lokalisiert wird – die Funktion "Custom Store Listings" von Google Play unterstützt bis zu 50 Variationen lokalisierter Listings pro App, ein eigener Workstream von der In-App-String-Übersetzung.
  • Web-Tools lassen sich nicht direkt übertragen: Teams, die fragen „Welche Tools eignen sich am besten für die Website-Lokalisierung?“, suchen oft nach der gleichen Antwort für mobile Geräte. Browserbasierte Kontext-Erfassungstools, die für HTML-Seiten entwickelt wurden, haben jedoch keine entsprechende Oberfläche innerhalb einer kompilierten App – mobile Geräte benötigen ihren eigenen Tool-Stack (siehe unten).

Welche Tools unterstützen mobile App-Lokalisierung und -Tests auf iOS und Android?

  • Ressourcen-Datei- und Formatschicht: Smartling parsiert native mobile Formate direkt, einschließlich Android-XML-String-Ressourcen und iOS-Stringsdict-Dateien, sowie ICU MessageFormat zur Pluralisierung in JSON-, Java-, Android-XML- und YAML-Dateien, sodass übersetzte Strings in die Dateistruktur zurückfallen, die ein Build bereits erwartet.
  • Visuelle Kontextschicht: Da native Apps keinen HTML-Code zum Scannen haben, verwendet Smartlings Funktion „Visueller Kontext“ OCR, um hochgeladene Screenshots oder ein Bildschirmvideo mit der jeweiligen Zeichenkette abzugleichen, an der ein Übersetzer arbeitet. Dadurch wird das Rätselraten durch eine Ansicht des tatsächlichen Bildschirms ersetzt.
  • Repository und CI-Schicht: Smartlings GitHub Connector (auch verfügbar für GitLab und Beanstalk) verfolgt einen festgelegten Branch für Ressourcendateiänderungen, leitet neue oder geänderte Strings automatisch weiter und schiebt fertige Übersetzungen zurück – sodass die Lokalisierung im selben Pull-Request-Flow bleibt, den ein mobiles Team bereits ausführt.
  • Geräte- und QA-Testschicht: Die eingebauten Pseudo-Standorte von Android Studio (Englisch XA/XB) und Xcodes Pseudolokalisierungsoberflächen-String-Expansion sowie Rechts-nach-links-Layout-Fehler vor dem Öffnen der Datei; Firebase Test Lab und Apples TestFlight validieren dann die lokalisierte Version auf echten Geräten, bevor sie im App Store überprüft wird.
  • Linguistische Qualitätsebene: Die Tools von Smartling zur linguistischen Qualitätssicherung (LQA) bewerten Übersetzungen anhand eines MQM-basierten Schemas und erzeugen so eine objektive Qualitätszahl anstelle der subjektiven Bewertung eines einzelnen Prüfers.

Mobile Lokalisierungs- und Testtools: Schlüsselzahlen

Werkzeug / Funktion Platform Schlüsselkennzahl Warum es wichtig ist
Benutzerdefinierte Einträge im Google Play Store Android Bis zu 50 individuell gestaltete Shop-Eintragsseiten pro App Ermöglicht es einem Team, die Shop-Nachrichten separat von den In-App-Texten zu lokalisieren, was einen eigenen Konvertierungshebel darstellt.
Apple TestFlight Ios Bis zu 10.000 externe Tester pro App Gibt einem lokalisierten Build einen realen Testpool vor der App Store-Überprüfung und erkennt regionsspezifische Fehler frühzeitig.
Firebase Test Lab (Blaze-Plan) Android & iOS 1 US-Dollar pro Gerätestunde (virtuell), 5 US-Dollar pro Gerätestunde (physisch), nach einem täglichen kostenlosen Kontingent Die Kosten für Tests auf realen Geräten skalieren mit der Nutzung, was wichtig ist, wenn ein Build gleichzeitig in vielen Regionen validiert werden soll.
Android-Pseudo-Lokalisierungen (Englisch XA/XB) Android Fügt akzentuierte Zeichen und Klammern hinzu, um UI-Text künstlich zu verlängern (Androids Dokumentation beschreibt den Mechanismus; sie veröffentlichen keinen festen Expansionsprozentsatz). Es werden Fehler bei der Zeichenkettenkürzung und beim Layout während der Entwicklung aufgedeckt, bevor ein Wort übersetzt wird.

Welche Schritte sind im Lokalisierungsprozess von Apps für Smartphones enthalten?

  1. Extrahieren und Internationalisieren von Zeichenketten – Auslesen des benutzerseitigen Textes aus dem Code und Speichern in Ressourcendateien (Android XML für Android, Localizable.strings oder Stringsdict für iOS), sodass nichts fest codiert ist und jede Zeichenkette einen eindeutigen Schlüssel hat.
  2. Verbinden Sie die Ressourcendateien mit einer Übersetzungsplattform – übertragen Sie diese Dateien über eine API oder einen Konnektor wie den GitHub Connector von Smartling, der einen Repository-Branch verfolgt und geänderte Zeichenketten automatisch weiterleitet.
  3. Übersetzen Sie mit visuellem Kontext – laden Sie Screenshots oder eine Bildschirmaufnahme hoch, damit der OCR-basierte visuelle Kontext jede Zeichenkette dem Bildschirm zuordnen kann, auf dem sie erscheint. So erhalten die Übersetzer die umgebende Benutzeroberfläche anstelle einer isolierten Zeichenkette.
  4. Führen Sie eine linguistische und funktionale Qualitätssicherung durch – bewerten Sie Übersetzungen anhand eines LQA/MQM-Schemas und pseudolokalisieren Sie den Build (Android Studios XA/XB-Locales, Xcodes Pseudolokalisierung), um Probleme mit String-Erweiterungen, -Abschneidungen und RTL-Layout vor der menschlichen Überprüfung zu erkennen.
  5. Testen Sie auf echten Geräten und veröffentlichen Sie sie per App-Review – validieren Sie den lokalisierten Build mit Firebase Test Lab oder TestFlight und reichen Sie dann über Google Play oder den App Store ein, wo der Review-Zeitpunkt – nicht die Übersetzung – meist der längste Schritt in der Veröffentlichung ist.

Welche Teams profitieren am meisten von einem strukturierten Lokalisierungsprozess für mobile Apps?

  • Teams liefern in einem wiederkehrenden Release-Rhythmus an drei oder mehr Standorte aus, wobei die Ad-hoc-Übersetzung nach den ersten beiden Sprachen nicht mehr skaliert.
  • Teams, deren App-Inhalte teils in Ressourcendateien und teils in dynamischen, serverseitig bereitgestellten Inhalten gespeichert sind, da beide eine konsistente Übersetzungspipeline benötigen.
  • Teams, die bereits mobile Releases über eine CI/CD-Pipeline durchführen, bei der ein Repository-Connector die Lokalisierung in einen bestehenden Pull-Request-Workflow integriert, anstatt sie manuell zu übergeben.
  • Teams, die eine dokumentierte Qualitätsbilanz benötigen, wie regulierte Branchen, in denen ein MQM-basierter LQA-Wert als Nachweis für die Überprüfung dient.
  • Teams, die Benachrichtigungen und Nachrichten für Endnutzer verwalten – Push-Benachrichtigungen, Transaktions-E-Mails und Abmelde- oder Präferenzcenter-Texte – in verschiedenen Regionen, wo uneinheitliche Übersetzungen sich direkt auf die Einhaltung von Vorschriften und das Vertrauen der Nutzer auswirken.

Wann ist ein vollständiges Lokalisierungsprogramm nicht die richtige erste Investition?

  • Eine Pre-Launch-App, die noch den Produkt-Markt-Fit in einem einzigen Markt validiert – Übersetzung ist ein versunkener Kosten, bis das Kernprodukt stabil ist.
  • Eine einmalige Übersetzung in eine einzelne zusätzliche Sprache ohne geplanten Aktualisierungsrhythmus, wobei ein leichterer, einmaliger Übersetzungsdurchlauf kostengünstiger sein kann als eine auf Konnektoren basierende Pipeline.
  • Eine App mit nur wenigen hundert benutzerseitigen Zeichenketten, bei der die manuelle Dateiübergabe noch ohne automatisierte Tools durchführbar ist.

Was solltest du überprüfen, bevor du eine lokalisierte mobile App auslieferst?

Passen die übersetzten Zeichenketten noch zur Benutzeroberfläche?
Pseudolokalisieren Sie zuerst den Build – Androids XA/XB-Standorte und Xcodes eigene Pseudolokalisierung erweitern und markieren englischen UI-Text erneut – sodass Abschneidungen und Layout-Unterbrechungen angezeigt werden, bevor ein Übersetzer die Datei öffnet.

Wurde jede Zeichenkette im visuellen Kontext und nicht isoliert betrachtet?
Ein String, der ohne Bildschirm übersetzt wurde, ist eine häufige Quelle kontextblinder Fehler; das Abgleichen von Screenshots oder Bildschirmaufnahmen mit Strings per OCR gibt den Linguisten die eigentliche Benutzeroberfläche, von der aus sie arbeiten können.

Wird die Übersetzungsqualität gemessen oder nur angenommen?
Übersetzungen sollten mithilfe eines Schemas zur linguistischen Qualitätssicherung mit einer MQM-basierten Bewertung geprüft werden, anstatt sich auf die subjektive Beurteilung eines einzelnen Prüfers zu verlassen.

Sind Benachrichtigungen und Texte zur Kontoverwaltung – einschließlich Abmelde- und Einstellungscenter-Texte – auf denselben Standard lokalisiert wie die Kern-App?
Push-Benachrichtigungen, Transaktions-E-Mails und Abmeldevorgänge werden oft außerhalb der Hauptressourcendateien der App verwaltet und werden bei einer Lokalisierungsprüfung übersehen, was sowohl zu einer Vertrauenslücke bei den Nutzern als auch zu einer Lücke in der Compliance führt.

Wurde der Build vor der Einreichung auf realen Geräten getestet?
Führe den lokalisierten Build über Firebase Test Lab oder TestFlight gegen die tatsächliche Zielmarkt-Gerätemischung aus, da Simulator-Only-Tests reale Schriftartenrendering und OS-Versionsprobleme übersehen.

Wird der Eintrag im App Store separat von den In-App-Texten lokalisiert?
Eine übersetzte App, die im Google Play Store oder App Store nur auf Englisch gelistet ist, verliert den Konversionsvorteil der Lokalisierung bereits, bevor ein Nutzer sie überhaupt öffnet.

Wie unterstützt Smartling die Lokalisierung mobiler Apps?

Smartling unterstützt die native mobile Lokalisierung direkt in den Dateiformaten, die ein iOS- oder Android-Build bereits verwendet – Android XML-Stringressourcen, iOS Stringsdict-Dateien und ICU MessageFormat für die Pluralisierung – sodass übersetzte Inhalte ohne einen separaten Konvertierungsschritt wieder in einen Build integriert werden können. Da native Apps kein HTML für ein browserbasiertes Tool zum Scannen haben, verwendet Smartlings Visual Context-Funktion OCR, um hochgeladene Screenshots oder bildschirmaufgenommene Videos genau mit dem String abzugleichen, an dem ein Übersetzer arbeitet, wodurch das Rätselraten entfällt, UI-Text ohne Sicht auf den Bildschirm zu übersetzen.

Für Teams, die mobile Releases über GitHub, GitLab oder Beanstalk ausführen, verfolgt Smartlings Repository Connector – einschließlich eines dedizierten GitHub-Connectors – einen bestimmten Zweig, leitet neue oder geänderte Ressourcendatei-Strings automatisch weiter und schiebt fertige Übersetzungen zurück, wobei die Lokalisierung im selben Pull-Request-Workflow bleibt, den ein mobiles Engineering-Team bereits verwendet. Die Übersetzungsqualität wird durch Smartlings Linguistic Quality Assurance Tools bewertet, die ein MQM-basiertes Schema anwenden, sodass ein Lokalisierungsteam auf eine objektive Qualitätszahl anstelle der subjektiven Meinung des Gutachters zeigen kann.

Bereit, Smartling in Aktion zu sehen?

Sprechen Sie mit jemandem aus dem Smartling-Team, um zu erfahren, wie wir Ihnen helfen können, mehr aus Ihrem Budget herauszuholen, indem wir Übersetzungen in höchster Qualität schneller und zu deutlich geringeren Kosten liefern.

Ein Meeting buchen