Le CLI de Lingo.dev traduit les fichiers de ressources mobiles natifs — Xcode .strings, Android XML, Flutter ARB et React Native JSON — via un moteur de localisation configuré. Chaque plateforme dispose d’un type de bucket dédié, capable de comprendre le format de fichier, d’en préserver la structure et de gérer les pluriels nativement.
Vue d’ensemble des plateformes#
| Plateforme | Format natif | Bucket CLI | Chemin de fichier habituel |
|---|---|---|---|
| iOS (Xcode) | .strings | xcode-strings | [locale].lproj/Localizable.strings |
| iOS (Xcode) | .stringsdict | xcode-stringsdict | [locale].lproj/Localizable.stringsdict |
| iOS (Xcode) | .xcstrings | xcode-xcstrings | Localizable.xcstrings |
| Android | strings.xml | android | app/src/main/res/values-[locale]/strings.xml |
| Flutter | .arb | flutter | lib/l10n/app_[locale].arb |
| React Native | .json | json | src/locales/[locale].json |
Prérequis#
À chaque exécution, le CLI envoie le contenu via un moteur de localisation — la configuration qui détermine le modèle LLM, le glossaire, la voix de marque et les instructions à appliquer. Créez-en un dans le tableau de bord Lingo.dev, puis générez une clé API.
Configurez votre plateforme#
Xcode prend en charge trois formats de localisation. Utilisez celui qui correspond à la configuration de votre projet.
String Catalogs (.xcstrings) — le format Xcode moderne introduit avec Xcode 15. Un seul fichier JSON contient toutes les langues, et Xcode le met à jour automatiquement lorsque vous ajoutez de nouvelles chaînes. Le CLI modifie ce fichier directement — aucun placeholder [locale] n’est nécessaire.
{
"$schema": "https://lingo.dev/schema/i18n.json",
"version": "1.15",
"locale": {
"source": "en",
"targets": ["es", "fr", "de", "ja"]
},
"buckets": {
"xcode-xcstrings": {
"include": ["MyApp/Localizable.xcstrings"]
}
}
}Fichiers .strings legacy — un fichier par langue dans des répertoires [locale].lproj/. Si votre projet utilise aussi .stringsdict pour les pluriels, ajoutez les deux buckets.
{
"$schema": "https://lingo.dev/schema/i18n.json",
"version": "1.15",
"locale": {
"source": "en",
"targets": ["es", "fr", "de", "ja"]
},
"buckets": {
"xcode-strings": {
"include": ["MyApp/[locale].lproj/Localizable.strings"]
},
"xcode-stringsdict": {
"include": ["MyApp/[locale].lproj/Localizable.stringsdict"]
}
}
}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 :
npx lingo.dev@latest runLe CLI lit vos fichiers de langue source, identifie ce qui a changé depuis la dernière exécution à l’aide du lockfile, traduit uniquement le delta, puis écrit les résultats dans les fichiers de langue cible.
Ciblez une plateforme spécifique lorsque votre projet contient plusieurs types de ressources :
npx lingo.dev@latest run --bucket android
npx lingo.dev@latest run --bucket xcode-xcstringsPluriels 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 ».
