Como localizar um app Lovable sem painel?

Você localiza um app Lovable sem painel mantendo cada parte do fluxo de trabalho no repositório: catálogos de mensagens como arquivos versionados, um arquivo de configuração que nomeia seus locales, e uma etapa de CLI no seu build que os compila. O globalize.now é uma infraestrutura de localização com IA que executa esse ciclo por você, extraindo strings do seu código, gerando chaves e arquivos de locale, e sincronizando as traduções a cada push no Git. Nada nessa cadeia exige uma interface de navegador, o que importa mais do que parece quando quem escreve seu código é um agente.

Por que um painel quebra um fluxo de trabalho construído com IA?

Porque o seu agente não consegue abri-lo. Lovable, Cursor, Claude Code e Copilot operam todos sobre as mesmas duas superfícies: arquivos em um repositório e comandos em um terminal. Um painel não é nenhuma das duas coisas.

Essa lacuna hoje é uma premissa documentada, não apenas uma preferência. O AGENTS.md, a convenção para informar aos agentes de código como um projeto funciona, foi doado à Agentic AI Foundation da Linux Foundation em dezembro de 2025, junto com o Model Context Protocol. Segundo o próprio anúncio da Linux Foundation, mais de 60 mil projetos de código aberto já haviam adotado o formato até então, em mais de vinte ferramentas de codificação com IA. A premissa central é que as instruções do projeto pertencem a um arquivo que o agente consegue ler.

O estado de tradução que vive atrás de um login fica fora dessa premissa. Quando o seu agente adiciona um novo botão ao seu app Lovable, ele consegue adicionar a string. Mas não consegue depois fazer login em algum lugar e reconciliar uma grade de tradução. Então a string vai para produção em inglês, a inconsistência se acumula, e você só descobre quando um usuário na Alemanha reclama.

Há uma segunda falha, mais silenciosa. Quando as correções só existem na interface de um fornecedor, o repositório deixa de ser a fonte de verdade sobre o que o seu app diz. Duas fontes de verdade, sendo que uma delas as suas ferramentas não conseguem inspecionar, é um problema de depuração esperando um prazo final para explodir.

Como é, na prática, uma configuração Lovable sem painel?

Quatro arquivos e um comando no seu build. Os apps gerados pelo Lovable são entregues em React, seja na stack clássica do Vite ou no TanStack Start com renderização no servidor, e ambos seguem a mesma estrutura.

1. Nomeie seus locales no config. Um único arquivo, versionado, é a lista que todas as outras camadas consultam.

// lingui.config.ts
import { defineConfig } from "@lingui/conf";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "de", "es", "fr"],
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

2. Extraia as mensagens em catálogos. lingui extract varre seu código-fonte e gera um catálogo .po por locale. Ele faz merge com o que já existe em disco, então as traduções existentes sobrevivem a uma nova execução — é essa propriedade que torna seguro colocar isso em um loop automatizado.

npx lingui extract

3. Compile antes de fazer o build. lingui compile transforma os catálogos em módulos de runtime. A flag --strict faz o build falhar quando uma tradução está faltando, o que transforma um fallback silencioso para o inglês em produção em um build vermelho que você vê primeiro.

{
  "scripts": {
    "build": "lingui compile --strict && vite build"
  }
}

4. Deixe a sincronização rodar a cada push. Adicionar um locale deveria ser uma edição no array locales, não um chamado de suporte. O globalize.now monitora o repositório, extrai as strings que o agente introduziu, gera as chaves e as entradas de catálogo para cada locale e faz o commit de volta. Os catálogos chegam como um diff em um pull request, revisável como qualquer outra mudança.

Os passo a passo completos por stack estão no guia do Lovable com Vite e no guia do TanStack Start.

O que acontece com as traduções gerenciadas por dashboard quando o fornecedor encerra as operações?

Elas somem junto com o fornecedor. Isso não é hipótese neste mês: o Lovalingo, um serviço de tradução em runtime feito para o Lovable e outros app builders de IA, encerra suas atividades em 31 de agosto de 2026 às 23h59 CEST. Novos projetos e assinaturas já pararam, e a própria página de encerramento da empresa orienta os clientes a implementar internacionalização própria do projeto em paralelo ao serviço antes de removê-lo, e depois verificar rotas de locale, fallbacks, URLs canônicas, hreflang e a saída do sitemap.

Isso é um fornecedor descrevendo, com precisão, a diferença entre alugar um workflow e ser dono dele.

A última linha traz uma consequência de SEO que sobrevive à questão do fornecedor. Traduções injetadas após o carregamento não ficam garantidamente no HTML que um crawler lê. Catálogos compilados no seu build ficam.

Como verificar se o seu app Lovable não depende de nenhum dashboard?

Três verificações, cada uma delas falha de forma bem visível.

Verifique a rede. Carregue seu app com o DevTools aberto, filtre por scripts e procure requisições para o domínio de um fornecedor de tradução. Se um script de terceiros precisa carregar antes que sua página em alemão seja lida como alemão, sua página em alemão depende da disponibilidade de outra empresa.

Verifique o repositório. Para cada locale no seu config, deve existir um arquivo de catálogo em disco, versionado pelo Git. Rode git ls-files "src/locales/**" e conte. Catálogos vazios ou ausentes indicam que as strings estão em outro lugar.

Verifique o build. Compile com --strict no CI. Uma tradução faltando deveria interromper um deploy. Se o seu build passa mesmo com um locale incompleto, a lacuna vai aparecer como texto em inglês numa interface que não é em inglês — o modo de falha que os usuários relatam como “o site está quebrado”.

Rode as três verificações em um deploy de preview antes de remover qualquer fornecedor existente, não depois. O próprio checklist de pré-remoção do Lovalingo reforça esse ponto: mantenha o serviço antigo instalado até que o substituto tenha sido testado em rotas de locale reais. Nossa comparação com o Lovalingo trata diretamente do caminho de migração.

Onde o globalize.now se encaixa se não há dashboard?

Na camada entre o seu runtime de i18n e o seu motor de tradução. Bibliotecas como Lingui, i18next e next-intl servem as traduções em runtime. Motores como DeepL e tradução por GPT produzem o texto. O globalize.now gera e mantém o que fica no meio: as chaves e os arquivos de locale, sempre atualizados junto com o código.

Essa camada é justamente a que antes exigia uma pessoa clicando em uma interface, por isso remover a interface é uma mudança de workflow, não a perda de uma funcionalidade. A configuração acontece uma única vez: conecte o repositório no globalize.now e a conversão chega como um pull request. No seu editor, a mesma configuração é um único comando:

npx skills add globalize-now/globalize-skills

Dentro do Lovable, a mesma funcionalidade é instalada como uma skill dentro do editor, para que o agente que constrói seu app possa acioná-la diretamente. O plano Starter custa 20 € por mês por workspace, incluindo 20 € de crédito de tradução (cerca de 200.000 palavras) por mês, com o uso excedente cobrado à mesma taxa por caractere. Sem cobrança por assento e sem cobrança por idioma, além de um crédito de 5 € no cadastro, sem precisar de cartão. Idiomas e projetos são ilimitados dentro de um único workspace — o que importa quando você está adicionando um quinto idioma, e não um quinto assento.

Mais sobre o fluxo de trabalho em torno disso para vibe coders e desenvolvedores, e a configuração específica para o Lovable na página de integração com o Lovable.

Resumo rápido

As traduções do seu app Lovable deveriam ser arquivos que você possui, num repositório que seu agente consegue ler, compilados pelo seu próprio build. O globalize.now mantém esses arquivos atualizados a cada push no Git.