El CLI de Lingo.dev traduce archivos de recursos nativos para apps móviles —Xcode .strings, Android XML, Flutter ARB y React Native JSON— mediante un motor de localización configurado. El CLI detecta automáticamente cada formato según su extensión, conserva la estructura y maneja los plurales de forma nativa.
Resumen de plataformas#
| Plataforma | Formato nativo | Ruta típica del archivo fuente |
|---|---|---|
| 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 mediante un motor de localización, la configuración que define qué modelo de LLM, glosario, voz de marca y reglas se aplican. Crea uno en el panel de Lingo.dev.
Instala el CLI (Node.js 22+) y autentícate:
npm install -g @lingo.dev/cli
lingo loginlingo login 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 los patrones de tus archivos) y luego 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 fuente, y el CLI deriva cada ruta de destino a partir de ahí. Por lo general, eso implica sustituir el idioma que encuentra en la ruta (en.lproj → de.lproj, app_en.arb → app_de.arb). Hay dos Plataformas que funcionan distinto, y el CLI se encarga de ambas por ti: un String Catalog reúne todos los idiomas en un solo archivo, así que la ruta de destino es la misma que la de origen; y Android guarda sus strings predeterminados en un values/ sin calificador, sin ningún idioma en la ruta, así que el CLI agrega el calificador de destino (values/ → values-de/).
Xcode admite tres formatos de localización. Usa el que mejor se ajuste a la configuración de tu proyecto.
String Catalogs (.xcstrings): el formato moderno de Xcode, introducido en Xcode 15. Un solo archivo JSON contiene todos los idiomas, y Xcode lo actualiza automáticamente cuando agregas nuevas cadenas. El CLI modifica este archivo directamente, así que el patrón apunta a un ú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 dentro de directorios [code].lproj/. El idioma de origen va en la ruta (en.lproj) y el CLI escribe cada destino en su propio directorio .lproj. Si tu proyecto también usa .stringsdict para plurales, agrega una segunda entrada en 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" }
]
}También funciona un proyecto cuyo bundle de idioma de desarrollo es Base.lproj en lugar de en.lproj; el CLI reconoce Base.lproj como idioma de origen.
Consulta la documentación de localización de Apple para configurar la infraestructura de i18n de Xcode.
Ejecuta las traducciones#
Traduce todos los archivos de recursos con un solo comando:
lingo pushEl CLI lee tus archivos del idioma de origen, calcula qué cambió desde la última ejecución usando el lockfile (.lingo/lock.json, que haces commit), 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 agregues un nuevo idioma de destino, traduce todo desde cero:
lingo push --backfill-missingApunta a una plataforma específica 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 uno de destino:
lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"Para obtener las traducciones más recientes en otro entorno (por ejemplo, en otra máquina), ejecuta lingo pull. Para verificar que las traducciones estén actualizadas sin escribir cambios —útil como control antes del despliegue— ejecuta lingo check.
Plurales y convenciones de cada plataforma#
Cada plataforma móvil maneja las formas 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 plurales correctas para cada idioma de destino.
Notas para traductores
Las cadenas móviles suelen ser cortas y depender mucho del contexto. Usa notas para traductores en archivos .xcstrings de Xcode para darle al motor de localización contexto sobre dónde aparece una cadena: "etiqueta de botón en el flujo de pago" se traduce distinto de "elemento del menú de navegación".
Automatización en CI#
La forma recomendada de mantener las traducciones al día es la Lingo.dev GitHub App. Se ejecuta del lado del servidor, lee tus archivos .lingo/config.json y engineId ya confirmados, y abre actualizaciones de traducción automáticamente, 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.
