|
Documentação
Agende uma demoPlataforma
PlataformaMCPCLIAPIWorkflows
Guias
Changelog

Localização

  • Visão geral
  • API de Tradução
  • Localização de apps web
  • Localização de aplicativos mobile
  • iOS com String Catalogs
  • Android com strings.xml
  • Localização de e-mails
  • Conteúdo estático (ex.: .md, .json)
  • Next.js com Markdoc
  • Rails com i18n

Workflows

  • Configuração do engine com MCP
  • Triagem no Jira
  • CI/CD

Localização de aplicativos mobile

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#

PlataformaFormato nativoCaminho típico do arquivo-fonte
iOS (Xcode).stringsen.lproj/Localizable.strings
iOS (Xcode).stringsdicten.lproj/Localizable.stringsdict
iOS (Xcode).xcstringsLocalizable.xcstrings
Androidstrings.xmlapp/src/main/res/values/strings.xml
Flutter.arblib/l10n/app_en.arb
React Native.jsonsrc/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:

bash
npm install -g @lingo.dev/cli
lingo login

lingo 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.

json
{
  "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.

json
{
  "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:

bash
lingo push

O 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:

bash
lingo push --backfill-missing

Direcione 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:

bash
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.

Guias detalhados por plataforma#

iOS com String Catalogs
Guia completo de .xcstrings do Xcode com o CLI e o GitHub App
Android com strings.xml
Guia completo de recursos XML do Android com o CLI e o GitHub App
Projetos de exemplo
Repositórios prontos para uso de iOS, Android e Flutter com a configuração e as traduções já commitadas

Próximos passos#

Formatos compatíveis
Referência completa de todos os formatos de arquivo mobile
Glossários
Proteja nomes de marca e termos técnicos contra tradução
GitHub App
Automatize traduções mobile a cada push
Bloqueio de chaves
Copie valores específicos sem traduzi-los

Esta página foi útil?

Max PrilutskiyMax Prilutskiy·Atualizado há 8 dias·6 min de leitura