Trabalhar com tradutores

Seus catálogos são JSON plano, sem nada proprietário para converter. Isso te dá três caminhos para traduzir: entregar os arquivos a um TMS, fazer round-trip de arquivos de tradutor com export/import, ou traduzir por máquina com translate.

JSON plano, sem lock-in

A maioria dos TMS (Crowdin, Lokalise, Phrase e companhia) ingere JSON plano nativamente. Aponte a plataforma para locales/ e pronto: sem etapa de export, sem formato próprio. As traduções voltam como os mesmos arquivos, e cada mudança é revisada como um diff normal.

Export para humanos

Quando não há TMS (um tradutor freelance, uma agência, um colega com uma planilha), verbaly export escreve um arquivo por idioma pronto para o tradutor, com o texto fonte ao lado de cada tradução.

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 untranslated

XLIFF 2.0 é o formato de intercâmbio da indústria, então TMS e ferramentas CAT o abrem direto. CSV é para todo o resto: três colunas, editável em qualquer lugar.

Antes de exportar, verbaly status (0.23.0) mostra quanto falta por idioma: es: 45/48 translated (94%).

Import de volta, validado

verbaly import lê os arquivos traduzidos (XLIFF 2.0 ou 1.2, ou CSV) e preenche seus catálogos. Cada entrada passa pela mesma validação estrutural da tradução por máquina: placeholders, variantes de plural e tags devem sobreviver intactos. O resto é rejeitado e reportado, nunca escrito.

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 translations

As traduções existentes são mantidas a menos que você passe --overwrite; keys desconhecidas são ignoradas e reportadas. O idioma de destino vem do próprio arquivo (ou do nome do arquivo no CSV), e --locale vence os dois.

Exportar para apps mobile

Os mesmos catálogos podem viajar para um app mobile irmão como recursos nativos: android-xml escreve pastas strings.xml que você solta em res/, e ios-strings escreve pastas .lproj para o 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, …

Seu idioma fonte vira o padrão da plataforma (values/strings.xml, en.lproj), e chaves sem tradução ficam de fora para o app fazer fallback a ele em vez de mostrar texto vazio. As keys são adaptadas a nomes de recurso válidos do Android, os valores mantêm sua sintaxe de parâmetros intacta, e o fluxo é de mão única: as traduções vão dos seus catálogos para o app.

Ainda sem humanos disponíveis?

A tradução por máquina preenche as lacunas com as mesmas garantias estruturais, e tudo o que um provider ou uma pessoa errar é pego pelo verbaly check no CI.