Die Lingo.dev CLI übersetzt native mobile Ressourcendateien — Xcode .strings, Android-XML, Flutter-ARB und React-Native-JSON — über eine konfigurierte Lokalisierungs-Engine. Die CLI erkennt jedes Dateiformat automatisch anhand der Erweiterung, behält die Struktur bei und verarbeitet Pluralformen nativ.
Plattformen im Überblick#
| Plattform | Natives Format | Typischer Pfad zur Quelldatei |
|---|---|---|
| iOS (Xcode) | .strings | en.lproj/Localizable.strings |
| iOS (Xcode) | .stringsdict | en.lproj/Localizable.stringsdict |
| iOS (Xcode) | .xcstrings | Localizable.xcstrings |
| Android | strings.xml | app/src/main/res/values/strings.xml |
| Flutter | .arb | lib/l10n/app_en.arb |
| React Native | .json | src/locales/en.json |
Voraussetzungen#
Bei jedem CLI-Durchlauf werden Inhalte über eine Lokalisierungs-Engine gesendet – die Konfiguration, die festlegt, welches LLM-Modell, Glossar, welche Markenstimme und welche Regeln gelten. Erstelle sie im Lingo.dev-Dashboard.
Installiere die CLI (Node.js 22+) und melde dich an:
npm install -g @lingo.dev/cli
lingo loginlingo login meldet dich per Einmalcode an. Für CI überspringst du den interaktiven Login und übergibst --api-key (oder setzt LINGO_API_KEY).
Deine Plattform konfigurieren#
Führe lingo init aus, um .lingo/config.json zu erstellen (Quell-/Ziel-Sprachen plus deine Dateimuster), und anschließend lingo link, um orgId und engineId zu verknüpfen. Committe .lingo/config.json in dein Repository. Die Beispiele unten zeigen die resultierende Konfiguration für jede Plattform.
Das Muster verweist immer auf deine Quelldatei, und die CLI leitet daraus jeden Zielpfad ab. In der Regel bedeutet das, die im Pfad gefundene Sprache auszutauschen (en.lproj → de.lproj, app_en.arb → app_de.arb). Bei zwei Plattformen ist es anders – und die CLI kümmert sich in beiden Fällen darum: Ein String Catalog enthält alle Sprachen in einer einzigen Datei, daher ist der Zielpfad identisch mit dem Quellpfad. Und Android speichert seine Standard-Strings in einem nicht qualifizierten values/ ganz ohne Sprache im Pfad, daher hängt die CLI den Ziel-Qualifier daran an (values/ → values-de/).
Xcode unterstützt drei Lokalisierungsformate. Verwende das Format, das zu deinem Projekt-Setup passt.
String Catalogs (.xcstrings) — das moderne Xcode-Format, das mit Xcode 15 eingeführt wurde. Eine einzige JSON-Datei enthält alle Sprachen, und Xcode aktualisiert sie automatisch, wenn du neue Strings hinzufügst. Die CLI aktualisiert diese Datei direkt, daher zeigt das Muster auf den einzelnen Katalog ohne Sprachsegment.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [{ "pattern": "MyApp/Localizable.xcstrings" }]
}Legacy-.strings-Dateien — eine Datei pro Sprache in [code].lproj/-Verzeichnissen. Die Quell-Sprache steht im Pfad (en.lproj), und die CLI schreibt jede Zielsprache in ihr eigenes .lproj-Verzeichnis. Wenn dein Projekt auch .stringsdict für Pluralformen verwendet, füge einen zweiten Dateieintrag hinzu.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [
{ "pattern": "MyApp/en.lproj/Localizable.strings" },
{ "pattern": "MyApp/en.lproj/Localizable.stringsdict" }
]
}Auch ein Projekt, dessen Bundle für die Entwicklungssprache Base.lproj statt en.lproj ist, funktioniert – die CLI erkennt Base.lproj als Quell-Sprache.
In Apples Lokalisierungsdokumentation findest du alles zur Einrichtung der i18n-Infrastruktur in Xcode.
Übersetzungen ausführen#
Übersetze alle Ressourcendateien mit einem einzigen Befehl:
lingo pushDie CLI liest deine Quell-Sprachdateien, ermittelt mithilfe der lockfile (.lingo/lock.json, die du committest), was sich seit dem letzten Lauf geändert hat, übersetzt nur das Delta und schreibt die Ergebnisse in die Ziel-Sprachdateien.
Beim ersten Lauf — oder wenn du eine neue Ziel-Sprache hinzufügst — wird alles von Grund auf übersetzt:
lingo push --backfill-missingWenn dein Projekt mehrere Ressourcentypen enthält, kannst du per Glob eine bestimmte Plattform auswählen (es gibt keine Flags --bucket oder --target-locale). Muster werden mit Quellpfaden abgeglichen, also grenze über die Quelldatei statt über ein Ziel ein:
lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"Um anderswo die neuesten Übersetzungen abzurufen (zum Beispiel auf einem anderen Rechner), führe lingo pull aus. Um zu prüfen, ob die Übersetzungen aktuell sind, ohne Änderungen zu schreiben — nützlich als Deploy-Gate — führe lingo check aus.
Pluralformen und Plattformkonventionen#
Jede mobile Plattform behandelt Pluralformen anders – iOS verwendet .stringsdict oder die Regeln von String Catalogs, Android nutzt <plurals>-XML-Elemente und Flutter setzt auf ICU MessageFormat in ARB-Dateien. Die CLI bewahrt bei der Übersetzung die native Pluralstruktur jeder Plattform und erzeugt die korrekten Pluralkategorien für jede Zielsprache.
Hinweise für Übersetzer:innen
Mobile Strings sind oft kurz und stark kontextabhängig. Verwende Hinweise für Übersetzer:innen in Xcode-.xcstrings-Dateien, um der Lokalisierungs-Engine Kontext dazu zu geben, wo ein String erscheint – „Button-Beschriftung im Checkout-Flow“ wird anders übersetzt als „Navigationsmenüpunkt“.
Automatisierung in CI#
Die empfohlene Methode, Übersetzungen aktuell zu halten, ist die Lingo.dev GitHub App. Sie läuft serverseitig, liest deine committeten .lingo/config.json und engineId und erstellt Übersetzungsupdates automatisch — ganz ohne Runner-, Secret- oder lockfile-Verwaltung auf deiner Seite. Wenn du Übersetzungen lieber in deiner eigenen Pipeline ausführen möchtest, führe lingo push in deinem CI-Runner aus und committe die Ergebnisse.
