App mehrsprachig anbieten – was dazugehört

Nicht nur Texte wandern: Datum, Zahlen, Pluralformen, Layoutbreite und Store-Seite – was Mehrsprachigkeit in einer App wirklich bedeutet und kostet.

„Und kann die App später auch auf Englisch?“ Die Frage klingt nach einer Kleinigkeit, die man am Ende dazubestellt, ist aber eine Entscheidung über den Aufbau der App – und die trifft man vor der ersten Zeile Code.

Denn sie lautet nicht „sind die Texte übersetzt“, sondern „ist die App so gebaut, dass Sprache austauschbar ist“.

„Übersetzt“ und „mehrsprachig gebaut“ sind zwei Dinge

Steht ein Text direkt im Code, existiert er genau einmal: auf Deutsch. Mehrsprachig gebaut heißt: kein Text steht im Code. Jeder Text liegt unter einem Schlüssel in einer Textdatei, und die App holt zur Laufzeit die Datei zur eingestellten Sprache. Bei Android sind das Ressourcendateien je Sprache, im Code über den Ressourcennamen angesprochen statt über den Wortlaut (Stand 2026, Android-Entwicklerdokumentation); für iOS und Cross-Platform gilt dasselbe Prinzip mit anderen Formaten.

Die Texte gleich auszulagern kostet kaum Mehraufwand – gleiche Arbeit, andere Ablage. Nachträglich ist es Handarbeit an jedem einzelnen Text, und jeder Fund muss durchgeklickt werden. Daraus folgt die Unterscheidung, die dir Geld spart: Die zweite Sprache darf in Version 1 fehlen, die Textdateien dürfen es nicht – dieselbe Weichenstellung, um die es in was ein MVP nicht weglassen darf geht.

Was außer den Texten noch wandert

Datum und Uhrzeit. 12.10.2026 und 10/12/2026 sind dasselbe Datum. Nie selbst zusammensetzen, sondern vom System für die aktive Sprache formatieren lassen.

Zahlen und Währung. Dezimal- und Tausendertrennzeichen sind nicht überall Komma und Punkt. Und Sprache, Region und Währung sind drei getrennte Einstellungen: Wer die App auf Englisch liest, zahlt nicht automatisch in einer anderen Währung – umschalten heißt nicht umrechnen.

Pluralformen. „1 Nachricht“ und „2 Nachrichten“ ist der einfache Fall; nicht jede Sprache hat nur zwei Formen. Das Unicode-CLDR führt die Kategorien zero, one, two, few, many und other; welche eine Sprache braucht, ist dort festgelegt (Stand 2026, CLDR-Spezifikation). Plural deshalb nie selbst mit „größer als eins“ abfragen, sondern den Plural-Mechanismus des Frameworks nutzen – sonst wird jede Sprache ein Sonderfall im Code.

Textlänge. Für dieselbe Aussage ist das deutsche Wort oft länger als das englische – „Benachrichtigungen“ gegen „Alerts“. Knöpfe mit fester Breite brechen dann auseinander. Regel fürs Design: Flächen wachsen mit dem Text, Text darf umbrechen, geprüft wird in der längsten Sprache.

Sortierung. Wo Umlaute und Sonderzeichen alphabetisch einsortiert werden, hängt von der Sprache ab – also die Sortierfunktion der aktiven Sprache verwenden statt Zeichen zu vergleichen.

Schreibrichtung. Arabisch und Hebräisch laufen von rechts nach links, dann spiegelt sich die Oberfläche: Zurück-Symbole, Einrückungen, Anordnung. Die Systeme können das, die App muss es zulassen – bei Android über das Manifest-Attribut android:supportsRtl und Abstände mit start und end statt left und right (Stand 2026, Android-Entwicklerdokumentation). Nachrüsten heißt: jedes Layout noch einmal anfassen – wenn Arabisch denkbar ist, sag es vor dem Design.

Die Store-Seite ist ein zweiter Satz Texte

Beide Stores erlauben Angaben je Sprache (Stand 2026):

  • In App Store Connect pflegst du Metadaten je Sprache; laut Apple-Hilfe übernehmen Screenshots und übrige Angaben beim Hinzufügen einer Sprache die Werte der Hauptsprache – ausgenommen Beschreibung und Schlüsselwörter.
  • In der Play Console lassen sich Titel, Kurz- und vollständige Beschreibung übersetzen; laut Google-Hilfe werden ohne eigene Grafiken die der Standardsprache angezeigt.

Welche Sprachen die Stores aktuell anbieten, siehst du in deren Listen selbst. Was in Titel, Untertitel und Screenshots gehört, steht in App-Store-Optimierung für kleine Anbieter.

Wer übersetzt

Ein praktikabler Weg: maschinelle Übersetzung als Grundlage, dann Korrektur durch einen Menschen, der die Fachbegriffe deines Betriebs kennt. Rohübersetzungen scheitern nach unserer Erfahrung weniger an der Grammatik als an euren Wörtern – am Unterschied zwischen Auftrag, Bestellung und Vorgang. Dafür braucht die Korrektur Kontext statt einer Wortliste: Satz, Schlüssel, Screenshot der Stelle, verfügbarer Platz. Und: Unserer Einschätzung nach schadet eine schlechte Übersetzung mehr als gar keine. Hast du für eine Sprache niemanden, der den Text abnimmt, ist sie noch nicht dran.

Was im Betrieb dazukommt

Mehrsprachigkeit wird nie fertig. Jede neue Funktion bringt neue Texte in allen Sprachen mit: jeden Hinweis, jede Fehlermeldung, jede Push-Nachricht, dazu je Sprache Korrektur und Durchklicken. Das gehört in die Betriebsplanung, wie sie was in einen Wartungsvertrag gehört beschreibt – und in den Testplan, siehe testen vor dem Release.

Wann du damit nicht anfangen solltest

Fang mit einer Sprache an. Sind deine Nutzer in einem Sprachraum, ist die zweite Sprache Ballast, der Budget bindet und jede spätere Änderung verteuert – bau nur so, dass die zweite ohne Umbau dazukommt.

Anders liegt es, wenn der Auslöser eine vorhandene Nutzergruppe ist: Werden in einer Elternschaft mehrere Sprachen gesprochen, gehört die Umschaltung in die erste Version, wie in App für Kitas beschrieben. Und eine Gästemappe in nur einer Sprache kann ein Teil internationaler Gäste nicht lesen – ein Thema aus App für Hotels und Ferienwohnungen.

Der Teil, der gegen unseren Umsatz spricht: Willst du nur die Store-Seite in einer zweiten Sprache, ist das Arbeit in App Store Connect und in der Play Console, die du selbst machen kannst – dafür brauchst du uns nicht. Steht auf dem Bildschirm ohnehin überwiegend, was dein Team eingibt, übersetzt du Inhalte statt der App.

Was Mehrsprachigkeit kostet

In unserer Preisliste steht Mehrsprachigkeit mit 2.500–4.500 €. Damit ist in der Regel das technische Gerüst gemeint: ausgelagerte Texte, Sprachumschaltung, Formate für Datum und Zahlen, Pluralbehandlung, Layouts für längere Texte, Einpflegen einer zweiten Sprache. Nicht darin: die Übersetzung selbst und der Store-Eintrag je Sprache.

Zur Einordnung ein typisches Projekt aus unserem Rechner – Cross-Platform, individuelles Design, E-Mail-Login, Firebase oder Supabase, Push: 33.000–56.000 €, 10–16 Wochen. Mit Mehrsprachigkeit 35.000–61.000 € und 10–18 Wochen. Dazu der Betrieb: als Faustregel 15–20 % der Projektsumme pro Jahr, bei uns Wartungspakete ab 150 € netto im Monat. Alle Preise netto zzgl. Umsatzsteuer – unser Angebot richtet sich an Unternehmen, Selbstständige und Organisationen. Nachrechnen kannst du im App-Kosten-Rechner.

Fazit

Eingeplante Mehrsprachigkeit ist überschaubar, nachgerüstete teuer – der Unterschied liegt darin, ob Texte von Anfang an außerhalb des Codes stehen. Mit den Texten wandern Datum, Zahlen, Pluralformen, Sortierung, Textlänge und die Schreibrichtung. Und jede Sprache ist eine Dauerverpflichtung, kein Posten im Projektplan.

Was davon dein Vorhaben betrifft, sortiert die Vorbereitungs-Checkliste. Erzähl uns im kostenlosen Erstgespräch, welche Sprachen deine Nutzer sprechen und wer übersetzen könnte. Wir antworten werktags innerhalb von 24 Stunden – auch dann, wenn die ehrliche Antwort lautet: eine Sprache reicht, bau nur die Tür für die zweite ein.

Lass uns über deine App sprechen.

Kostenloses Erstgespräch, 30–45 Minuten: Du erzählst, wir fragen nach – und du bekommst eine Einschätzung zu Aufwand, Zeitplan und dem sinnvollsten ersten Schritt. Antwort werktags innerhalb von 24 Stunden.