So lokalisieren Sie eine mobile App

TABLE OF CONTENTS

Wenn Sie nach einer Anleitung zur Lokalisierung einer mobilen App suchen, brauchen Sie normalerweise keine „Übersetzungstipps”. Sie brauchen einen release-sicheren Workflow, der App-Strings, Layout, Pluralregeln, Rechts-nach-Links-Unterstützung, Screenshots und Store-Metadaten abdeckt, ohne das Produkt zu beschädigen.

Das ist der entscheidende Unterschied: Die Lokalisierung einer mobilen App bedeutet nicht nur, Text zu übersetzen. Es geht darum, die App, die Produktseite und den QA-Prozess für jeden Zielmarkt anzupassen. Apple gibt an, dass der App Store in 175 Regionen und 40 Sprachen verfügbar ist, während Android 13 systemweite App-spezifische Spracheinstellungen eingeführt hat. Mit anderen Worten: Beide großen Plattformen gehen mittlerweile davon aus, dass die Sprachwahl ein zentrales Produkterlebnis ist, kein nachträglicher Gedanke.

Dieser Leitfaden führt Sie durch die praktischen Schritte für iOS- und Android-Teams.

Auf einen Blick:

Trennen Sie die In-App-Lokalisierung von der App Store- und Google Play-Lokalisierung.
Externalisieren Sie Strings, bevor Sie irgendetwas übersetzen.
Behandeln Sie Pluralformen, Variablen, Datumsangaben, Währungen und RTL frühzeitig.
Testen Sie mit Pseudosprachen, bevor Sie echte Übersetzungen ausliefern.
Lokalisieren Sie Screenshots und Store-Assets, nicht nur Beschreibungen.

Was die Lokalisierung einer mobilen App tatsächlich umfasst

Die Lokalisierungsarbeit fällt üblicherweise in zwei Bereiche.

1. In-App-Lokalisierung

Das ist das Produkt selbst:

UI-Strings
Fehlermeldungen und Onboarding-Texte
Datumsangaben, Uhrzeiten, Zahlen, Währungen und Maßeinheiten
Plural- und geschlechtersensible Strings
Layout-Erweiterung und Rechts-nach-Links-Verhalten
Bilder oder Icons, die Text oder richtungsabhängige Bedeutung enthalten

Apple empfiehlt ausdrücklich die Verwendung von Xcode, Foundation-APIs, Auto Layout, Unicode-Unterstützung, lokalisierten Asset-Katalogen und richtungsbewussten Symbolen, um Apps für globale Märkte vorzubereiten. Android empfiehlt entsprechend lokalisierungsbewusste Ressourcen, App-Sprachunterstützung und RTL-fähige Layouts anstelle von fest codierten Texten und Positionierungen.

2. Lokalisierung des Store-Eintrags

So entdecken Nutzer Ihre App:

App-Name
Untertitel oder Kurzbeschreibung
Vollständige Beschreibung
Schlüsselwörter
Screenshots
App-Vorschauen oder Promo-Videos

Behandeln Sie dies als separate Liefereinheit. Eine gut lokalisierte App kann trotzdem unterdurchschnittlich abschneiden, wenn die Produktseite generisch, unübersetzt oder visuell nicht zum Zielmarkt passend ist.

Beginnen Sie mit Internationalisierung, nicht mit Übersetzung

Übersetzung ist der letzte Schritt in einer Pipeline, die mit Struktur beginnt.

Externalisieren Sie Strings und pflegen Sie ein vollständiges Fallback-Locale

Auf Android warnt Google, dass Ihre Standard-res/values/strings.xml jeden String definieren muss, den Ihre App benötigt. Wenn die Standarddatei unvollständig ist und das Gerät in einem nicht unterstützten Locale läuft, kann die App nicht laden und zeigt einen Fehler mit einem „Beenden erzwingen”-Button an. Deshalb beginnt Lokalisierung mit Ressourcen-Hygiene, nicht mit der Sprachauswahl.

Für iOS empfiehlt Apple, benutzersichtbaren Text und Bilder vom ausführbaren Code zu trennen, damit sie als Ressourcendateien lokalisiert werden können. In modernen Apple-Workflows sind String-Kataloge der empfohlene Ansatz in Xcode 15 und höher für Strings mit Pluralformen.

Praktische Regel:

Niemals UI-Text in Views oder Controllern fest codieren
Eine kanonische Quellsprache beibehalten
Sicherstellen, dass jeder benutzersichtbare String einen stabilen Schlüssel, Kontext und Fallback hat
Übersetzerkommentare für mehrdeutige Strings einfügen

Ein kleines Beispiel veranschaulicht das besser.

Android beginnt üblicherweise mit einer Standard-strings.xml-Datei:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

Dann liest Ihre UI die Ressource, anstatt Englisch fest zu codieren:

Text(text = stringResource(R.string.checkout_cta))

Auf Apple-Plattformen verwaltet Xcode 15+ dieselbe Idee oft in einem String-Katalog. Ein vereinfachter Localizable.xcstrings-Auszug kann so aussehen:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

Sie müssen sich das Dateiformat nicht merken. Die praktische Lektion ist einfacher: Jeder benutzersichtbare String braucht eine einzige Wahrheitsquelle, genügend Kontext für Übersetzer und einen sicheren Fallback, wenn ein Locale unvollständig ist.

Wenn Ihre App auch strukturierte Sprachdateien mitliefert, kann unser Leitfaden zu Best JSON Translators in 2026 Ihnen bei der Automatisierung und Formaterhaltung helfen.

Wenn Sie eine direkte Tool-Option für App-Ressourcendateien suchen, ist OpenL JSON Translator einen Blick wert. Es wurde entwickelt, um .json-Dateien zu übersetzen, ohne Schlüssel oder Struktur zu beschädigen – genau das, was Sie brauchen, wenn App-Strings in maschinenlesbaren Lokalisierungsdateien gespeichert sind. Der Workflow ist einfach: Laden Sie die aus Ihrer App, Ihrem CMS oder Ihrer Lokalisierungspipeline exportierte JSON-Datei hoch, wählen Sie die Zielsprache und laden Sie eine übersetzte JSON-Datei mit derselben Struktur herunter. Laut der Produktseite werden über 100 Sprachen und Dateien bis zu 50 MB unterstützt, was es zu einem praktischen Erstpass-Tool für App-Lokalisierungsteams macht, die mit strukturierten Inhalten arbeiten.

Unterstützen Sie die App-Level-Sprachauswahl

Nutzer erwarten zunehmend, eine App-Sprache unabhängig von ihrer Gerätesprache wählen zu können.

Auf Apple-Plattformen können Nutzer ihre bevorzugte Sprache für eine App unabhängig von der Gerätesprache auswählen. Auf Android hat Android 13 eine zentralisierte App-Spracheinstellung hinzugefügt, und Google empfiehlt die Aktivierung automatischer App-spezifischer Sprachunterstützung oder die Anbindung Ihres Sprachwahlschalters an die offiziellen APIs.

Das ist für echte Produkte relevant. Zwei- und mehrsprachige Nutzer behalten ihr Telefon möglicherweise auf Englisch, bevorzugen aber eine Shopping-, Banking- oder Liefer-App in einer anderen Sprache. Wenn Ihre App ein einziges Sprachmodell erzwingt, schaffen Sie Reibung, bevor die Übersetzungsqualität überhaupt infrage gestellt wird.

Nutzen Sie den Plattform-Lokalisierungsstack

Widerstehen Sie dem Drang, ein paralleles Lokalisierungssystem zu erfinden, es sei denn, Sie brauchen wirklich eines.

Für die meisten Teams reicht der Standard-Plattform-Stack aus:

iOS: String-Kataloge, Localizable.strings, .stringsdict, Foundation-Formatierer, Auto Layout
Android: res/values/, locale-spezifische Ressourcenordner, LocaleConfig, setApplicationLocales(), supportsRtl

Eigene Lokalisierungsinfrastruktur ist bei sehr großem Umfang sinnvoll, aber sie bringt operativen Mehraufwand mit sich. Starten Sie mit dem nativen System und erweitern Sie es nur dort, wo Sie echte Probleme spüren.

Lokalisieren Sie die Teile, die die meisten Teams übersehen

Teams übersetzen oft sichtbare Sätze und übersehen die Produktmechaniken drumherum.

Pluralformen, Variablen und Grammatik

Pluralregeln sind nicht universell. Die Unicode-CLDR-Pluralregeln definieren Kategorien wie zero, one, two, few, many und other, und verschiedene Sprachen verwenden unterschiedliche Teilmengen. Apple weist darauf hin, dass in älteren .stringsdict-Workflows other die einzige erforderliche Kategorie ist, aber das Auslassen sprachspezifischer Kategorien kann dennoch grammatikalisch falsche Ausgaben erzeugen. Android und iOS setzen beide aus gutem Grund auf locale-bewusste Pluralbehandlung.

Hier versagt naive maschinelle Übersetzung:

1 file vs. 2 files ist im Englischen einfach
Slawische Sprachen benötigen oft mehr als zwei Pluralformen
Manche Sprachen verändern Substantive, Verben oder umgebende Wörter gemeinsam

Bauen Sie nie pluralisierte UI durch Verkettung von Fragmenten wie "You have " + count + " messages". Verwenden Sie stattdessen plattformeigene Plural-Ressourcen.

Hier ist die minimale Form davon auf jeder Plattform.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOS Legacy-.stringsdict-Beispiel:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

In Xcode 15 und höher empfiehlt Apple die Handhabung von Pluralformen in String-Katalogen, aber das Prinzip bleibt dasselbe: Geben Sie der Plattform ein Nachrichtenmuster und lassen Sie sie die richtige Sprachform wählen.

Für tiefergehende Workflow-Leitplanken rund um Platzhalter und strukturierte Strings siehe How to Translate Technical Docs Without Breaking Code.

Datumsangaben, Zahlen, Währungen und Maßeinheiten

Apple empfiehlt ausdrücklich die Verwendung von Foundation-APIs zur Formatierung von Datumsangaben, Längen, Gewichten, Preisen und Währungssymbolen über verschiedene Locales hinweg. Dasselbe Prinzip gilt für Android: Formatieren Sie Daten mit locale-bewussten APIs, anstatt Zeichensetzung, Dezimalzeichen oder Einheitenreihenfolge fest zu codieren.

Typische Fehler umfassen:

03/04/2026 bedeutet in verschiedenen Regionen unterschiedliche Dinge
Fest codierte Dollarzeichen für Nicht-USD-Märkte
1,234.56 wird in Locales, die Kommas als Dezimaltrennzeichen verwenden, falsch angezeigt
Maßeinheiten werden im falschen System angezeigt

Wenn Ihre App Terminplanung, Abrechnung, Lieferzeitfenster oder Analysen enthält, ist dies Teil der Lokalisierung, nicht der Feinpolitur.

Layout-Erweiterung und Rechts-nach-Links-Unterstützung

Englisch ist normalerweise kompakt. Deutsch wird länger. Arabisch und Hebräisch kehren die Leserichtung um. Ein Layout, das auf Englisch gut aussieht, kann in anderen Locales stark fehlerhaft erscheinen.

Apple empfiehlt das Testen mit Pseudosprachen, einschließlich einer Rechts-nach-Links-Pseudosprache und einer Doppellängen-Pseudosprache, bevor Sie überhaupt echte Übersetzungen importieren. Android empfiehlt die Verwendung von start und end anstelle von left und right, die Aktivierung von android:supportsRtl="true" und das Testen von RTL-Layouts auf dem Gerät mit Force RTL.

Ihre Checkliste hier ist einfach:

Erlauben Sie Buttons und Labels zu wachsen
Vermeiden Sie Container mit fester Breite für wichtige UI-Elemente
Spiegeln Sie richtungsabhängige UI, wo angemessen
Überprüfen Sie Icons, Chevrons, Fortschrittsabläufe und Karussells in RTL
Testen Sie gemischtdirektionalen Text wie arabische UI mit lateinischen Produktnamen oder Gutscheincodes

Bilder, Icons, Screenshots und Video

Apples Lokalisierungsleitfaden macht einen wichtigen Punkt, den viele Teams übersehen: Auch Bilder können lokalisiert werden. Das umfasst Bildsets, Symbolsets und Richtungsabhängigkeit für benutzerdefinierte Symbole. Wenn Ihr Screenshot englische UI, englischen Text in Bannern oder Links-nach-Rechts-Pfeile enthält, dann ist der Screenshot selbst nicht lokalisiert.

Das ist besonders wichtig für Onboarding-Bildschirme, Tutorial-Karten und App Store-Assets. Nutzer trennen nicht mental zwischen „Marketing-Visuals” und „Produktsprache”. Sie beurteilen das gesamte Erlebnis auf einmal.

Lokalisieren Sie Ihre App Store- und Google Play-Seiten separat

Hier verlieren viele Teams Installationen, selbst nachdem sie die In-App-Arbeit gut gemacht haben.

Anforderungen des App Store, die Sie einplanen sollten

Apple empfiehlt die Lokalisierung von Metadaten in App Store Connect, einschließlich App-Beschreibung, Schlüsselwörter, App-Vorschauen und Screenshots. Apple gibt außerdem an, dass Sie bis zu 10 Screenshots auf Ihrer Produktseite zeigen können und bis zu 3 App-Vorschauen pro unterstützter Gerätegröße und Sprache. App-Vorschauen können bis zu 30 Sekunden lang sein, und Screenshots sind noch wichtiger, wenn keine Vorschau vorhanden ist, da die ersten ein bis drei Screenshots in Suchergebnissen erscheinen können.

Das hat zwei Implikationen:

Ihre ersten Screenshots sind Sichtbarkeits-Assets, nicht nur Dokumentation.
Sie sollten Screenshots und Vorschauen für die wichtigsten Märkte lokalisieren, anstatt überall englische Assets wiederzuverwenden.

Anforderungen von Google Play, die Sie einplanen sollten

Google Play behandelt die Eintrags-Lokalisierung ebenfalls als eigenen Workflow. Die Play Console ermöglicht das Hinzufügen von lokalisiertem Text, Screenshots in der jeweiligen Sprache und lokalisierte grafische Assets. Wenn Sie Textübersetzungen ohne lokalisierte grafische Assets hinzufügen, zeigt Google an, dass weiterhin die Visuals der Standardsprache angezeigt werden.

Google weist außerdem darauf hin, dass Nutzer, wenn Sie keine eigenen Store-Eintragsübersetzungen hinzufügen, möglicherweise eine automatische Übersetzung mit einem Hinweis sehen, dass diese automatisch generiert wurde. Das ist als Fallback nützlich, aber keine starke Markteintritts-Strategie.

Ein besonders relevantes aktuelles Feature: Die Play Console gibt an, dass sie App-Strings kontinuierlich mit Gemini-Modellen kostenlos übersetzen kann. Genauer gesagt gilt dies laut Google für App-Strings aus strings.xml in App-Bundles, die in Draft-Releases hochgeladen werden, und Sie können die generierten Übersetzungen in einem integrierten Emulator vor der Veröffentlichung überprüfen. Das ist ein starker Weg, um die Erstabdeckung zu beschleunigen, sollte aber dennoch von einer menschlichen Überprüfung für kritische Abläufe gefolgt werden.

Bauen Sie einen Release- und QA-Workflow auf

Ein guter Lokalisierungsprozess dreht sich weniger um schnelleres Übersetzen als darum, weniger Überraschungen auszuliefern.

Schritt 1. Wählen Sie Ziel-Locales bewusst aus

Beginnen Sie nicht mit „alles in 20 Sprachen übersetzen”.

Starten Sie mit:

Ihrem aktuellen Download-Mix
Ländern, die Sie aktiv unterstützen
Abrechnung, rechtliche Abdeckung und Kundensupport
ob Sie sowohl die App als auch den Store-Eintrag gemeinsam lokalisieren können

Einen Markt vollständig zu bedienen schlägt in der Regel fünf Märkte halb zu bedienen.

Schritt 2. Erstellen Sie lokalisierungsbereite Assets

Bevor die Übersetzung beginnt, frieren Sie Folgendes ein und bereiten es vor:

Quell-Strings mit Kontext
Screenshot-Liste nach Locale
Glossar und Produktnamen-Regeln
Platzhalter-Regeln
Zeichenlimit-Vorgaben für Store-Texte
Locale-spezifische Prüfverantwortliche

Wenn die App separate Repositories oder mehrere Dateiformate verwendet, standardisieren Sie Benennung und Extraktion frühzeitig.

Schritt 3. Testen Sie zuerst mit Pseudolokalisierung

Auf Apple-Plattformen verwenden Sie Doppellängen- und Rechts-nach-Links-Pseudosprachen. Auf Android testen Sie nicht unterstützte Locales, Force RTL und App-Spracheinstellungen. Das findet:

Abgeschnittene Buttons
Abgeschnittene Überschriften
Versteckter Text
Falsche Ausrichtung
Nicht lokalisierte Strings
Fest codierte Links/Rechts-Annahmen

Das ist einer der günstigsten QA-Durchläufe, die Sie durchführen können.

Schritt 4. Führen Sie linguistische QA auf echten Geräten durch

Nachdem die Übersetzungen eingetroffen sind:

Testen Sie kritische Abläufe in jeder Zielsprache
Vergleichen Sie das Verhalten von Systemsprache und App-Sprache
Überprüfen Sie Pluralverhalten und Platzhalter
Prüfen Sie Zahlungen, Datumsangaben und Adressen
Überprüfen Sie Screenshots und Store-Einträge im jeweiligen Markt

Wenn ein Fehler Onboarding, Checkout, Identitätsverifizierung oder Benachrichtigungen betrifft, behandeln Sie ihn als Release-Blocker.

Eine Checkliste für den ersten Lokalisierungs-Sprint

Wenn dies Ihr erster ernsthafter Rollout ist, halten Sie den Sprint klein genug, um ihn sauber abzuschließen:

Diese Checkliste ist absichtlich eng gefasst. Ein Locale mit einem sauberen App-Erlebnis und synchronisierten Store-Assets lehrt Sie weit mehr als ein überstürzter Launch über viele Märkte hinweg.

Praxisbeispiele

Die obigen Kernideen sind nicht theoretisch.

DoorDash hat Übersetzung als Plattform-Problem behandelt

Im Jahr 2022 gab DoorDash an, bereits mehr als eine Million Strings in vier Sprachen übersetzt und das Onboarding neuer Sprachen von stundenlangem Entwickleraufwand auf einen einzigen Befehl in einer Minute reduziert zu haben. Die interessante Lektion ist nicht nur die Skalierung. Es ist die Struktur: DoorDash trennte statische und dynamische Strings, fügte Glossar- und Stilrichtlinien-Unterstützung hinzu und baute Schutzmaßnahmen, um zu verhindern, dass unübersetzte Strings durchrutschen.

In einem DoorDash-Blogbeitrag vom 2. Februar 2026 gab das Unternehmen an, dass seine neu aufgebaute Onboarding-Plattform nun Anmeldungen in allen DoorDash-Märkten unterstützt und schnelle internationale Launches mit nahtloser Lokalisierung ermöglicht. Genau so sieht ausgereifte Lokalisierung aus: wiederverwendbare Workflows, regionale Flexibilität und weniger Einzelfall-Workarounds.

Meta hat Lokalisierung sowohl als Sprach- als auch als App-Größenproblem behandelt

Meta gibt an, dass etwa 57 % der Facebook für Android-Nutzer und 49 % der Facebook für iOS-Nutzer die App in einer anderen Sprache als Englisch verwenden. Im selben Bericht sagt Meta, dass das Entfernen gebündelter Übersetzungsdateien bis zu 16,6 MB in der iOS-App einsparte und es Android ermöglichte, fast ein Dutzend weitere Sprachen hinzuzufügen, ohne die App-Größe zu erhöhen.

Die Erkenntnis ist auch für kleinere Teams nützlich: Lokalisierung hat technische Konsequenzen. Sie beeinflusst die Binärgröße, das Laufzeit-Laden, die Übersetzungsauslieferung und die Release-Mechanik – nicht nur das Texten.

Letzte Checkliste vor dem Ausliefern

Verwenden Sie dies als letzten Durchgang:

Alle benutzersichtbaren Strings sind externalisiert.
Standard-Fallback-Ressourcen sind vollständig.
Pluralformen und Platzhalter verwenden plattformeigene Lokalisierungsunterstützung.
Datumsangaben, Uhrzeiten, Zahlen, Währungen und Maßeinheiten sind locale-bewusst.
RTL-Layouts und gemischtdirektionaler Text wurden getestet.
Store-Eintragstexte sind für Zielmärkte lokalisiert.
Screenshots und Vorschauen sind für prioritäre Sprachen lokalisiert.
Die In-App-Sprachauswahl funktioniert wie erwartet auf iOS und Android.
Linguistische QA hat die wichtigsten Nutzerreisen abgedeckt.

Abschließende Gedanken

Die einfachste Art, über die Lokalisierung einer mobilen App nachzudenken, ist diese: Übersetzen Sie das Produkt, lokalisieren Sie das Erlebnis und testen Sie den Release.

Wenn Sie dies zum ersten Mal tun, streben Sie nicht gleich am ersten Tag eine perfekte globale Abdeckung an. Wählen Sie ein oder zwei strategische Locales, lokalisieren Sie die App und die Store-Seite gemeinsam, führen Sie einen ernsthaften QA-Durchlauf durch und lernen Sie aus der realen Nutzung. Wenn Sie bereits Ressourcendateien und entwicklerseitige Inhalte verwalten, kombinieren Sie diesen Workflow mit How to Translate Technical Docs Without Breaking Code und Best JSON Translators in 2026.

Wenn Sie diese Woche nur eine Aktion durchführen, dann diese: Wählen Sie 1 Locale, führen Sie 1 Pseudolokalisierungs-Durchlauf durch und lokalisieren Sie 1 passenden App Store- oder Google Play-Eintrag. Dieser dreiteilige Test sagt Ihnen mehr über Ihre Bereitschaft als zwanzig Locales parallel zu übersetzen.

Wenn Sie einen schnellen Erstdurchlauf für App-Texte, Screenshots oder strukturierte Sprachdateien benötigen, nutzen Sie Automatisierung, um den Entwurf zu beschleunigen, und behalten Sie dann einen menschlichen QA-Schritt vor dem Release bei. Das ist der Teil, der das Nutzervertrauen schützt und einen „übersetzten, aber nicht wirklich lokalisierten” Launch verhindert.

Referenzen

Apple Developer. Localization. https://developer.apple.com/localization/
Apple Developer. Creating Your Product Page. https://developer.apple.com/app-store/product-page/
Apple Developer. Upload app previews and screenshots. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
Apple Developer. Localizing strings that contain plurals. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
Apple Developer. Testing Your Internationalized App. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
Android Developers. Localize your app. https://developer.android.com/guide/topics/resources/localization
Android Developers. Per-app language preferences. https://developer.android.com/guide/topics/resources/app-languages
Android Developers. Support different languages and cultures. https://developer.android.com/training/basics/supporting-devices/languages
Google Play Console Help. Translate and localize your app. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
Google Play Console Help. Create and set up your app. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
Unicode CLDR. Plural Rules. https://cldr.unicode.org/index/cldr-spec/plural-rules
DoorDash Engineering. Building a Platform to Translate DoorDash into Multiple Languages. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
DoorDash Engineering. Unified Dasher Onboarding: A modular platform to scale globally. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
Engineering at Meta. Language packs: Meta’s mobile localization solution. https://engineering.fb.com/2022/05/09/android/language-packs/