Guías
Trabajar con traductores
Tus catálogos son JSON plano, sin nada propietario que convertir. Eso te da tres caminos para traducir: entregar los archivos a un TMS, hacer round-trip de archivos de traductor con export/import, o traducir a máquina con translate.
JSON plano, sin lock-in
La mayoría de los TMS (Crowdin, Lokalise, Phrase y compañía) ingieren JSON plano de forma nativa. Apunta la plataforma a locales/ y listo: sin paso de export, sin formato propio. Las traducciones vuelven como los mismos archivos, y cada cambio se revisa como un diff normal.
Export para humanos
Cuando no hay TMS (un traductor freelance, una agencia, un colega con una hoja de cálculo), verbaly export escribe un archivo por idioma listo para el traductor, con el texto fuente junto a cada traducción.
npx verbaly export # verbaly-export/es.xlf, pt.xlf (XLIFF 2.0)
npx verbaly export --format csv # key,source,target (opens in any spreadsheet)
npx verbaly export --missing # only what's untranslatedXLIFF 2.0 es el formato de intercambio de la industria, así que los TMS y herramientas CAT lo abren directo. CSV es para todos los demás: tres columnas, editable en cualquier lado.
Antes de exportar, verbaly status (0.23.0) muestra cuánto falta por idioma: es: 45/48 translated (94%).
Import de vuelta, validado
verbaly import lee los archivos traducidos (XLIFF 2.0 o 1.2, o CSV) y rellena tus catálogos. Cada entrada pasa la misma validación estructural que la traducción a máquina: placeholders, variantes de plural y tags deben sobrevivir intactos. Lo demás se rechaza y se reporta, nunca se escribe.
npx verbaly import verbaly-export/es.xlf
# es: +42 imported
# es: 1 rejected (params/tags not preserved): home.greeting
npx verbaly import es.csv --dry-run # preview without writing
npx verbaly import es.xlf --overwrite # replace existing translationsLas traducciones existentes se conservan salvo que pases --overwrite; las keys desconocidas se ignoran y se reportan. El idioma destino sale del propio archivo (o del nombre del archivo en CSV), y --locale gana sobre ambos.
Exportar para apps móviles
Los mismos catálogos pueden viajar a una app móvil hermana como recursos nativos: android-xml escribe carpetas strings.xml que puedes soltar en res/, y ios-strings escribe carpetas .lproj para Xcode.
npx verbaly export --format android-xml # verbaly-export/values-es/strings.xml, values-pt-rBR/…
npx verbaly export --format ios-strings # verbaly-export/es.lproj/Localizable.strings, …Tu idioma fuente se vuelve el default de la plataforma (values/strings.xml, en.lproj), y las claves sin traducir se omiten para que la app haga fallback a él en vez de mostrar texto vacío. Las keys se adaptan a nombres de recurso válidos de Android, los valores conservan su sintaxis de parámetros intacta, y el flujo es de ida: las traducciones van de tus catálogos a la app.
¿Aún sin humanos disponibles?
La traducción a máquina llena los huecos con las mismas garantías estructurales, y todo lo que un provider o una persona haga mal lo atrapa verbaly check en CI.