Pull requests de tradução quebram a sincronização do Lovable com o GitHub?

Não, um pull request de tradução não quebra a sincronização do Lovable com o GitHub, desde que seja mergeado na única branch que o Lovable está sincronizando. O Lovable edita uma branch por vez e traz de volta para o projeto os commits mergeados, então um pull request de tradução é só mais um commit chegando nessa branch. A globalize.now é uma infraestrutura de localização com IA que entrega as traduções como pull request no seu repositório, o que significa que os dois sistemas se encontram em um merge normal do Git e em nenhum outro ponto. Os casos que dão errado são específicos e documentados, e este post passa por eles.

Como a sincronização do Lovable com o GitHub realmente funciona?

Ela é bidirecional e de uma única branch. A documentação do Lovable diz que ele edita e sincroniza uma branch por vez, por padrão a branch padrão do repositório, geralmente main. As alterações que você faz no Lovable são commitadas nessa branch. Os commits enviados para essa branch no GitHub são puxados de volta para o Lovable.

Dois detalhes importam para qualquer coisa que escreva no seu repositório de fora do Lovable.

O pull depende de uma notificação. O Lovable recebe uma notificação de push do GitHub e atualiza o projeto. Segundo a mesma documentação, se essa notificação nunca chega, os commits daquele push não aparecem no Lovable. A correção documentada é enviar outro commit para disparar uma nova notificação. Se você mergeou um pull request de tradução e o editor continua mostrando inglês, esta é a primeira coisa a verificar.

Você pode trocar a branch sincronizada. As configurações de GitHub do projeto incluem um seletor de branch. Uma branch criada ali parte da branch que estiver ativa no momento, não automaticamente da main. Depois que você troca, o Lovable passa a editar e sincronizar essa branch. Tudo o que for mergeado na main a partir daí fica invisível para o editor até ser mergeado na branch em que o Lovable está.

Se for guardar uma única frase desta seção: o pull request de tradução precisa cair na branch que o seletor mostra.

O que acontece quando o GitHub rejeita um push do Lovable?

O Lovable guarda a alteração em uma branch chamada lovable-sync em vez de perdê-la. Segundo a documentação do Lovable, isso acontece quando o GitHub rejeita um push por causa de conflitos ou de regras de proteção de branch, e você então mergeia a lovable-sync na sua branch protegida pelo seu processo normal de revisão.

Uma rede de segurança relacionada: se a branch que o Lovable está sincronizando for excluída no GitHub, o Lovable muda o projeto para uma nova branch chamada lovable-fallback. Já excluir o próprio repositório quebra a conexão e interrompe a sincronização, enquanto renomeá-lo não causa isso.

Nada disso é específico de traduções. É assim que se espera que um segundo escritor se comporte ao redor do Lovable, e um pull request de tradução é um escritor educado: chega como um pull request revisável e nunca faz push direto em uma branch protegida.

Onde o pull request de tradução se encaixa?

Entre os commits do Lovable e o seu botão de merge. O fluxo fica assim em um projeto Lovable que já tem a skill lovable-i18n instalada, com as regras de instrução no knowledge do Lovable mantendo as novas strings envolvidas.

1. O Lovable escreve uma feature e envolve as novas strings em macros do Lingui. Ele faz commit na branch sincronizada.
2. Um workflow do GitHub extrai as strings envolvidas para os catálogos PO em src/locales/ e commita a sincronização de volta. O Lovable não tem terminal, então a extração precisa rodar no GitHub, e não no editor.
3. A conversão acontece uma única vez e dentro do app: você conecta o repositório e a globalize.now converte a base de código uma vez, entregando o catálogo como pull request. Depois disso, os jobs de push traduzem as novas unidades do catálogo e entregam os catálogos traduzidos também como pull requests.
4. Você mergeia o pull request na branch sincronizada. O Lovable puxa o commit de merge e o app passa a renderizar o novo idioma.

Repare no que não existe: nenhuma etapa de importação no Lovable, nenhuma exportação de um painel web e nenhum widget carregando traduções em runtime. Os arquivos traduzidos são arquivos comuns no seu repositório, que é o argumento por trás de localizar um app Lovable sem painel, e os passos exatos de conexão estão na página de integração com o Lovable.

O Lovable e um pull request de tradução podem entrar em conflito?

Sim, no sentido comum do Git, e é raro quando você mantém os pull requests de curta duração. Um conflito exige que os dois lados alterem as mesmas linhas do mesmo arquivo entre a criação da branch e o merge.

A única sobreposição realista é o catálogo PO. Quando o Lovable adiciona uma string, ele acrescenta uma nova mensagem a cada src/locales/*/messages.po com a tradução vazia, e o app recorre ao texto de origem. O pull request de tradução preenche o texto traduzido das mensagens que já estavam no catálogo quando ele foi aberto. Se o Lovable acrescenta novas mensagens no fim de um arquivo enquanto o pull request edita entradas anteriores do mesmo arquivo, o Git mergeia os dois sem reclamar. Se os dois mexem na mesma entrada, aparece um marcador de conflito.

Três hábitos mantêm essa janela pequena.

Mergeie os pull requests de tradução no mesmo dia em que forem abertos. Um pull request parado por uma semana enquanto o Lovable entrega dez features é a única forma de isso virar bagunça.

Nunca edite à mão os comentários de referência das entradas do catálogo. O workflow de extração regenera as linhas #. e #:, então, ao resolver um conflito, mantenha a entrada com o texto traduzido e deixe a próxima execução da extração reescrever os comentários.

Atualize uma branch defasada antes de mergear. Se a branch do pull request ficou para trás, atualize-a primeiro:

git fetch origin
git checkout <translation-branch>
git merge origin/<synced-branch>

Resolva o que o Git apontar, faça push e mergeie. Como os catálogos são texto e cada mensagem é um bloco, o conflito que você resolve quase sempre é de uma entrada, não do arquivo inteiro.

O que a proteção de branch muda?

Ela adiciona revisão, e revisão já é o modelo. Uma tradução entregue como pull request passa por todas as verificações obrigatórias e aprovações que a sua branch exigir. Os pushes do próprio Lovable que uma branch protegida rejeita chegam na lovable-sync, que você mergeia pela mesma revisão. Os dois caminhos são separados e nenhum bloqueia o outro.

Se você protege a branch padrão e também deixa o Lovable editá-la, espere ter que mergear a lovable-sync de tempos em tempos; esse é o comportamento documentado do Lovable, não um problema de tradução. Se isso incomoda, as opções são flexibilizar a regra de proteção para o autor do Lovable ou trocar a branch sincronizada por uma dedicada nas configurações do projeto. Em ambos os casos, aponte o pull request de tradução para a branch que o Lovable estiver sincronizando.

Por que essa dúvida não existia com os widgets de tradução em runtime?

Porque eles nunca escreviam no seu repositório. O Lovalingo, que encerrou as atividades em 31 de agosto de 2026, traduzia a página renderizada no navegador, então não havia arquivos de locale no repositório nem pull requests para mergear. Quem migrou para catálogos commitados pelo guia de migração está encontrando a sincronização do Lovable com o GitHub como um sistema de dois escritores pela primeira vez.

Essa é a troca, e é a certa: o texto traduzido é seu, versionado e indexável, em vez de alugado na hora da renderização. Em contrapartida, exige que você saiba em qual branch o Lovable está. Para a outra metade de manter um app Lovable traduzido, quando os catálogos ficam atrás do código, veja por que as traduções quebram a cada deploy. Se o seu app também guarda conteúdo em um banco de dados, essa camada fica fora do repositório; localizar conteúdo de banco de dados em um app Lovable cobre esse caso.

Mantenha os dois escritores na mesma branch

Confira o seletor de branch nas configurações de GitHub do projeto, mergeie os pull requests de tradução nessa branch e trate a lovable-sync como uma tarefa pendente, não como um erro. Se você está construindo no Lovable e prefere que o trabalho de tradução seja resolvido em vez de mantido por você, a página para vibe coders traz a visão geral e os preços ficam em uma página própria.