Publicado8 de julho de 2026

Seu app Lovable está preso em inglês no SSR

Principais pontos

Os novos projetos Lovable agora usam TanStack Start com SSR, o que quebra a abordagem de tradução via widget em runtime que a maioria dos guias ainda ensina.
No SSR, o servidor renderiza primeiro em inglês, então os widgets do lado do cliente causam um flash em inglês e os crawlers indexam o idioma errado.
Catálogos PO do Lingui versionados no repositório renderizam o idioma correto no servidor e geram páginas indexáveis por idioma.
Guarde o locale ativo em um cookie, não no localStorage, para que o servidor consiga resolvê-lo antes de renderizar.
O globalize.now extrai as strings, gera os catálogos e os sincroniza a cada push, então você nunca precisa gerenciar arquivos de locale manualmente.

Se o seu app Lovable continua sendo renderizado em inglês independentemente do idioma que você adiciona, a causa é a mudança de stack: desde meados de maio de 2026, os novos projetos Lovable passaram a usar TanStack Start com renderização no servidor, em vez do antigo SPA com React e Vite. O globalize.now é uma infraestrutura de localização com IA que se encaixa nesse novo stack extraindo suas strings para catálogos PO do Lingui versionados no repositório, de modo que o idioma correto seja renderizado no servidor em vez de ser trocado no navegador. A solução não é mais um widget. É levar a tradução para dentro do seu repositório, onde o servidor pode renderizá-la e os mecanismos de busca podem indexá-la.

Por que localizar seu app Lovable ficou de repente mais difícil?

Porque o terreno mudou embaixo dos conselhos antigos. A maioria dos guias de "como traduzir seu app Lovable" parte do pressuposto de um SPA renderizado no cliente, onde um widget pode reescrever o DOM depois do carregamento sem que ninguém note. Esse pressuposto agora está errado para novos projetos.

O Lovable migrou os novos projetos para o TanStack Start com SSR para que os crawlers recebam HTML totalmente renderizado já na primeira requisição, sem precisar executar JavaScript. Isso é uma vitória real para o SEO, mas inverte a forma como a tradução precisa funcionar. Quando a primeira resposta já chega renderizada, traduzi-la depois, no navegador, já é tarde demais.

Se você construiu seu app nos últimos meses e instalou um widget de tradução em runtime, você está vendo o sintoma: um flash em inglês, seguido da troca. A integração do globalize.now com o Lovable existe justamente para resolver isso na camada certa.

O que realmente mudou com a migração do Lovable para o TanStack Start?

O modelo de renderização mudou de client-side para server-side. Antes, o Lovable gerava SPAs construídos com React e Vite, publicados como arquivos estáticos e renderizados inteiramente no navegador. Agora a base é o TanStack Start, um framework React full-stack com SSR, SSG e CSR por rota, além de funções de servidor colocadas junto com os componentes.

Para a localização, três coisas importam. Primeiro, o HTML é gerado no servidor antes de chegar ao navegador, então o idioma é decidido do lado do servidor. Segundo, o roteamento agora suporta URLs reais por locale. Terceiro, qualquer coisa que dependa de APIs exclusivas do navegador para escolher um idioma roda depois que o servidor já se comprometeu com um.

Esse terceiro ponto é onde vive a maioria das configurações quebradas. Um locale salvo em localStorage é invisível para o servidor, então o servidor renderiza o idioma padrão e o cliente o corrige um instante depois.

Por que os widgets de tradução em runtime causam um flash em inglês no SSR?

Porque eles traduzem depois que o servidor já enviou o inglês. No novo stack, a sequência é: o servidor renderiza o HTML no idioma padrão, o navegador o exibe, e só então o JavaScript do widget carrega e reescreve o texto. O intervalo entre a exibição e a reescrita é o flash em inglês, e agora isso é um problema estrutural, não algo que se resolve com ajustes finos.

O custo para o SEO é ainda pior que o flash. Um crawler lê a primeira resposta e segue adiante. Se o texto traduzido só aparece depois que o JavaScript do cliente executa, o crawler indexa inglês para todos os locales, e você não tem páginas por idioma para ranquear. Todo o motivo pelo qual o Lovable migrou para SSR, HTML indexável, é anulado ao traduzir no navegador.

Catálogos versionados evitam isso por design. Quando as strings de tradução vivem no seu repositório, o TanStack Start renderiza o locale solicitado no servidor, então a primeira resposta já sai correta. Essa é a diferença duradoura entre uma infraestrutura que vive no seu código-fonte e um widget que roda por cima dele, e é por isso que ferramentas em runtime como o Weglot se encaixam melhor no antigo modelo de SPA do que no novo. Para uma análise mais detalhada do problema de sincronização, veja por que as traduções do Lovable quebram a cada push.

Como tornar multilíngue um app Lovable feito com TanStack Start?

Mova a tradução para o servidor e mantenha os catálogos no seu repositório. Na prática, isso são quatro etapas no novo stack, e nenhuma delas exige que você edite arquivos de locale manualmente.

Adicione a skill lovable-i18n e deixe o Lovable configurar o i18n. No seu workspace do Lovable, adicione a skill lovable-i18n e peça ao Lovable para configurar a internacionalização. Ela instala o Lingui, extrai suas strings de UI fixas para catálogos de mensagens e configura o provider. Fora do editor, a mesma configuração é instalada com npx skills add globalize-now/globalize-skills (adicione --all para instalar em todos os agentes).
Roteie os locales com o parâmetro de caminho opcional do TanStack. O TanStack Router usa {-$locale} para parâmetros de caminho opcionais, então uma rota definida como /{-$locale}/about corresponde tanto a /about, para o seu idioma padrão, quanto a /es/about, para espanhol. Isso dá a cada idioma uma URL distinta e rastreável por crawlers, em vez de uma única URL cujo texto muda no navegador.
Resolva o locale no servidor, não no localStorage. Guarde o idioma ativo em um cookie para que o handler de SSR consiga lê-lo a partir da requisição. Com o Lingui, o servidor chama setupLocaleFromRequest() antes de criar o router, e a hidratação no cliente chama dynamicActivate() com o locale fornecido pelo servidor antes de renderizar. Ter o mesmo valor dos dois lados significa nenhuma incompatibilidade na hidratação e nenhum flash.
Mantenha os catálogos no seu repositório, sincronizados a cada push. Os catálogos PO são arquivos versionados, não o runtime de um fornecedor. Enquanto você continua construindo no Lovable e novas strings surgem, elas precisam ser extraídas e traduzidas de novo, e é essa parte que se deteriora quando feita manualmente. Esse é o trabalho que o globalize.now faz automaticamente, mantendo os catálogos sempre atualizados sem nenhuma etapa manual de exportação.

// server: resolve locale before the router exists
const locale = getLocaleFromCookie(request) ?? "en";
await setupLocaleFromRequest(locale);

// client: activate the SAME locale before first render
await dynamicActivate(serverLocale);

Por se tratar de um procedimento real, passo a passo, com resultado versionado, ele se comporta como código normal sob controle de versão: revisável em um pull request, comparável em diffs e portátil, caso você um dia decida deixar o Lovable.

Onde o globalize.now se encaixa no stack de i18n do TanStack Start?

Ele fica uma camada abaixo da biblioteca de runtime e acima do motor de tradução. O TanStack Start e o Lingui entregam as traduções em runtime; o DeepL ou um LLM produz as próprias traduções. O globalize.now é a infraestrutura entre os dois: ele gera as chaves e os catálogos PO e os mantém sincronizados, para que o runtime sempre tenha algo correto para renderizar.

O efeito prático para quem constrói com Lovable é que você para de ficar de babá dos arquivos de locale. Você instala a skill, dá o comando ao Lovable uma vez, e cada push subsequente extrai novas strings, preenche os catálogos e abre a alteração como um PR normal. Sem ida e volta em dashboard, sem reexportação, sem descompasso entre o que o seu app diz e o que os seus catálogos contêm.

O preço é um único plano: € 20/mês por workspace, incluindo € 20 de crédito de tradução (cerca de 200.000 palavras) por mês, e depois uso por token na mesma taxa por caractere. Não há cobrança por assento nem por idioma, e o cadastro vem com € 5 de crédito, sem cartão. Um app Lovable típico, cobrindo cinco locales, cabe tranquilamente nesse limite. Se quiser detalhes do lado técnico, as páginas globalize.now para desenvolvedores e vibe coders aprofundam o assunto, e a visão geral do produto cobre o restante do stack.

Seu app Lovable está travado em inglês porque a tradução está acontecendo no lugar errado, o navegador, depois que o servidor já se comprometeu com um idioma. Mova-a para dentro do seu repositório e o servidor vai renderizar o idioma correto já na primeira requisição. O globalize.now cuida da extração e da sincronização, então você configura uma vez e ele se mantém atualizado a cada push.

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

O Lovable realmente mudou seu stack, e isso quebra as traduções?

Sim. Desde meados de maio de 2026, novos projetos Lovable são lançados em TanStack Start com renderização no servidor, em vez de um SPA em React e Vite. Isso não quebra as traduções por si só, mas quebra a abordagem de widget em tempo real que muitos guias ainda recomendam. No SSR, o servidor envia primeiro o HTML em inglês já totalmente renderizado, então um widget do lado do cliente troca o texto depois do carregamento, causando um flash de inglês e fazendo os crawlers indexarem o idioma errado.

Por que não simplesmente adicionar um widget de tradução ao meu app Lovable?

Um widget em tempo real traduz no navegador depois que o servidor já renderizou o HTML em inglês. No novo stack com SSR, isso significa que os visitantes veem brevemente o inglês antes da troca, e os mecanismos de busca indexam a versão em inglês porque o texto traduzido nunca existe na primeira resposta. Catálogos de idioma versionados renderizam o idioma correto no servidor, então não há flash, e cada idioma é uma página real e indexável.

Como funcionam as URLs de idioma no TanStack Start?

O TanStack Router usa um parâmetro de caminho opcional escrito como {-$locale}, então uma rota como /{-$locale}/about corresponde tanto a /about, para seu idioma padrão, quanto a /es/about, para espanhol. Isso dá URLs limpas por idioma que um crawler pode indexar separadamente, que é justamente o objetivo de mover a tradução para o servidor em vez de um widget no cliente.

Onde meu app Lovable deve armazenar o idioma ativo no SSR?

Guarde essa informação em um cookie, não no localStorage. O localStorage não é acessível pelo servidor, então o servidor não tem como saber qual idioma renderizar, e você acaba vendo um flash com o idioma errado a cada carregamento. Já o cookie é enviado junto com a requisição, então o handler de SSR consegue resolver o locale antes de renderizar e passar o mesmo valor para o cliente durante a hidratação.

O que o globalize.now realmente faz por um app Lovable?

O globalize.now é uma infraestrutura de localização com IA. Ele extrai strings de UI fixas no código do seu projeto Lovable, gera chaves de tradução e catálogos PO do Lingui, e os mantém sincronizados a cada push no Git. Você instala como uma skill do Lovable e pede ao Lovable, uma única vez, para configurar o i18n; depois disso, os catálogos ficam no seu repositório e se atualizam automaticamente conforme seu app evolui.

← Voltar ao blog