|
Documentação
Marcar uma demonstraçãoPlataforma
PlataformaMCPCLIAPIWorkflows
Guias
Changelog

Localização

  • Visão geral
  • API de Tradução
  • Localização de aplicações web
  • Localização de Apps Mobile
  • iOS com String Catalogs
  • Android com strings.xml
  • Localização de emails
  • Conteúdo Estático (ex.: .md, .json)
  • Next.js com Markdoc
  • Rails com i18n

Workflows

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

Workflows de localização em CI/CD

A CLI do Lingo.dev corre em qualquer ambiente CI/CD com Node.js. Adicione-a como passo do pipeline para traduzir a cada push — o lockfile garante que só as strings alteradas são processadas, para manter as traduções rápidas e os custos sob controlo à medida que o projeto cresce.

No GitHub? Tem duas formas de o executar

A GitHub App é a opção mais simples no GitHub — instala uma vez e reage automaticamente a pushes e pull requests. Sem runner, sem segredo de chave de API e sem lockfile; configura o repositório com .lingo/config.json e um engineId.

A GitHub Action e as restantes integrações abaixo executam a CLI dentro do seu próprio pipeline, com i18n.json, um lockfile i18n.lock e um segredo LINGODOTDEV_API_KEY. Siga este caminho se quiser executar a tradução em conjunto com outros passos de CI, ou se não estiver no GitHub.

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

Como funciona#

O pipeline de CI/CD executa a CLI como passo após o checkout. A CLI lê a configuração i18n.json, compara os ficheiros de origem com o lockfile para identificar alterações, traduz o delta através de um motor de localização configurado e escreve os resultados nos ficheiros do idioma de destino. Depois, o pipeline faz commit dos ficheiros traduzidos ou abre um pull request — consoante a sua preferência de workflow.

Escolha o workflow certo#

Estes quatro padrões de workflow cobrem a maioria das estruturas de equipa. Comece pelo mais simples e evolua à medida que a equipa cresce.

WorkflowComo funcionaIdeal paraTrade-off
Commit para mainTraduz e faz commit diretamente para mainEquipas pequenas, zero fricçãoSem etapa de revisão das traduções
PR a partir de mainTraduz e abre um PR para revisãoEquipas que fazem revisão das traduçõesRequer aprovação manual do PR
Commit para branch de funcionalidadeTraduz a cada push para a branch de funcionalidadeBranches de funcionalidade de longa duraçãoCommits de tradução no histórico da branch
PR a partir de branch de funcionalidadeTraduz e abre PR a partir da branch de funcionalidadeMáximo controlo por funcionalidadeVários PR por funcionalidade

Recomendação para começar

Fazer commit para main resulta bem para a maioria das equipas. As traduções seguem com cada push, o lockfile garante consistência e o glossário e as regras de voz da marca do motor de localização asseguram a qualidade. Passe para workflows baseados em PR quando precisar de revisão humana das traduções.

Configuração rápida#

Guarde a sua chave de API do Lingo.dev como segredo de CI/CD e, depois, adicione a etapa de tradução ao pipeline.

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

Prefere não gerir um ficheiro de workflow, um segredo de chave de API ou um lockfile? A GitHub App faz localização contínua no GitHub sem nada disso — instale uma vez e configure .lingo/config.json.

Commit para 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 de 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 de branches de funcionalidade, mensagens de commit personalizadas, suporte para monorepo e assinatura GPG.

Verificação de traduções#

A flag --frozen e o lockfile fazem parte da GitHub Action e da CLI. A GitHub App acompanha o estado da tradução do lado do servidor e não tem lockfile nem equivalente a --frozen.

Use a flag --frozen como gate de deployment para garantir que nenhum conteúdo por traduzir chega à produção. A CLI termina com um estado 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, 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 os seus próprios ficheiros de tradução, use a opção working-directory para apontar a pacotes específicos:

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

Conflitos de merge#

Isto aplica-se à GitHub Action e à CLI. A GitHub App não usa lockfile, por isso não há conflitos de i18n.lock para resolver.

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

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 a partir do estado atual dos seus ficheiros de origem sem acionar 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 gerida no GitHub — sem runner, segredo ou lockfile
GitHub Actions
Configuração completa de GitHub Actions com assinatura GPG e configuração personalizada
GitLab CI
Configuração completa de GitLab CI/CD com tokens de acesso e merge requests
Bitbucket Pipelines
Configuração completa de Bitbucket Pipelines com pipes e pull requests
Padrões avançados
Seleção de workflow, resolução de conflitos e gates de deployment

Esta página foi útil?

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