La CLI de Lingo.dev traduce archivos de recursos nativos para móvil —.strings de Xcode, XML de Android, ARB de Flutter y JSON de React Native— a través de un motor de localización configurado. La CLI detecta automáticamente cada formato por su extensión, conserva la estructura y gestiona los plurales de forma nativa.
Resumen de plataformas#
| Plataforma | Formato nativo | Ruta típica del archivo de origen |
|---|---|---|
| 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 |
Requisitos previos#
Cada ejecución de CLI envía el contenido a través de un motor de localización: la configuración que determina qué modelo de LLM, glosario, voz de marca y reglas se aplican. Crea uno en el panel de Lingo.dev.
Instala la CLI (Node.js 22+) y autentícate:
npm install -g @lingo.dev/cli
lingo loginlingo login te inicia sesión con un código de un solo uso. En CI, omite el inicio de sesión interactivo y pasa --api-key (o configura LINGO_API_KEY).
Configura tu plataforma#
Ejecuta lingo init para crear .lingo/config.json (idiomas de origen y destino, además de tus patrones de archivo) y, después, lingo link para vincular tus orgId y engineId. Haz commit de .lingo/config.json en tu repositorio. Los ejemplos de abajo muestran la configuración resultante para cada plataforma.
El patrón siempre apunta a tu archivo de origen, y la CLI deriva a partir de él cada ruta de destino. Normalmente, eso significa sustituir el idioma que encuentra en la ruta (en.lproj → de.lproj, app_en.arb → app_de.arb). Hay dos plataformas que funcionan de forma distinta, y la CLI se encarga de ambas: un String Catalog reúne todos los idiomas en un único archivo, así que la ruta de destino coincide con la de origen; y Android guarda sus cadenas predeterminadas en un values/ sin calificador, sin ningún idioma en la ruta, así que la CLI añade el calificador de destino (values/ → values-de/).
Xcode admite tres formatos de localización. Usa el que mejor encaje con la configuración de tu proyecto.
Catálogos de cadenas (.xcstrings): el formato moderno de Xcode introducido en Xcode 15. Un único archivo JSON contiene todos los idiomas, y Xcode lo actualiza automáticamente cuando añades cadenas nuevas. La CLI modifica este archivo directamente, así que el patrón apunta a ese único catálogo, sin segmento de idioma.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [{ "pattern": "MyApp/Localizable.xcstrings" }]
}Archivos heredados .strings: un archivo por idioma en directorios [code].lproj/. El idioma de origen va en la ruta (en.lproj) y la CLI escribe cada destino en su propio directorio .lproj. Si tu proyecto también usa .stringsdict para los plurales, añade una segunda entrada de archivos.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [
{ "pattern": "MyApp/en.lproj/Localizable.strings" },
{ "pattern": "MyApp/en.lproj/Localizable.stringsdict" }
]
}También funciona un proyecto cuyo bundle del idioma de desarrollo sea Base.lproj en lugar de en.lproj; la CLI reconoce Base.lproj como idioma de origen.
Consulta la documentación de localización de Apple para configurar la infraestructura de internacionalización de Xcode.
Ejecutar traducciones#
Traduce todos los archivos de recursos con un solo comando:
lingo pushLa CLI lee los archivos del idioma de origen, calcula qué ha cambiado desde la última ejecución mediante el lockfile (.lingo/lock.json, que subes al repositorio), traduce solo el delta y escribe los resultados en los archivos de los idiomas de destino.
En la primera ejecución —o cada vez que añadas un nuevo idioma de destino—, traduce todo desde cero:
lingo push --backfill-missingApunta a una plataforma concreta cuando tu proyecto incluya varios tipos de recursos pasando un glob (no existen flags --bucket ni --target-locale). Los patrones se comparan con las rutas de origen, así que delimita por el archivo de origen en lugar de por uno de destino:
lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"Para traer las traducciones más recientes a otro entorno (por ejemplo, otra máquina), ejecuta lingo pull. Para comprobar que las traducciones están al día sin escribir cambios —útil como control antes del despliegue—, ejecuta lingo check.
Plurales y convenciones de cada plataforma#
Cada plataforma móvil gestiona los plurales de forma distinta: iOS usa .stringsdict o las reglas de String Catalog, Android usa elementos XML <plurals> y Flutter usa ICU MessageFormat en archivos ARB. La CLI conserva la estructura plural nativa de cada plataforma durante la traducción y genera las categorías de plural correctas para cada idioma de destino.
Notas para traductores
Las cadenas de móvil suelen ser breves y muy dependientes del contexto. Usa notas para traductores en los archivos .xcstrings de Xcode para dar al motor de localización contexto sobre dónde aparece una cadena: «texto de botón en el flujo de pago» se traduce de forma distinta a «elemento del menú de navegación».
Automatización en CI#
La forma recomendada de mantener las traducciones al día es la GitHub App de Lingo.dev. Se ejecuta en el servidor, lee tus archivos versionados .lingo/config.json y engineId, y abre automáticamente actualizaciones de traducción, sin que tengas que gestionar runners, secretos ni lockfiles. Si prefieres ejecutar las traducciones en tu propio pipeline, ejecuta lingo push en tu runner de CI y haz commit de los resultados.
