Le CLI Lingo.dev traduit les fichiers de ressources mobiles natifs — Xcode .strings, XML Android, ARB Flutter et JSON React Native — via un moteur de localisation configuré. Le CLI détecte automatiquement chaque format de fichier à partir de son extension, en préserve la structure et gère nativement les pluriels.
Vue d’ensemble des plateformes#
| Plateforme | Format natif | Chemin type du fichier source |
|---|---|---|
| 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 |
Prérequis#
À chaque exécution du CLI, le contenu passe par un moteur de localisation — la configuration qui détermine le modèle de LLM, le glossaire, la voix de marque et les règles à appliquer. Créez-en un dans le tableau de bord Lingo.dev.
Installez le CLI (Node.js 22+) et authentifiez-vous :
npm install -g @lingo.dev/cli
lingo loginlingo login vous connecte à l’aide d’un code à usage unique. Pour la CI, ignorez la connexion interactive et passez --api-key (ou définissez LINGO_API_KEY).
Configurez votre plateforme#
Exécutez lingo init pour créer .lingo/config.json (langues source/cible et motifs de fichiers), puis lingo link pour y associer votre orgId et votre engineId. Validez .lingo/config.json dans votre dépôt. Les exemples ci-dessous montrent la configuration obtenue pour chaque plateforme.
Le motif pointe toujours vers votre fichier source, et le CLI en déduit chaque chemin cible. Le plus souvent, cela revient à remplacer la langue repérée dans le chemin (en.lproj → de.lproj, app_en.arb → app_de.arb). Deux plateformes font exception, et le CLI les gère pour vous : un catalogue de chaînes regroupe toutes les langues dans un seul fichier, donc le chemin cible est identique au chemin source ; et Android stocke ses chaînes par défaut dans un values/ non qualifié, sans aucune langue dans le chemin, donc le CLI y ajoute le qualifiant cible (values/ → values-de/).
Xcode prend en charge trois formats de localisation. Utilisez celui qui correspond à la configuration de votre projet.
Catalogues de chaînes (.xcstrings) — le format Xcode moderne introduit avec Xcode 15. Un unique fichier JSON contient toutes les langues, et Xcode le met à jour automatiquement lorsque vous ajoutez de nouvelles chaînes. Le CLI modifie ce fichier sur place ; le motif pointe donc vers ce catalogue unique, sans segment de langue.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [{ "pattern": "MyApp/Localizable.xcstrings" }]
}Fichiers .strings hérités — un fichier par langue dans des répertoires [code].lproj/. La langue source figure dans le chemin (en.lproj) et le CLI écrit chaque cible dans son propre répertoire .lproj. Si votre projet utilise aussi .stringsdict pour les pluriels, ajoutez une deuxième entrée files.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [
{ "pattern": "MyApp/en.lproj/Localizable.strings" },
{ "pattern": "MyApp/en.lproj/Localizable.stringsdict" }
]
}Un projet dont le bundle de langue de développement est Base.lproj plutôt que en.lproj fonctionne aussi : le CLI reconnaît Base.lproj comme langue source.
Consultez la documentation sur la localisation d’Apple pour mettre en place l’infrastructure i18n de Xcode.
Lancer les traductions#
Traduisez tous les fichiers de ressources en une seule commande :
lingo pushLe CLI lit vos fichiers de langue source, calcule ce qui a changé depuis la dernière exécution à l’aide du lockfile (.lingo/lock.json, que vous validez), traduit uniquement le delta, puis écrit les résultats dans les fichiers de langue cible.
Lors de la première exécution — ou chaque fois que vous ajoutez une nouvelle langue cible — retraduisez l’ensemble depuis zéro :
lingo push --backfill-missingCiblez une plateforme précise lorsque votre projet contient plusieurs types de ressources en passant un glob (il n’existe pas de flags --bucket ou --target-locale). Les motifs sont comparés aux chemins source : limitez donc la portée via le fichier source, plutôt que via une cible :
lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"Pour récupérer les dernières traductions ailleurs (par exemple sur une autre machine), exécutez lingo pull. Pour vérifier que les traductions sont à jour sans écrire de modifications — pratique comme garde-fou avant déploiement — exécutez lingo check.
Pluriels et conventions par plateforme#
Chaque plateforme mobile gère les formes plurielles différemment — iOS utilise .stringsdict ou les règles des String Catalogs, Android utilise des éléments XML <plurals>, et Flutter utilise ICU MessageFormat dans les fichiers ARB. Le CLI préserve la structure plurielle native de chaque plateforme pendant la traduction et génère les bonnes catégories de pluriel pour chaque langue cible.
Notes de traduction
Les chaînes mobiles sont souvent courtes et très dépendantes du contexte. Utilisez les notes de traduction dans les fichiers .xcstrings de Xcode pour donner au moteur de localisation le contexte d’affichage d’une chaîne — « libellé de bouton dans le tunnel de paiement » ne se traduit pas comme « élément de menu de navigation ».
Automatiser en CI#
La méthode recommandée pour garder vos traductions à jour est la GitHub App Lingo.dev. Elle s’exécute côté serveur, lit vos fichiers .lingo/config.json et engineId validés, et ouvre automatiquement les mises à jour de traduction — sans gestion de runner, de secret ou de lockfile de votre côté. Si vous préférez exécuter les traductions dans votre propre pipeline, lancez lingo push dans votre runner CI et validez les résultats.
