A melhor forma de localizar um app Lovable construído sobre o stack clássico do Vite é extrair suas strings fixas para catálogos PO do Lingui versionados no repositório, e não simplesmente encaixar um widget de tradução em tempo de execução. Seu app Lovable é uma SPA React renderizada no cliente, então não há renderização no servidor para se conectar, e a opção durável são arquivos de tradução que vivem no seu próprio repositório e vão junto com o seu build. O globalize.now é uma infraestrutura de localização com IA que faz essa extração e mantém esses catálogos sincronizados a cada push no Git, então você configura uma vez e nunca mais precisa gerenciar arquivos de locale manualmente.
Em qual stack seu app Lovable está: o Vite clássico ou o TanStack Start?
Antes de tudo, abra a árvore de arquivos do seu projeto, porque o Lovable oferece dois stacks diferentes e cada um exige uma configuração de i18n distinta. Se você vir src/pages/Index.tsx, src/main.tsx e vite.config.ts, você está no stack clássico Vite + React SPA, que é o padrão do Lovable. Já os projetos TanStack Start têm src/routes/, src/router.tsx, src/routeTree.gen.ts e src/server.ts.
O stack é escolhido no momento da criação do projeto e não pode ser trocado depois, então essa decisão já foi tomada por você. O stack clássico do Vite renderiza tudo no navegador e não faz busca de dados no servidor por padrão. Este guia cobre essa SPA clássica com Vite. Se seus arquivos corresponderem ao layout do TanStack Start, siga em vez disso nosso guia de i18n para TanStack Start no Lovable, já que a renderização no servidor muda a forma como as traduções são carregadas.
Por que os apps Lovable em Vite SPA ficam de fora das ferramentas de i18n?
Porque a atenção das ferramentas migrou para o novo padrão do Lovable, TanStack Start com SSR, deixando a SPA clássica com Vite mal atendida, mesmo sendo esse ainda o stack mais comum no Lovable. Nos últimos meses, as ferramentas de localização voltadas ao Lovable, incluindo Lovalingo, Intlayer e Paraglide, redirecionaram todos os seus guias para o TanStack Start com renderização no servidor.
Isso deixa uma lacuna. Uma SPA renderizada no cliente tem restrições reais que os guias de SSR ignoram: não há renderização no servidor para injetar o markup já traduzido, o bundle inteiro carrega no navegador, e qualquer script que carregue depois acaba sobrepondo uma interface ainda em inglês. A boa notícia é que o stack clássico tem uma solução limpa e bem suportada que a maioria dos desenvolvedores nunca ouviu falar, porque as ferramentas mais barulhentas estão ocupadas correndo atrás do outro stack.
Qual é a diferença entre catálogos versionados no repositório e um widget de tradução em tempo de execução?
Catálogos versionados são arquivos de tradução incluídos no seu repositório e empacotados no momento do build, enquanto um widget de tempo de execução é um script de terceiros que troca o texto no navegador depois que sua interface em inglês já carregou. Essa diferença define três coisas que fazem toda a diferença para uma SPA em Vite.
Primeiro, o efeito de flash e o deslocamento de layout: um widget mostra o texto em inglês e depois o reescreve, então os usuários percebem uma troca visível e o layout pode até saltar. Catálogos versionados renderizam o idioma correto já na primeira renderização. Segundo, a indexabilidade: as strings que vão junto com o seu build fazem parte do seu código-fonte, enquanto o texto do widget é injetado depois e é mais difícil de ser lido pelos rastreadores. Terceiro, a propriedade: catálogos versionados são arquivos seus, no seu repositório, então nada externo precisa continuar online para seu app continuar falando alemão ou japonês.
Como adicionar i18n a um app Lovable Vite com Lingui?
Adicione o Lingui como sua camada de i18n, envolva suas strings e deixe o plugin dele para Vite compilar os catálogos. O Lingui é um framework de i18n leve, com um plugin dedicado para Vite e um formato de catálogo baseado em PO — exatamente o que uma SPA renderizada no cliente precisa.
Primeiro, instale os pacotes. O Lingui divide sua CLI, seu plugin Vite e seu runtime React:
npm install --save-dev @lingui/cli @lingui/vite-plugin @rolldown/plugin-babel
npm install @lingui/core @lingui/react
Em seguida, registre o plugin em vite.config.ts e adicione um lingui.config.ts que aponte para as pastas de código-fonte e de locales:
// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import { lingui } from "@lingui/vite-plugin";
export default defineConfig({
plugins: [react(), lingui()],
});
// lingui.config.ts
import { defineConfig } from "@lingui/cli";
export default defineConfig({
locales: ["en", "de", "fr"],
sourceLocale: "en",
catalogs: [
{
path: "src/locales/{locale}/messages",
include: ["src"],
},
],
});
Depois, envolva o texto JSX fixo com o macro Trans em vez de deixar strings soltas:
// before
<h1>Create your account</h1>
// after
import { Trans } from "@lingui/react/macro";
<h1><Trans>Create your account</Trans></h1>
Agora é hora de extrair. A CLI varre o diretório src e gera um catálogo PO para cada idioma, por exemplo src/locales/en/messages.po:
npx lingui extract
Preencha os campos msgstr para cada idioma, ou deixe essa etapa a cargo de uma camada automatizada (veja a próxima seção). Não é preciso rodar um comando de compilação separado, pois o @lingui/vite-plugin compila os catálogos PO em tempo real durante o desenvolvimento e o build.
Por fim, adicione um seletor de idioma ativando um locale em tempo de execução:
import { i18n } from "@lingui/core";
i18n.activate("de");
Esse é todo o fluxo para o stack clássico com Vite: instalar, envolver, extrair, traduzir, alternar. Tudo, exceto as próprias traduções, fica no seu repositório.
Como o globalize.now automatiza isso a cada push?
O globalize.now elimina as etapas manuais de extração e preenchimento monitorando seu repositório e fazendo tudo isso por você a cada push no Git. Ele localiza novas strings fixas no seu código Lovable, gera as chaves e entradas PO que o Lingui espera, produz as traduções e envia de volta os catálogos atualizados via commit — assim, sua pasta src/locales está sempre em dia sem que você precise rodar nenhum comando.
Conecte o repositório ao globalize.now uma única vez e ele passa a monitorar tudo automaticamente. Para configurar direto do seu editor, instale as skills:
npx skills add globalize-now/globalize-skills
Especificamente no Lovable, adicione a skill lovable-i18n no seu workspace e depois peça ao Lovable para configurar o i18n. O runtime continua sendo o Lingui, então nada muda na forma como seu app é renderizado. O que muda é que você para de ficar cuidando manualmente dos arquivos de locale. É o mesmo modelo de configurar uma vez e sincronizar a cada push em que se baseiam nosso fluxo de trabalho vibe-coder e nossa configuração para desenvolvedores.
O preço é simples para quem trabalha sozinho: 20 € por mês por workspace, sem cobrança por usuário nem por idioma, mais o valor das traduções que você efetivamente usar. Novos workspaces recebem um crédito de 5 € no cadastro, sem necessidade de cartão — o suficiente para traduzir um app pequeno do início ao fim.
Vale usar um widget em tempo de execução em vez disso? A lição do Lovalingo
Não, se você quer que suas traduções sobrevivam a qualquer fornecedor específico. Um widget de tradução em tempo de execução é conveniente no início, mas faz seu app depender do servidor de outra empresa continuar no ar — e essa dependência tem um risco real de falha.
O Lovalingo, um widget de tempo de execução popular entre quem constrói com Lovable, anunciou que vai encerrar as atividades em 31 de agosto de 2026, sem aceitar novos cadastros e sem sucessor designado. A própria orientação de migração da empresa recomenda que os usuários adotem uma internacionalização própria do projeto — exatamente a abordagem de catálogos versionados apresentada neste guia. Quando o fornecedor de um widget encerra as operações, as traduções injetadas param de funcionar e a interface volta para o inglês. Já os arquivos no seu repositório, não. Se você já usa um widget, nosso guia de migração do encerramento do Lovalingo mostra o caminho, e o problema mais amplo das traduções que quebram a cada push explica por que catálogos versionados vencem em apps construídos com IA.
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