A CLI da Lingo.dev traduz ficheiros de recursos nativos para dispositivos móveis — Xcode .strings, Android XML, Flutter ARB e React Native JSON — através de um motor de localização configurado. A CLI deteta automaticamente cada formato de ficheiro pela respetiva extensão, preserva a estrutura e trata os plurais de forma nativa.
Visão Geral das Plataformas#
| Plataforma | Formato nativo | Caminho típico do ficheiro de origem |
|---|---|---|
| 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#
Cada execução da CLI envia conteúdo através de um motor de localização — a configuração que determina que modelo de LLM, glossário, voz da marca e regras se aplicam. Crie um no painel de controlo da Lingo.dev.
Instale a CLI (Node.js 22+) e autentique-se:
npm install -g @lingo.dev/cli
lingo loginlingo login inicia sessão com um código de utilização única. Para CI, ignore o início de sessão interativo e passe --api-key (ou defina LINGO_API_KEY).
Configure a Sua Plataforma#
Execute lingo init para criar .lingo/config.json (idiomas de origem/destino e os padrões dos seus ficheiros) e, depois, lingo link para associar o seu orgId e engineId. Faça commit de .lingo/config.json no repositório. Os exemplos abaixo mostram a configuração resultante para cada plataforma.
O padrão aponta sempre para o ficheiro de origem, e a CLI gera cada caminho de destino a partir dele. Normalmente, isso significa trocar o idioma encontrado no caminho (en.lproj → de.lproj, app_en.arb → app_de.arb). Há duas plataformas que funcionam de forma diferente, e a CLI trata de ambas: um Catálogo de Strings reúne todos os idiomas num único ficheiro, por isso o caminho de destino é o mesmo da origem; e o Android guarda as strings predefinidas num values/ sem qualificador, sem qualquer idioma no caminho, pelo que a CLI lhe acrescenta o qualificador de destino (values/ → values-de/).
O Xcode suporta três formatos de localização. Use o que melhor se adequa à configuração do seu projeto.
Catálogos de strings (.xcstrings) — o formato moderno do Xcode, introduzido no Xcode 15. Um único ficheiro JSON contém todos os idiomas, e o Xcode atualiza-o automaticamente quando adiciona novas strings. A CLI altera este ficheiro diretamente, por isso 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" }]
}Ficheiros .strings legados — um ficheiro por idioma em diretórios [code].lproj/. O idioma de origem está no caminho (en.lproj) e a CLI escreve cada destino no respetivo diretório .lproj. Se o seu projeto também usar .stringsdict para plurais, adicione uma segunda entrada em 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" }
]
}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.
Executar Traduções#
Traduza todos os ficheiros de recursos com um único comando:
lingo pushA CLI lê os ficheiros do seu idioma de origem, calcula o que mudou desde a última execução com base no lockfile (.lingo/lock.json, ao qual faz commit), traduz apenas o delta e escreve os resultados nos ficheiros dos idiomas de destino.
Na primeira execução — ou sempre que adicionar um novo idioma de destino — traduza tudo de raiz:
lingo push --backfill-missingDirecione para uma plataforma específica quando o seu projeto inclui vários tipos de recursos, passando um glob (não existem opções --bucket nem --target-locale). Os padrões são comparados com os caminhos de origem, por isso delimite pelo ficheiro de origem, e não por um destino:
lingo push "app/src/main/res/values/strings.xml"
lingo push "MyApp/Localizable.xcstrings"Para obter as traduções mais recentes noutro local (por exemplo, noutra máquina), execute lingo pull. Para verificar se as traduções estão atualizadas sem escrever alterações — útil como bloqueio de deploy — execute lingo check.
Plurais e Convenções por Plataforma#
Cada plataforma mobile trata as formas de plural de forma diferente — o iOS usa .stringsdict ou regras de String Catalog, o Android usa elementos XML <plurals> e o Flutter usa ICU MessageFormat em ficheiros ARB. A CLI preserva a estrutura nativa de plurais de cada plataforma durante a tradução e gera as categorias de plural corretas para cada idioma de destino.
Notas para tradutores
As strings mobile são frequentemente curtas e dependem do contexto. Use notas para tradutores em ficheiros .xcstrings do Xcode para dar ao motor de localização contexto sobre onde uma string aparece — "rótulo de botão no fluxo de checkout" traduz-se de forma diferente de "item do menu de navegação".
Automatizar em CI#
A forma recomendada de manter as traduções atualizadas é a GitHub App da Lingo.dev. Corre do lado do servidor, lê os seus .lingo/config.json e engineId com commit e abre automaticamente atualizações de tradução — sem gestão de runner, secret ou lockfile do seu lado. Se preferir executar as traduções no seu próprio pipeline, execute lingo push no runner de CI e faça commit dos resultados.
