Padrões avançados

Padrões avançados de localização em CI/CD — escolha de workflow, verificação da completude das traduções e resolução de conflitos de merge.

Escolher um workflow#

Há quatro padrões de workflow que cobrem a maioria das configurações de equipa. Cada um implica diferentes compromissos ao nível da automação, do esforço de revisão e da higiene dos branches.

Workflow	Ideal para	Compromisso
Commit na main	Equipas pequenas, atualizações sem fricção	Sem etapa de revisão para as traduções
PR a partir da main	Equipas que querem rever as traduções	Requer aprovação manual do PR
Commit no branch de funcionalidade	Branches de funcionalidade de longa duração	Commits de tradução no histórico do branch
PR a partir do branch de funcionalidade	Controlo máximo por funcionalidade	Vários PRs por funcionalidade para gerir

No GitHub, a Lingo.dev GitHub App trata da maioria destes padrões do lado do servidor — reage a pushes e PRs, faz commit das traduções de volta ao repositório e não requer runner nem secret. Recorra aos padrões de CLI abaixo quando executar a localização no seu próprio pipeline.

Se tiver dúvidas, comece por "Commit na main". É o workflow mais simples e evita por completo os conflitos de merge, já que não existe divergência entre branches.

Verificar se as traduções estão completas#

O comando lingo check verifica se todo o conteúdo está traduzido sem gerar novas traduções. Termina com um código de saída diferente de zero se houver conteúdo em falta:

bash

lingo check

Use isto como gate de deployment para evitar publicar conteúdo por traduzir. Instale a CLI com npm install -g @lingo.dev/cli (Node 22+) e autentique o runner com a variável de ambiente LINGO_API_KEY.

yaml

name: Check translations
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm install -g @lingo.dev/cli
      - run: lingo check
        env:
          LINGO_API_KEY: ${{ secrets.LINGO_API_KEY }}

Resolver conflitos de merge#

Os conflitos de merge surgem quando o ficheiro .lingo/lock.json diverge entre branches — normalmente quando as traduções são atualizadas de forma independente em branches diferentes.

Prevenção#

Fazer commit das traduções diretamente em main (em vez de usar branches de funcionalidade para as traduções) elimina por completo os conflitos no lockfile.

Resolução por merge#

Iniciar o merge

bash

git merge <branch-name>

Eliminar o lockfile em conflito

bash

rm .lingo/lock.json

Concluir o merge

bash

git add .
git merge --continue

Regenerar o lockfile

bash

lingo push

Ao executar lingo push, o .lingo/lock.json é recriado a partir do estado atual dos seus ficheiros de origem, como parte da sincronização normal.

Resolução por rebase#

A mesma abordagem também funciona com rebase — elimine .lingo/lock.json em cada etapa de conflito, continue o rebase e, no final, execute lingo push para regenerar o lockfile:

bash

git rebase <branch-name>
# On each conflict: rm .lingo/lock.json && git add . && git rebase --continue
lingo push

Próximos passos#

GitHub App

Automatize a localização no GitHub sem runner

lingo push

Sincronize o conteúdo de origem e as traduções

Como funciona

O pipeline de localização em CI/CD

Configuração

Configure o CI/CD do seu projeto

Padrões avançados de localização em CI/CD — escolha de workflow, verificação da completude das traduções e resolução de conflitos de merge.

Escolher um workflow#

Workflow	Ideal para	Compromisso
Commit na main	Equipas pequenas, atualizações sem fricção	Sem etapa de revisão para as traduções
PR a partir da main	Equipas que querem rever as traduções	Requer aprovação manual do PR
Commit no branch de funcionalidade	Branches de funcionalidade de longa duração	Commits de tradução no histórico do branch
PR a partir do branch de funcionalidade	Controlo máximo por funcionalidade	Vários PRs por funcionalidade para gerir

Se tiver dúvidas, comece por "Commit na main". É o workflow mais simples e evita por completo os conflitos de merge, já que não existe divergência entre branches.

Verificar se as traduções estão completas#

O comando lingo check verifica se todo o conteúdo está traduzido sem gerar novas traduções. Termina com um código de saída diferente de zero se houver conteúdo em falta:

bash

lingo check

yaml

name: Check translations
on: [push, pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm install -g @lingo.dev/cli
      - run: lingo check
        env:
          LINGO_API_KEY: ${{ secrets.LINGO_API_KEY }}

Resolver conflitos de merge#

Os conflitos de merge surgem quando o ficheiro .lingo/lock.json diverge entre branches — normalmente quando as traduções são atualizadas de forma independente em branches diferentes.

Prevenção#

Fazer commit das traduções diretamente em main (em vez de usar branches de funcionalidade para as traduções) elimina por completo os conflitos no lockfile.

Resolução por merge#

Iniciar o merge

bash

git merge <branch-name>

Eliminar o lockfile em conflito

bash

rm .lingo/lock.json

Concluir o merge

bash

git add .
git merge --continue

Regenerar o lockfile

bash

lingo push

Ao executar lingo push, o .lingo/lock.json é recriado a partir do estado atual dos seus ficheiros de origem, como parte da sincronização normal.

Resolução por rebase#

A mesma abordagem também funciona com rebase — elimine .lingo/lock.json em cada etapa de conflito, continue o rebase e, no final, execute lingo push para regenerar o lockfile:

bash

git rebase <branch-name>
# On each conflict: rm .lingo/lock.json && git add . && git rebase --continue
lingo push

Próximos passos#

GitHub App

Automatize a localização no GitHub sem runner

lingo push

Sincronize o conteúdo de origem e as traduções

Como funciona

O pipeline de localização em CI/CD

Configuração

Configure o CI/CD do seu projeto