|
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

Workflows de localização em CI/CD

A CLI do Lingo.dev roda em qualquer ambiente de CI/CD com Node.js. Adicione-a como uma etapa do pipeline para traduzir a cada push — o lockfile garante que só as strings alteradas sejam processadas, mantendo as traduções rápidas e com ótimo custo-benefício à medida que seu projeto cresce.

Usa GitHub? Você tem duas opções

O GitHub App é a forma mais simples de rodar no GitHub — instale uma vez e ele reage automaticamente a pushes e pull requests. Sem runner, sem secret de chave de API e sem lockfile; você configura o repositório com .lingo/config.json e um engineId.

A GitHub Action e as outras integrações abaixo executam a CLI dentro do seu próprio pipeline usando i18n.json, um i18n.lock lockfile e um secret LINGODOTDEV_API_KEY. Siga por esse caminho se você quiser que a tradução rode junto com outras etapas de CI, ou se não usa GitHub.

O restante deste guia aborda a GitHub Action e a CLI.

Como funciona#

O pipeline de CI/CD executa a CLI como uma etapa depois do checkout. A CLI lê sua configuração i18n.json, compara os arquivos de origem com o lockfile para identificar mudanças, traduz o delta por meio de um engine de localização configurado e grava os resultados nos arquivos do idioma de destino. Em seguida, o pipeline faz commit dos arquivos traduzidos ou abre um pull request — dependendo da sua preferência de workflow.

Escolha seu workflow#

Quatro padrões de workflow atendem à maioria das estruturas de equipe. Comece pelo mais simples e evolua conforme sua equipe cresce.

WorkflowComo funcionaIdeal paraPonto de atenção
Commit na mainTraduz e faz commit direto na mainEquipes pequenas, zero atritoSem etapa de revisão para as traduções
PR a partir da mainTraduz e abre um PR para revisãoEquipes que revisam traduçõesExige aprovação manual do PR
Commit na branch de featureTraduz a cada push na branch de featureBranches de feature de longa duraçãoCommits de tradução entram no histórico da branch
PR a partir da branch de featureTraduz e abre um PR a partir da branch de featureMáximo controle por featureVários PRs por feature

Recomendação inicial

Commit na main funciona bem para a maioria das equipes. As traduções são entregues a cada push, o lockfile garante consistência, e o glossário e as regras de voz da marca do engine de localização ajudam a manter a qualidade. Migre para workflows baseados em PR quando precisar de revisão humana das traduções.

Configuração rápida#

Armazene sua chave de API do Lingo.dev como um secret de CI/CD e depois adicione a etapa de tradução ao pipeline.

O Lingo.dev oferece uma GitHub Action oficial que cuida do checkout, da tradução e da criação de commit/PR.

Prefere não gerenciar um arquivo de workflow, um secret de chave de API ou um lockfile? O GitHub App faz localização contínua no GitHub sem nada disso — basta instalar uma vez e configurar .lingo/config.json.

Commit na main:

yaml
name: Translate
on:
  push:
    branches: [main]
permissions:
  contents: write
jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: lingodotdev/lingo.dev@main
        with:
          api-key: ${{ secrets.LINGODOTDEV_API_KEY }}

PR a partir da main — adicione pull-request: true e um GH_TOKEN:

yaml
name: Translate
on:
  push:
    branches: [main]
permissions:
  contents: write
  pull-requests: write
jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: lingodotdev/lingo.dev@main
        with:
          api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
          pull-request: true
        env:
          GH_TOKEN: ${{ github.token }}

Consulte o guia completo de integração com GitHub Actions para workflows com branch de feature, mensagens de commit personalizadas, suporte a monorepo e assinatura GPG.

Verificação de tradução#

A flag --frozen e o lockfile fazem parte da GitHub Action e da CLI. O GitHub App rastreia o estado da tradução no servidor e não tem lockfile nem um equivalente a --frozen.

Use a flag --frozen como gate de deploy para garantir que nenhum conteúdo sem tradução chegue à produção. A CLI retorna um status diferente de zero se alguma string precisar de tradução.

bash
npx lingo.dev@latest run --frozen

Adicione isto como uma etapa separada do pipeline, executada antes do deploy:

yaml
- name: Verify translations
  run: npx lingo.dev@latest run --frozen

Workflows para monorepo#

Para monorepos com vários pacotes, cada um com seus próprios arquivos de tradução, use a opção working-directory para segmentar pacotes específicos:

yaml
- uses: lingodotdev/lingo.dev@main
  with:
    api-key: ${{ secrets.LINGODOTDEV_API_KEY }}
    working-directory: apps/web

Conflitos de merge#

Isso se aplica à GitHub Action e à CLI. O GitHub App não usa lockfile, então não há conflitos de i18n.lock para resolver.

O lockfile (i18n.lock) pode entrar em conflito quando branches com alterações de tradução são mescladas. A resolução é simples — exclua o lockfile em conflito, conclua o merge e gere-o novamente:

bash
git merge feature-branch
rm i18n.lock
git add .
git merge --continue
npx lingo.dev@latest lockfile --force

O comando lockfile --force reconstrói o lockfile com base no estado atual dos seus arquivos de origem sem disparar novas traduções. Consulte o guia de padrões avançados de integração para estratégias de resolução baseadas em rebase e prevenção de conflitos.

Próximos passos#

GitHub App
Localização contínua gerenciada no GitHub — sem runner, secret ou lockfile
GitHub Actions
Configuração completa do GitHub Actions com assinatura GPG e configuração personalizada
GitLab CI
Configuração completa do GitLab CI/CD com tokens de acesso e merge requests
Bitbucket Pipelines
Configuração completa do Bitbucket Pipelines com pipes e pull requests
Padrões avançados
Seleção de workflow, resolução de conflitos e gates de deploy

Esta página foi útil?

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