Mobile App Localization

The Lingo.dev CLI translates native mobile resource files - Xcode .strings, Android XML, Flutter ARB, and React Native JSON - through a configured localization engine. The CLI auto-detects each file format from its extension, preserves structure, and handles plurals natively.

Platform Overview#

Prerequisites#

Every CLI run sends content through a localization engine - the configuration that determines which LLM model, glossary, brand voice, and rules apply. Create one in the Lingo.dev dashboard.

Install the CLI (Node.js 22+) and authenticate:

npm install -g @lingo.dev/cli
lingo login

lingo login signs you in with a one-time code. For CI, skip the interactive login and pass --api-key (or set LINGO_API_KEY).

Configure Your Platform#

Run lingo init to create .lingo/config.json (source/target locales plus your file patterns), then lingo link to attach your orgId and engineId. Commit .lingo/config.json to your repo. The examples below show the resulting config for each platform.

The pattern always points at your source file, and the CLI derives each target path from it. Usually that means swapping the locale it finds in the path (en.lproj → de.lproj, app_en.arb → app_de.arb). Two platforms are different, and both are handled for you: a String Catalog holds every locale in one file, so the target path is the source path; and Android keeps its default strings in an unqualified values/ with no locale in the path at all, so the CLI appends the target qualifier to it (values/ → values-de/).

{
  "orgId": "org_...",
  "engineId": "eng_...",
  "sourceLocale": "en",
  "targetLocales": ["es", "fr", "de", "ja"],
  "files": [{ "pattern": "MyApp/Localizable.xcstrings" }]
}

{
  "orgId": "org_...",
  "engineId": "eng_...",
  "sourceLocale": "en",
  "targetLocales": ["es", "fr", "de", "ja"],
  "files": [
    { "pattern": "MyApp/en.lproj/Localizable.strings" },
    { "pattern": "MyApp/en.lproj/Localizable.stringsdict" }
  ]
}

Running Translations#

Translate all resource files in one command:

lingo push

The CLI reads your source locale files, computes what changed since the last run using the lockfile (.lingo/lock.json, which you commit), translates only the delta, and writes results to target locale files.

On the first run - or whenever you add a new target locale - translate everything from scratch:

lingo push --backfill-missing

Target a specific platform when your project contains multiple resource types by passing a glob (there are no --bucket or --target-locale flags). Patterns are matched against source paths, so scope by the source file rather than a target:

lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"

To fetch the latest translations elsewhere (for example on another machine), run lingo pull. To verify translations are up to date without writing changes - useful as a deploy gate - run lingo check.

Plurals and Platform Conventions#

Each mobile platform handles plural forms differently - iOS uses .stringsdict or String Catalog rules, Android uses <plurals> XML elements, and Flutter uses ICU MessageFormat in ARB files. The CLI preserves each platform's native plural structure during translation and generates the correct plural categories for each target locale.

Automating in CI#

The recommended way to keep translations current is the Lingo.dev GitHub App. It runs server-side, reads your committed .lingo/config.json and engineId, and opens translation updates automatically - no runner, secret, or lockfile management on your side. If you prefer to run translations in your own pipeline, execute lingo push in your CI runner and commit the results.

Platform Deep Dives#

Next Steps#