O CLI da Lingo.dev traduz arquivos nativos de recursos mobile — Xcode .strings, Android XML, Flutter ARB e React Native JSON — por meio de um engine de localização configurado. O CLI detecta automaticamente cada formato pela extensão do arquivo, preserva a estrutura e lida com plurais nativamente.
Visão geral das plataformas#
| Plataforma | Formato nativo | Caminho típico do arquivo-fonte |
|---|---|---|
| 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 |
Pré-requisitos#
Sempre que o CLI é executado, o conteúdo passa por um engine de localização — a configuração que define qual modelo de LLM, glossário, voz da marca e regras serão aplicados. Crie um no painel da Lingo.dev.
Instale o CLI (Node.js 22+) e faça a autenticação:
npm install -g @lingo.dev/cli
lingo loginlingo login faz seu login com um código de uso único. Em CI, pule o login interativo e passe --api-key (ou defina LINGO_API_KEY).
Configure sua plataforma#
Execute lingo init para criar .lingo/config.json (idiomas de origem/destino e seus padrões de arquivo) e, em seguida, lingo link para vincular suas orgId e engineId. Faça commit de .lingo/config.json no seu repositório. Os exemplos abaixo mostram a configuração resultante em cada plataforma.
O padrão sempre aponta para o arquivo de origem, e a CLI gera cada caminho de destino a partir dele. Na prática, isso geralmente significa trocar o idioma encontrado no caminho (en.lproj → de.lproj, app_en.arb → app_de.arb). Em duas Plataformas, porém, isso funciona de outro jeito — e a CLI cuida de tudo para você: um String Catalog reúne todos os idiomas em um único arquivo, então o caminho de destino é igual ao de origem; e o Android mantém as strings padrão em um values/ sem qualificador, sem idioma no caminho, então a CLI acrescenta o qualificador de destino (values/ → values-de/).
O Xcode oferece suporte a três formatos de localização. Use aquele que corresponde à configuração do seu projeto.
String Catalogs (.xcstrings) — o formato moderno do Xcode, introduzido no Xcode 15. Um único arquivo JSON reúne todos os idiomas, e o Xcode o atualiza automaticamente quando você adiciona novas strings. O CLI altera esse arquivo diretamente, então o padrão aponta para o catálogo único, sem segmento de idioma.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [{ "pattern": "MyApp/Localizable.xcstrings" }]
}Arquivos legados .strings — um arquivo por idioma em diretórios [code].lproj/. O idioma de origem aparece no caminho (en.lproj), e o CLI grava cada destino no respectivo diretório .lproj. Se o seu projeto também usa .stringsdict para plurais, adicione uma segunda entrada de arquivo.
{
"orgId": "org_...",
"engineId": "eng_...",
"sourceLocale": "en",
"targetLocales": ["es", "fr", "de", "ja"],
"files": [
{ "pattern": "MyApp/en.lproj/Localizable.strings" },
{ "pattern": "MyApp/en.lproj/Localizable.stringsdict" }
]
}Um projeto cujo bundle do idioma de desenvolvimento é Base.lproj, em vez de en.lproj, também funciona — a CLI reconhece Base.lproj como idioma de origem.
Consulte a documentação de localização da Apple para configurar a infraestrutura de i18n do Xcode.
Executando traduções#
Traduza todos os arquivos de recursos com um único comando:
lingo pushO CLI lê os arquivos do idioma de origem, identifica o que mudou desde a última execução usando o lockfile (.lingo/lock.json, que vai com commit), traduz apenas o delta e grava os resultados nos arquivos dos idiomas de destino.
Na primeira execução — ou sempre que você adicionar um novo idioma de destino — traduza tudo do zero:
lingo push --backfill-missingDirecione para uma plataforma específica quando seu projeto tiver vários tipos de recurso, passando um glob (não há flags --bucket nem --target-locale). Os padrões são comparados com os caminhos de origem, então delimite pelo arquivo de origem, e não pelo de destino:
lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"Para buscar as traduções mais recentes em outro ambiente (por exemplo, em outra máquina), execute lingo pull. Para verificar se as traduções estão atualizadas sem gravar alterações — útil como etapa de validação antes do deploy — execute lingo check.
Plurais e convenções de cada plataforma#
Cada plataforma mobile lida com formas plurais de um jeito diferente — iOS usa .stringsdict ou regras de String Catalog, Android usa elementos XML <plurals> e Flutter usa ICU MessageFormat em arquivos ARB. A CLI preserva a estrutura plural nativa de cada plataforma durante a tradução e gera as categorias de plural corretas para cada idioma de destino.
Notas para tradutores
Strings mobile costumam ser curtas e depender bastante de contexto. Use notas para tradutores em arquivos .xcstrings do Xcode para dar ao engine de localização mais contexto sobre onde uma string aparece — "rótulo de botão no fluxo de checkout" é traduzido de forma diferente de "item de menu de navegação".
Automatização em CI#
A forma recomendada de manter as traduções em dia é o Lingo.dev GitHub App. Ele roda no servidor, lê o .lingo/config.json e o engineId versionados no seu repositório e abre atualizações de tradução automaticamente — sem runner, secret nem gerenciamento de lockfile da sua parte. Se preferir executar as traduções no seu próprio pipeline, rode lingo push no runner do CI e faça commit dos resultados.
