Mehrsprachige Apps: Acht Sprachen, eine Codebasis
„Erstmal Deutsch, Englisch kommt später” ist einer der teuersten Sätze in der App-Entwicklung. Nicht weil Übersetzen schwierig wäre, sondern weil die Entscheidung, wann man damit anfängt, über die Struktur des ganzen Projekts bestimmt.
Wer Mehrsprachigkeit von Beginn an einplant, zahlt dafür wenige Tage. Wer sie nachrüstet, zahlt Wochen — und bekommt ein Ergebnis, das schlechter ist.
Der Grund ist einfach: Mehrsprachigkeit ist keine Funktion, sondern eine Architekturentscheidung. Steht im Code kein Text, sondern nur ein Schlüssel, ist jede weitere Sprache eine Datei. Steht der Text im Code, ist jede weitere Sprache ein Projekt.
Warum Nachrüsten so teuer wird
In einer App, die für eine Sprache gebaut wurde, stehen Texte überall: in Oberflächen, in Fehlermeldungen, in Push-Nachrichten, in E-Mail-Vorlagen, in Store-Beschreibungen, in Rechtstexten. Sie nachträglich herauszulösen bedeutet, jede einzelne Stelle zu finden — und die Suche endet nie ganz sicher. Bei einer Altanwendung ist das oft der Punkt, an dem die Frage Sanierung oder Neubau mit auf den Tisch kommt.
Dazu kommen Effekte, an die vorher niemand denkt:
Texte ändern ihre Länge. Deutsche Wörter sind im Schnitt deutlich länger als englische. Ein Button, der auf Englisch passt, sprengt auf Deutsch das Layout. Bei Französisch kommt oft noch mehr dazu. Wer Layouts auf eine Sprache hin gebaut hat, baut sie ein zweites Mal.
Zahlen, Daten und Währungen folgen anderen Regeln. 1.000,50 € ist im Englischen 1,000.50 €. Datumsformate unterscheiden sich, Wochenanfänge auch. Wer das selbst formatiert hat, statt es der Plattform zu überlassen, hat jetzt Arbeit.
Pluralformen sind nicht überall zwei. Deutsch und Englisch kennen Einzahl und Mehrzahl. Polnisch hat mehrere Formen abhängig von der Zahl. Ein selbstgebautes if (anzahl === 1) fällt dort auseinander.
Sortierung ist sprachabhängig. Umlaute werden je nach Sprache anders einsortiert. Eine alphabetische Liste kann in einer Sprache richtig und in einer anderen falsch sein.
Die Kette, die von Anfang an stehen sollte
Der Kern ist die erste Station: Im Code steht kein Text, nur ein Schlüssel. Wenn diese Regel von Tag eins gilt, ist alles Weitere Routine. Wenn sie nicht gilt, ist jede spätere Sprache ein Projekt.
Die Sprachdateien gehören dabei ins Repository und werden versioniert wie Code — nicht in eine Tabelle, die jemand per Mail schickt. Nur so lässt sich nachvollziehen, wann welcher Text warum geändert wurde, und nur so fällt auf, wenn ein Schlüssel in einer Sprache fehlt.
Übersetzung ist nicht Lokalisierung
Das wird regelmäßig verwechselt und ist der Unterschied zwischen „funktioniert” und „fühlt sich richtig an”.
Übersetzung ist der Text in einer anderen Sprache. Lokalisierung ist die Anpassung an den Ort: Maßeinheiten, Rechtstexte, Zahlungsarten, kulturelle Erwartungen — und manchmal Funktionen, die es in einem Markt gar nicht geben darf.
Ein Beispiel aus der Praxis: Eine App, die Temperatur misst, braucht in den USA Fahrenheit. Das ist keine Übersetzung, sondern ein Datenformat mit Auswirkung auf Anzeige, Eingabe und gespeicherte Werte. Wer das erst nach der Übersetzung bemerkt, hat einen Umbau statt einer Textänderung.
Die Frage, wer prüft
Maschinelle Übersetzung ist heute gut genug für den ersten Entwurf. Sie ist nicht gut genug für den letzten. Der Unterschied liegt an drei Stellen:
Fachbegriffe. Ein Modell entscheidet sich für eine Übersetzung, die im Kontext falsch ist — und dann inkonsistent zwischen zwei Bildschirmen. Für wiederkehrende Begriffe braucht es eine feste Liste.
Anrede und Ton. Duzen oder siezen, förmlich oder direkt — das ist eine Markenentscheidung und keine sprachliche. Sie muss vorgegeben und dann konsequent durchgehalten werden.
Rechtlich heikle Texte. Einwilligungen, Haftungshinweise, medizinische Formulierungen. Hier ist maschinelle Übersetzung ein Vorschlag, den ein Mensch verantworten muss. Bei Medizinprodukten ist das keine Empfehlung, sondern Anforderung.
Was acht Sprachen praktisch heißen
Bei einer App, die wir seit zwei Jahren betreuen — einer Companion-App zu einem Messgerät —, sind es acht: Deutsch, Englisch, Französisch, Italienisch, Polnisch, Dänisch — und weil die DACH-Region ernst genommen wird, auch Schweizerdeutsch und Kölsch.
Die letzten beiden sind keine Spielerei, sondern eine Haltung: Wer eine App für den deutschsprachigen Raum macht, kann sich entscheiden, die regionale Färbung mitzunehmen. Technisch kostet die neunte Sprache fast nichts, wenn die Kette steht — das ist der eigentliche Punkt.
Der laufende Aufwand ist der, den man unterschätzt. Jedes neue Feature bringt neue Texte, und die brauchen acht Fassungen. Ohne einen Ablauf dafür entstehen Lücken: Ein Bildschirm ist plötzlich halb deutsch, halb englisch. Deshalb gehört in die Auslieferungskette eine Prüfung, die fehlende Schlüssel meldet, bevor ein Release rausgeht.
Die Stellen außerhalb der App
Mehrsprachigkeit endet nicht am App-Rand. Drei Bereiche werden regelmäßig vergessen:
Store-Einträge. Titel, Kurzbeschreibung, Beschreibung und Screenshots gibt es je Sprache — und sie sind der erste Kontakt mit potenziellen Nutzern. Ein englischer Store-Eintrag für eine deutsche App kostet Installationen, weil die Store-Suche in der Sprache des Nutzers arbeitet.
Push-Nachrichten. Sie entstehen im Backend, nicht in der App. Wenn dort die Sprache des Empfängers nicht bekannt ist, kommen sie in der falschen an — und zwar genau in dem Moment, in dem der Nutzer aufmerksam ist.
E-Mails und Rechtstexte. Bestätigungen, Passwort-Zurücksetzungen, Datenschutzhinweise. Sie liegen meistens in einem anderen System und werden bei der Sprachplanung übersehen.
Rechts-nach-links ist eine eigene Entscheidung
Arabisch und Hebräisch laufen von rechts nach links. Das ist keine weitere Sprache, sondern eine Spiegelung des gesamten Layouts: Zurück-Pfeile, Fortschrittsbalken, Einrückungen, sogar Icons mit Richtung.
Moderne Frameworks unterstützen das, wenn man Layouts von Anfang an in „Anfang” und „Ende” denkt statt in „links” und „rechts”. Wer stattdessen feste Ränder setzt, baut später jedes Layout ein zweites Mal.
Die praktische Empfehlung: Auch wenn keine RTL-Sprache geplant ist, in Anfang/Ende denken. Es kostet nichts und hält die Tür offen.
Wie man das testet, ohne acht Sprachen zu sprechen
Niemand im Team spricht alle Sprachen der App. Was trotzdem geht:
- Auf fehlende Schlüssel prüfen, automatisiert in der Auslieferungskette. Ein Text, der in einer Sprache fehlt, darf kein Release passieren.
- Mit der längsten Sprache testen. Wenn das Layout auf Deutsch oder Französisch hält, hält es meistens überall.
- Screenshots je Sprache erzeugen und einmal durchsehen. Abgeschnittene Texte sieht man sofort, auch ohne die Sprache zu verstehen.
- Muttersprachler einmal draufschauen lassen, bevor ein Markt startet. Eine Stunde reicht, um die peinlichen Fälle zu finden.
Woran du erkennst, dass es sauber gebaut ist
- Die App wechselt die Sprache, ohne dass sie neu gestartet werden muss.
- Kein Bildschirm zeigt zwei Sprachen gleichzeitig.
- Zahlen, Daten und Währungen sehen in jeder Sprache erwartbar aus.
- Eine neue Sprache ist eine Datei, kein Projekt.
- Ein fehlender Text fällt vor dem Release auf, nicht danach.
Keiner dieser Punkte ist aufwendig, wenn er von Anfang an gilt. Jeder einzelne ist teuer, wenn er nachgezogen werden muss.
Passend dazu: Wie wir Apps für mehrere Märkte bauen, steht unter App-Entwicklung. Für bestehende Apps, die international werden sollen: App-Modernisierung.