Tornar um app Lovable multilíngue da forma certa significa versionar catálogos de tradução reais no seu repositório e mantê-los sincronizados automaticamente, e não simplesmente encaixar um widget de tradução por cima da interface. O globalize.now é uma infraestrutura de localização baseada em IA que extrai suas strings fixas no código, monta os catálogos PO e os atualiza a cada push no Git. As ferramentas de atalho te dão uma demo multilíngue em minutos. Mas também deixam traduções que ficam desatualizadas, um layout que se desloca durante o carregamento e páginas que os mecanismos de busca têm dificuldade de ler. Aqui está a configuração que sobrevive até o release doze.

O que realmente significa "multilíngue da forma certa" para um app Lovable?

Significa que suas traduções vivem no seu código como catálogos versionados, são servidas já no markup inicial e são atualizadas automaticamente conforme o app evolui.

Existem três camadas em qualquer app multilíngue de verdade. Uma biblioteca de runtime de i18n serve a string correta para o locale ativo. Os catálogos de tradução guardam as traduções em si. E algo precisa manter esses catálogos atualizados conforme a interface evolui. A maioria dos guias sobre Lovable cobre a primeira camada e ignora a terceira, que é justamente a que quebra.

O Lovable foi feito para mudar sua interface rapidamente. Cada prompt pode adicionar, renomear ou reestruturar texto voltado ao usuário. Então a questão do multilíngue não é "como eu traduzo o app uma vez". É "como eu mantenho cada idioma completo enquanto continuo gerando prompts". Erre nisso e você vai lançar uma interface com idiomas misturados, uma das formas mais rápidas de perder a confiança de um mercado que não fala inglês.

Por que os widgets de tradução não são suficientes para apps Lovable?

Eles traduzem o conteúdo depois que a página já carregou, trocando um problema invisível de manutenção por um problema visível de performance e SEO.

Tradutores em tempo de execução como Weglot, Lovalingo e widgets de tradução injetados são geralmente a primeira resposta mais comum para o Lovable, porque se instalam em minutos e não exigem arquivos de locale. O custo aparece depois. O usuário vê brevemente o idioma original antes da tradução entrar em cena, o que é um flash de conteúdo não traduzido. Essa troca desloca o layout, gerando Cumulative Layout Shift, métrica que o Google mede como parte do Core Web Vitals.

O problema mais profundo é a capacidade de ser encontrado. Se o texto traduzido só existe depois que o JavaScript do lado do cliente é executado, você geralmente tem uma única página real mais uma tradução feita no navegador. URLs por idioma são fracas ou inexistentes, então suas páginas em espanhol e alemão não rankeiam como um site devidamente localizado. Um widget pode ser a escolha certa para uma ferramenta interna ou uma demo descartável. Para um app que você quer que seja encontrado em outros mercados, é a base errada.

Uma configuração pontual de i18n mantém um app Lovable traduzido?

Não. Uma extração limpa funciona até o seu próximo prompt, e então a defasagem começa.

Você pode pedir ao Lovable, ao Cursor ou ao Claude Code para configurar uma biblioteca de i18n adequada e extrair todas as strings para catálogos de tradução. Isso de fato funciona na versão em que você o executa. O problema é que não existe um checkpoint natural em que a extração esteja "concluída". A próxima seção de preços, o próximo estado vazio, o próximo rótulo de botão chegam como novas strings fixas no código, e seus catálogos silenciosamente ficam defasados.

A alternativa manual, pedir ao Lovable para atualizar cada catálogo a cada mudança, parece disciplinada e desmorona na prática. Você precisa lembrar, para cada string, em cada idioma, em cada prompt. Multiplique por quatro idiomas e cada mudança na interface se torna um exercício de coordenação. Esse atrito é exatamente o que mata a velocidade que tornava o Lovable vantajoso de usar.

Como eu torno meu app Lovable multilíngue, passo a passo?

Antes de começar: conecte seu projeto Lovable ao GitHub (menu + no campo de chat, depois GitHub, depois Connect project), crie uma conta no globalize.now (cadastro gratuito, crédito inicial de €5, sem cartão) e certifique-se de ser owner ou admin do workspace no Lovable para poder adicionar a skill uma vez para todo o workspace.

Conecte o repositório, adicione a skill lovable-i18n uma vez e deixe a sincronização rodar a cada push. Aqui está o caminho completo.

  1. Conecte seu projeto Lovable ao GitHub. Use o menu + no campo de chat, depois GitHub, depois Connect project. O Lovable sincroniza seu projeto com um repositório real, o que é o que torna possível um i18n durável. Tudo a seguir opera nesse repositório, não dentro de uma caixa-preta.
  2. Adicione a skill lovable-i18n ao seu workspace. O Lovable suporta skills reutilizáveis. 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 (é necessário ser owner ou admin do workspace). Adicionar uma skill é gratuito e não consome créditos. Está construindo no Cursor ou no Claude Code em vez disso? Execute npx skills add globalize-now/globalize-skills no repositório conectado.
  3. Peça ao Lovable para configurar. Cole no chat do Lovable: Set up i18n for my project using the lovable-i18n skill. O Lovable identifica sua stack (Vite SPA ou TanStack Start), faz uma 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 (@lingui/core, @lingui/react, o plugin do Vite), integra o provider, monta um catálogo PO por locale em src/locales/{locale}/messages.po, envolve as strings em macros <Trans> e adiciona um seletor de idioma.
  4. 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.
  5. Conecte o repositório ao globalize.now. Faça login, depois Connect repository, autorize o app do GitHub, selecione o repositório Lovable e a branch padrão, e escolha os idiomas (mais de 50, incluindo RTL).
  6. Continue construindo no Lovable. A cada push, o globalize.now abre um PR de tradução com os catálogos PO atualizados. Faça o merge. Seu app é lançado traduzido. Nada mais é necessário de sua parte entre releases.

O ponto que realmente importa está nos passos três a seis: a configuração acontece uma única vez, e a sincronização contínua não exige comando, dashboard nem fila de revisão. Para o passo a passo completo da integração, veja a página de integração com o Lovable.

Qual biblioteca de i18n um app Lovable deve usar?

A skill lovable-i18n instala o Lingui, porque apps Lovable são projetos React do tipo Vite SPA ou TanStack Start, e o Lingui se encaixa bem nessa stack.

A skill integra @lingui/core, @lingui/react e o plugin do Vite, monta catálogos PO em src/locales/{locale}/messages.po e envolve as strings em macros <Trans>. react-i18next e next-intl são as escolhas certas para outras configurações React e Next.js, mas a skill não os instala.

Evite inventar um contexto de tradução personalizado ou fixar um mapa de idiomas no código. Parece mais leve no primeiro dia e se torna aquilo que você vai ter que arrancar no trigésimo dia. A página para desenvolvedores do globalize.now mostra como a extração se aplica a cada biblioteca, para que você não escolha no escuro.

Como eu mantenho as traduções sincronizadas enquanto continuo dando prompts no Lovable?

Mova a sincronização para dentro do seu fluxo de trabalho no Git, para que ela nunca possa ser esquecida.

O motivo pelo qual o i18n manual falha é que ele depende de uma pessoa lembrar de uma tarefa durante um ciclo de desenvolvimento acelerado. Infraestrutura remove a pessoa do processo. Quando a etapa de diff e tradução roda a cada push, uma nova string criada por um prompt no Lovable é capturada nesse push, traduzida e enviada de volta em um PR antes do merge da branch. Não existe release em que os catálogos PO fiquem silenciosamente defasados, porque não existe etapa manual para pular.

Essa é a diferença entre uma configuração e uma infraestrutura. Uma configuração é um estado que você alcança uma vez. Infraestrutura é uma propriedade que se mantém enquanto tudo ao redor muda. Para um app que você continua editando no Lovable, você quer a propriedade, não o estado. Mais sobre o fluxo de trabalho específico de apps construídos com IA está na página para vibe coders, e se você está avaliando ferramentas, o guia comparativo mostra onde cada uma se encaixa na stack.

Tornar um app Lovable multilíngue é fácil de começar e difícil de manter. O globalize.now cuida da manutenção. No Lovable, adicione a skill lovable-i18n em Open Skills, depois Add, depois Import from GitHub, apontando para globalize-now/lovable-i18n. No Cursor ou no Claude Code, execute npx skills add globalize-now/globalize-skills. 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