App mehrsprachig machen: Texte, Formate und Store-Einträge

Kurz gesagt: Eine App mehrsprachig zu machen beginnt nicht mit der Übersetzung, sondern damit, dass alle Texte aus dem Code in zentrale Textdateien wandern und Datums-, Zahl- und Pluralformen dem System überlassen werden. Danach übersetzen Sie mit Kontext, testen mit Pseudo-Sprachen und echten Geräten auf zu lange Texte und lokalisieren zum Schluss die Store-Einträge getrennt von der App selbst. Wer diese Reihenfolge einhält, kann später jede weitere Sprache mit wenig Aufwand ergänzen.

Typischer Ausgangspunkt: Eine deutsche Service- oder Kunden-App läuft gut, nun sollen englischsprachige Mitarbeitende, Gäste oder Kunden im Ausland sie nutzen. Die naheliegende Idee – „wir schicken die Texte zum Übersetzer“ – scheitert meist daran, dass es „die Texte“ nicht an einem Ort gibt. Deshalb lohnt sich ein Vorgehen in Phasen.

Phase 1: Vorbereiten – die App übersetzbar machen

Texte raus aus dem Code

Die Android-Dokumentation zur Lokalisierung (abgerufen November 2026) formuliert es klar: Texte nicht fest im Code verdrahten, sondern alle als Ressourcen in einer Standarddatei strings.xml ablegen. Dann lassen sie sich extrahieren, übersetzen und wieder einspielen, ohne den kompilierten Code zu ändern. Auf iOS übernimmt das der String-Katalog in Xcode: Laut Apple sammelt Xcode beim Build die übersetzbaren Texte automatisch in einem Katalog mit visueller Bearbeitung, inklusive Pluralvarianten je Sprache.

Fragen Sie Ihr Entwicklerteam konkret: Gibt es noch Texte, die direkt im Code stehen – Fehlermeldungen, Push-Nachrichten, E-Mail-Vorlagen aus dem Backend? Gerade Letztere werden oft vergessen, weil sie gar nicht in der App liegen.

Eine vollständige Standardsprache

Android lädt laut Doku die Standardtexte, wenn für eine Gerätesprache keine eigene Übersetzung existiert. Fehlt in dieser Standarddatei ein Text, den die App braucht, startet sie nicht und zeigt einen Fehler. Die Standardsprache muss also immer vollständig sein – auch wenn Sie später nur einzelne Sprachen nachziehen.

Formate dem System überlassen

Datum, Uhrzeit, Währungen, Dezimaltrennzeichen und Mehrzahlformen unterscheiden sich je Sprache und Region. „3 Termine“ funktioniert im Deutschen, aber andere Sprachen haben mehr Pluralformen. Statt Formate selbst zusammenzubauen, sollte die App die Formatierungsfunktionen der Plattform nutzen. Ebenso wichtig: keine Sätze aus Einzelteilen zusammensetzen („Sie haben“ + Zahl + „neue Nachrichten“), weil die Wortstellung in anderen Sprachen anders ist.

Platz für längere Texte

Übersetzungen sind oft länger als das Original, Schaltflächen und Tabs werden zu eng. Planen Sie Layouts, die mitwachsen, statt fixer Breiten. Wenn eine Sprache mit Leserichtung von rechts nach links dazukommen soll, betrifft das die gesamte Anordnung der Oberfläche – das gehört früh auf den Tisch.

Phase 2: Übersetzen – mit Kontext statt Wortlisten

Eine Liste wie „Senden, Abbrechen, Termin“ ist für Übersetzer ein Ratespiel. Google empfiehlt in der Lokalisierungsanleitung, bei jedem Text zu beschreiben, in welchem Zusammenhang er erscheint; das verbessere die Übersetzungsqualität. Apple bietet im String-Katalog Kommentare für die Übersetzenden, die Xcode auf Wunsch aus der Oberfläche heraus vorschlägt.

Praktisch bewährt sich:

Glossar zuerst: Fachbegriffe Ihres Betriebs (Produktnamen, Leistungsbezeichnungen) einmal festlegen, damit sie überall gleich übersetzt werden.
Screenshots mitliefern: Ein Bild der Maske beantwortet viele Rückfragen.
Maschinelle Übersetzung als Entwurf: Google Play bietet laut Play-Console-Hilfe kostenlose maschinelle Übersetzungen für Store-Eintrag und In-App-Produkte sowie eine optionale automatische Übersetzung der App-Texte mit Gemini an. Für kurze Bedienelemente kann das genügen; Texte, die verkaufen oder erklären, sollten von einem Menschen mit Sprachgefühl geprüft werden.
Platzhalter schützen: Variablen wie Namen oder Zahlen dürfen beim Übersetzen nicht verändert werden. Android kennzeichnet nicht zu übersetzende Teile dafür eigens in der Ressourcendatei.

Phase 3: Testen – Fehler sichtbar machen, bevor Nutzer sie sehen

Pseudo-Sprachen

Android stellt laut Entwicklerdoku zwei Pseudo-Sprachen bereit: „English (XA)“ versieht Texte mit Akzenten, verlängert sie künstlich und setzt Klammern um jede Texteinheit; „AR (XB)“ simuliert eine Rechts-nach-links-Sprache. Fest verdrahtete Texte erscheinen dabei ohne Akzente und fallen sofort auf, ebenso abgeschnittene Beschriftungen und zusammengestückelte Sätze. Das ist ein schneller Test, noch bevor eine echte Übersetzung vorliegt.

Echte Geräte, echte Sprachen

Danach testen Sie mit eingestellter Gerätesprache: Passt jede Schaltfläche? Stimmen Datums- und Zahlformate? Was passiert, wenn das Gerät auf eine Sprache eingestellt ist, die Sie gar nicht anbieten – fällt die App sauber auf die Standardsprache zurück? Prüfen Sie auch Push-Nachrichten und E-Mails, die vom Server kommen.

Sprachwahl in der App?

Viele Apps folgen einfach der Gerätesprache. Wenn Ihre Nutzer häufig auf Firmenhandys mit fester Sprache arbeiten, kann ein eigener Sprachumschalter sinnvoll sein. Das ist eine Produktentscheidung, die vor dem Testen fallen sollte.

Phase 4: Veröffentlichen – Store-Einträge eigens lokalisieren

Die Sprachen der App und die Sprachen des Store-Eintrags sind zwei getrennte Dinge. Apple schreibt in der App-Store-Connect-Hilfe ausdrücklich, dass die Sprachen auf der Seite „App-Informationen“ Teil der Metadaten sind und sich vom Lokalisieren der App in Xcode unterscheiden. Wer nur eine Primärsprache angibt, zeigt diese in allen Ländern. Neue Sprachen übernehmen Screenshots und Felder zunächst aus der Primärsprache – außer Beschreibung und Schlüsselwörtern, die Sie selbst ergänzen.

In der Play Console fügen Sie laut Hilfe über „Übersetzungen verwalten“ Sprachen zum Store-Eintrag hinzu. Lokalisierte Grafiken sind optional; ohne sie erscheinen die Bilder der Standardsprache. Nutzer, für deren Sprache Sie nichts hinterlegt haben, können sich laut Google eine automatische Übersetzung der Store-Seite anzeigen lassen – mit Hinweis darauf.

Praxistipp: Screenshots mit eingebautem deutschen Text wirken in einem englischen Eintrag schnell nachlässig. Wenn Sie Screenshots ohnehin neu erstellen, legen Sie sie gleich je Sprache an.

Danach: die zweite Sprache ist der Anfang, nicht das Ende

Jedes Update bringt neue Texte. Legen Sie fest, wer neue Texte vor dem Release übersetzt und freigibt, damit nicht in Version 2.3 plötzlich deutsche Fehlermeldungen in der englischen App auftauchen. Die Statusanzeige im Xcode-String-Katalog, die laut Apple neue und übersetzte Einträge sowie den Übersetzungsgrad je Sprache zeigt, hilft dabei, nichts zu übersehen.

Häufige Fragen

Reicht es, nur den Store-Eintrag zu übersetzen?

Für die Auffindbarkeit im Ausland kann ein übersetzter Eintrag helfen, aber Nutzer erwarten dann auch die App in ihrer Sprache. Ein englischer Eintrag zu einer rein deutschen App sorgt eher für Enttäuschung und schwache Bewertungen.

Wie viele Sprachen sollte eine kleine Firma anbieten?

So viele, wie Sie dauerhaft pflegen können. Eine sauber gepflegte Zweitsprache ist besser als fünf halb übersetzte.

Müssen auch Inhalte aus dem Backend übersetzt werden?

Ja, wenn Nutzer sie sehen: Produktnamen, Kategorien, Benachrichtigungen, E-Mails. Dafür braucht das Backend ein Feld je Sprache oder eine eigene Übersetzungstabelle – das ist oft der größere Teil der Arbeit.

Kann ich mit einer Sprache starten und später weitere ergänzen?

Genau dafür ist Phase 1 gedacht. Ist die App einmal übersetzbar gebaut, bedeutet jede neue Sprache vor allem Übersetzungs- und Testaufwand, nicht Umbau.

Falls Sie gerade überlegen, Ihre App für eine zweite Sprache fit zu machen, schaue ich gern mit Ihnen auf den Ist-Zustand und die nächsten Schritte – hier entlang.