Publicado24 de abril de 2026

Atualizado7 de setembro de 2026

Por que as traduções do seu app do Lovable quebram a cada novo lançamento

Principais pontos

Todo prompt do Lovable que altera sua UI pode criar novas strings sem tradução nos seus catálogos PO.
O problema não é a configuração multilíngue inicial — é manter as traduções sincronizadas a cada novo lançamento.
Ferramentas de tradução em tempo de execução resolvem o sintoma, mas trazem um flash de conteúdo não traduzido e prejudicam o Core Web Vitals.
A solução correta é uma infraestrutura de i18n conectada ao seu ciclo de push no Git, não uma extração pontual.
Você pode continuar construindo no Lovable — o globalize.now cuida da sincronização, você cuida do produto.

O que realmente acontece quando você torna seu produto multilíngue no Lovable

Você pede ao Lovable para adicionar uma nova seção de preços. O Lovable gera o componente, integra tudo e publica. Sua UI em inglês é atualizada. Seus catálogos messages.po continuam apontando para o que existia antes. Usuários de língua francesa veem o texto antigo. Usuários de língua alemã veem inglês. Ninguém percebe até que um usuário real reporte o problema.

Isso não é um bug do Lovable. É uma incompatibilidade estrutural. O Lovable é otimizado para lançar UI rapidamente. O i18n exige rastrear cada string voltada ao usuário em cada catálogo de idioma, a cada alteração. Esses dois objetivos estão em tensão direta um com o outro.

O problema da extração é contínuo, não pontual. Cada prompt executado no Lovable pode criar novas strings. Cada iteração altera conteúdo existente. Não existe um ponto natural em que você possa dizer "a extração está concluída".

Por que as soluções óbvias não resolvem

Uma extração pontual resolve o problema?

Não. Você pode rodar um processo de extração de strings depois da build inicial do Lovable e criar catálogos PO limpos. Isso funciona até o próximo prompt. Depois disso, você passa a comparar diffs manualmente entre dezenas de componentes e dezenas de catálogos. Uma única string esquecida no seu catálogo messages.po em espanhol e seus usuários hispanofalantes recebem texto em inglês no meio de uma página traduzida — o que se conhece como UI com idiomas misturados, uma das experiências que mais destroem a confiança do usuário.

Ferramentas de tradução em tempo de execução são boas o suficiente?

Tradutores em tempo de execução, como Weglot ou widgets de tradução injetados via JavaScript, resolvem um problema diferente. Eles traduzem o conteúdo depois que a página carrega, o que significa que os usuários veem o idioma original por uma fração de segundo antes que o conteúdo traduzido apareça. Além da experiência de uso ruim, isso gera um Cumulative Layout Shift mensurável — um sinal do Core Web Vitals que o Google usa para ranquear páginas. Você está trocando um problema de manutenção invisível por um problema de performance visível.

E se você simplesmente pedir ao Lovable para atualizar os arquivos de idioma?

O Lovable pode escrever nos catálogos PO se você pedir. O problema: você precisa se lembrar de pedir, para cada string, em cada prompt, em cada idioma. A carga cognitiva aumenta a cada idioma adicionado. Multiplique por quatro idiomas e você transformou cada prompt de UI em um exercício de coordenação de quatro etapas. É exatamente esse tipo de atrito que mata a velocidade que tornava o Lovable valioso.

Como o ciclo de i18n do Lovable realmente desanda

O padrão é consistente o suficiente para ter um formato reconhecível:

Configuração inicial — Você adiciona suporte multilíngue. Funciona. Está tudo traduzido. Você se sente satisfeito.
Primeiros lançamentos — Você se lembra de atualizar os catálogos PO manualmente. É chato, mas dá para gerenciar.
Fase de velocidade — Você começa a lançar mais rápido. Os catálogos PO começam a ficar atrasados. Você promete a si mesmo que vai colocar em dia depois.
Produção com idiomas misturados — Usuários em mercados não anglófonos começam a ver trechos em inglês. Chegam chamados de suporte. Você gasta um ciclo inteiro de lançamento só caçando strings.
Taxa de retrabalho — Toda nova funcionalidade agora carrega um custo oculto de i18n que não existia na versão só em inglês. Sua velocidade de lançamento cai.

A taxa de retrabalho é a parte que ninguém menciona quando escreve guias do tipo "veja como tornar seu app multilíngue no Lovable". Os guias mostram a configuração inicial. Não mostram o que acontece no lançamento número 12.

A solução: i18n conectado ao seu ciclo de push no Git

A resposta arquiteturalmente correta é eliminar as etapas manuais por completo. Se as traduções são atualizadas automaticamente a cada push, o problema de manutenção desaparece. Você não pode esquecer de rodar a extração se ela roda sozinha.

O fluxo de trabalho funciona assim:

Conecte seu projeto Lovable ao GitHub. Use o menu + no campo de chat, depois GitHub, depois Connect project.
Adicione a skill lovable-i18n ao seu workspace. Abra Skills no seu workspace do Lovable, depois Add, depois Import from GitHub, e cole https://github.com/globalize-now/globalize-skills/tree/main/skills/lovable-i18n. Confirme. Uma vez por workspace (é preciso ser owner ou admin do workspace).
Peça ao Lovable para configurar tudo. Cole no chat do Lovable: Set up i18n for my project using the lovable-i18n skill. O Lovable detecta sua stack (Vite SPA ou TanStack Start) e faz uma única pergunta (idioma de origem, idiomas de destino, se o locale vai na URL ou não, adicionar a GitHub Action); responda go para usar os padrões. Ele instala o Lingui, cria os catálogos PO em src/locales/{locale}/messages.po, envolve as strings em macros <Trans> e adiciona um seletor de idioma.
Revise e faça o merge. O Lovable sincroniza com o GitHub; revise o diff e faça o merge para sua branch padrão.
Conecte o repositório ao globalize.now. Faça login, conecte o repositório, autorize o app do GitHub, selecione seu repositório Lovable e a branch padrão, escolha os idiomas (mais de 50, incluindo RTL).
Continue construindo no Lovable. Cada push aciona o globalize.now para abrir um PR de tradução com os catálogos PO atualizados; faça o merge, e o app é publicado já traduzido.

A propriedade essencial: as etapas de conexão e sincronização não exigem nada de você depois da configuração inicial. Você não roda comando nenhum. Não precisa checar um painel. Não precisa aprovar uma fila de tradução. Novas strings nos seus componentes gerados pelo Lovable são detectadas no push, traduzidas e enviadas de volta via PR antes mesmo de você fazer o merge da branch. O passo a passo completo está na página de integração com o Lovable.

O que isso significa para o seu fluxo de trabalho no Lovable

Você não precisa parar de usar o Lovable. A arquitetura foi pensada justamente assumindo que sua UI vai continuar mudando — esse é todo o ponto. O Lovable gera a UI e executa a skill lovable-i18n; o globalize.now cuida da sincronização.

O Lovable gera componentes e aplica a skill quando você precisa de i18n. O globalize.now monitora o resultado a cada push. Seus usuários sempre veem uma UI completa e traduzida, independentemente da velocidade com que você lança novidades.

A página para vibe coders do globalize.now traz mais detalhes sobre como a configuração funciona especificamente para apps construídos com IA. Se você já está rodando um app Next.js ou React construído no Lovable, a página para desenvolvedores cobre o caminho técnico de integração.

Para equipes que já gerenciam vários projetos Lovable, o preço por workspace do globalize.now significa que você não paga por idioma nem por extração de strings — o custo de sincronização se mantém estável conforme seu app cresce.

O peso da manutenção é real e só aumenta. Adicione a skill lovable-i18n no Lovable (abra Skills no seu workspace, depois Add, depois Import from GitHub). Veja o guia de integração com o Lovable ou o globalize.now.

O globalize.now transforma textos fixos do app em arquivos de locale prontos para tradução e os mantém atualizados a cada novo lançamento.

Experimente o globalize.now grátis

Isso foi útil?

Perguntas frequentes

Por que as traduções do meu app do Lovable quebram a cada atualização?

Todo prompt do Lovable que altera sua interface gera novas strings fixas. Seus catálogos PO não são atualizados automaticamente, então cada lançamento amplia a diferença entre a interface em inglês e as versões traduzidas. A solução é integrar o i18n ao seu ciclo de push no Git, para que os catálogos PO permaneçam sincronizados sem etapas manuais de extração.

Posso usar o Lovable e ainda ter um i18n adequado?

Sim. Conecte seu projeto do Lovable ao GitHub, adicione a skill lovable-i18n no Lovable (abra Skills no seu workspace, depois clique em Add e em Import from GitHub: globalize-now/lovable-i18n) e envie o prompt: Configure o i18n do meu projeto usando a skill lovable-i18n. Conecte o repositório ao globalize.now e continue desenvolvendo no Lovable normalmente. A cada push é gerado um diff, novas strings são traduzidas, e um PR é aberto com os catálogos PO atualizados.

Qual é o problema de ferramentas de tradução em tempo de execução, como o Weglot, em apps do Lovable?

Tradutores em tempo de execução injetam JavaScript que traduz o conteúdo depois que a página já carregou. Isso cria um flash de conteúdo não traduzido a cada carregamento de página: os usuários veem o texto em inglês por uma fração de segundo antes da tradução entrar em ação. Essa instabilidade visual prejudica as métricas do Core Web Vitals e passa a impressão de uma experiência quebrada para os usuários.

Preciso parar de usar o Lovable para adicionar suporte a múltiplos idiomas?

Não. Conecte seu projeto do Lovable ao GitHub, adicione a skill lovable-i18n uma única vez no seu workspace do Lovable (abra Skills, depois clique em Add e em Import from GitHub: globalize-now/lovable-i18n), execute o prompt de configuração, conecte o repositório ao globalize.now e continue desenvolvendo no Lovable normalmente. O globalize.now cuida da sincronização das traduções a cada push. O Lovable cuida da sua interface e da configuração de i18n. Os dois não entram em conflito.

Qual é a diferença entre o globalize.now e manter os arquivos de idioma manualmente?

Manter os catálogos PO manualmente exige que você identifique novas strings a cada lançamento, atualize cada catálogo à mão e confira se nada ficou dessincronizado. O globalize.now automatiza o diff a cada push no Git, traduz as novas strings e abre um PR com os arquivos atualizados. Sem fila de revisão. Sem exportações manuais. Sem strings esquecidas.

← Voltar ao blog