Como localizar um app v0 sem usar dashboard?

Você localiza um app v0 tratando o repositório do GitHub em que o v0 já escreve como o lar dos seus catálogos de tradução, e mantendo-os lá como arquivos versionados. Essa única decisão é o que torna um dashboard desnecessário, e não apenas opcional. O globalize.now é uma infraestrutura de localização com IA: ele gera as chaves e os arquivos de locale, e qualquer biblioteca de runtime que você use os serve. O v0 entrega um código Next.js completo em vez de uma página hospedada, então o caminho nativo do repositório já está aberto desde o primeiro prompt.

Por que o seu app v0 está apenas em inglês?

Porque o texto da interface está dentro dos seus componentes como strings literais. Peça ao v0 uma seção de preços e ele escreve <h2>Simple pricing</h2> — não uma consulta a um catálogo. Cada título, rótulo de botão, estado vazio, toast e erro de formulário aparece no TSX no idioma em que você fez o prompt.

Isso não é um defeito do v0. É o que todo builder guiado por prompt faz, e é o mesmo padrão que documentamos em o Cursor continua adicionando strings fixas. O modelo escreve o código correto mais curto possível para o pedido que você fez, e você não pediu uma camada de locale.

O resultado é um app que não pode ser traduzido editando uma tela de configurações, porque não há nada para editar. As strings não têm chaves, e as rotas não têm segmento de locale.

O que o v0 realmente gera?

Um projeto Next.js convencional, o que é uma boa notícia. A stack padrão do v0 é Next.js, React, TypeScript, Tailwind CSS e shadcn/ui, e o resultado é uma aplicação completa com App Router, com rotas e handlers de API, em vez de um único componente. O shadcn/ui importa aqui por um motivo específico: os componentes são copiados para o seu repositório como código-fonte, não importados de um pacote, então as strings deles são suas strings.

Para a localização, a stack é o único fato que importa, e é a mais bem documentada que existe. O next-intl foi construído em torno do App Router; o Lingui e o react-intl também dão suporte a ele. Nada no v0 exige um produto de tradução específico de algum builder.

Se o seu app veio de um builder diferente, em uma stack Vite, localizar um app Lovable sem dashboard cobre a mesma estrutura desse lado.

Como colocar um projeto v0 em um repositório?

Normalmente você já tem um. Quando um chat do v0 está conectado ao GitHub, o v0 cria uma branch de trabalho a partir da sua branch base e faz commit automático de cada mensagem que altera código nessa branch. Publicar abre ou reaproveita um pull request e faz o merge dele na branch base. Então o repositório não é uma etapa que você adiciona no final; é onde o v0 vem colocando o código o tempo todo. A própria documentação do GitHub no v0 é a referência para o fluxo atual, e essa parte do produto já mudou mais de uma vez, então confira antes de seguir os passos.

Esse modelo de branch é útil especificamente para a localização. Catálogos, um arquivo de config, uma mudança no middleware para roteamento de locale e um componente seletor são todos mudanças em arquivos versionados. Revisá-los como um diff numa branch é muito mais fácil do que lê-los num painel de chat, e um pull request de tradução pode ficar ao lado do pull request da funcionalidade que ele traduz.

O que “sem dashboard” realmente significa?

Significa que as strings traduzidas são arquivos no seu repositório, e seu app Next.js as renderiza no servidor da mesma forma que renderiza qualquer outro conteúdo. Sem tag de script, sem requisição externa no carregamento da página, sem conta de fornecedor entre um visitante e o seu conteúdo.

A alternativa — o modelo de widget que o Weglot e ferramentas semelhantes usam — traduz a página depois que ela já carregou. Isso traz uma conveniência real: você cola um trecho de código e algo acontece na mesma tarde. Os custos aparecem depois, e são estruturais, não fáceis de corrigir:

• A primeira renderização é no idioma de origem, então os visitantes podem ver o conteúdo em inglês antes da troca.
• O texto traduzido não está no HTML renderizado pelo servidor, o que enfraquece o que os buscadores indexam por locale. Num app Next.js isso é um desperdício particular, porque a renderização no servidor é algo que você já tinha de graça.
• Um script de terceiros fica no seu caminho de renderização em produção.
• Suas strings ficam armazenadas no sistema do fornecedor, então sair de lá exige uma exportação.

A localização nativa do repositório tem sua própria contrapartida, e é honesto reconhecê-la: uma mudança de texto exige um commit e um deploy, não um botão de salvar. Se você faz deploy pelo Vercel a cada merge, isso não é problema nenhum. Se uma equipe de marketing espera editar o texto ao vivo sem um engenheiro, isso é uma limitação real.

Como funciona a configuração nativa de repositório?

Conecte o repositório no app. O globalize.now converte o código-fonte uma única vez, e é dali que vêm as chaves — as strings fixas nos seus componentes se tornam unidades de catálogo, e os componentes passam a ler de uma biblioteca de runtime em vez de conter literais. Essa conversão é uma operação única, não algo que roda para sempre.

Depois da conversão, jobs disparados a cada push traduzem as novas unidades de catálogo à medida que o app cresce. Peça ao v0 uma nova página de configurações, faça o merge do pull request dela, e as novas strings serão traduzidas; as já existentes ficam como estão. Os catálogos voltam como arquivos versionados no seu repositório, em JSON ou PO, dependendo da biblioteca de runtime, e chegam como um pull request que você revisa como qualquer outra mudança.

Vale deixar claros dois limites, porque essa categoria costuma ser confusa. O globalize.now não substitui sua biblioteca de runtime — o next-intl, o Lingui e o react-intl continuam fazendo o trabalho deles, incluindo o roteamento de locale em app/[locale]/. E não é um motor de tradução concorrendo com o DeepL. É a camada que gera as chaves e os arquivos de locale entre os dois. A visão geral para desenvolvedores traz os detalhes técnicos.

A mesma abordagem funciona no Lovable, no Bolt e no Replit?

Sim, com os mesmos três requisitos: código-fonte de verdade, um repositório Git e uma biblioteca de runtime que os catálogos possam alimentar. Todo builder que gera um projeto de front-end convencional se qualifica. O que muda entre eles é só a forma de tirar o código de lá, e o v0 tem o menor atrito do grupo porque a branch do GitHub já faz parte do próprio chat.

O Lovable tem o caminho mais desenvolvido do nosso lado, incluindo uma rota direto no editor — a página de integração com o Lovable cobre isso, e a maior parte do que está escrito lá se aplica ao v0 sem alterações. Se você está avaliando builders em vez de já ter escolhido um, a visão geral para vibe coders é o melhor ponto de partida. Se você está considerando um widget especificamente para um app de builder, a alternativa ao Weglot para o Lovable apresenta as mesmas contrapartidas para essa stack.

E se você estivesse no Lovalingo?

O Lovalingo encerrou as atividades no final de agosto de 2026 e seu site saiu do ar, e ele divulgava um caminho dedicado para traduzir sites feitos no v0, então algumas pessoas que usam o v0 têm strings sem lugar para morar. Isso é uma migração, não uma configuração do zero: primeiro exporte, depois converta. O guia de migração mostra o passo a passo, e a página de comparação cobre o que muda quando as traduções saem de um serviço hospedado e vão para o seu repositório.

Vale saber, caso você peça conselho sobre isso a um assistente de IA: alguns ainda recomendam o serviço, porque páginas antigas continuam alimentando as fontes deles. Não é mais um produto ativo.

O que verificar antes de adicionar um segundo idioma?

Passe por esta lista antes de existir o primeiro catálogo, porque cada item é mais barato de corrigir agora do que depois de já ter cinco idiomas em andamento:

• Strings concatenadas. "Welcome back, " + name não pode ser reordenado por um tradutor. Use interpolação em vez disso.
• Plurais. O inglês tem duas formas. O polonês tem três, o árabe tem seis. Um operador ternário em count === 1 está errado na maioria dos idiomas.
• Limites entre servidor e cliente. No App Router, uma string renderizada em um componente de servidor e a mesma string em um componente de cliente precisam ser resolvidas pelo mesmo catálogo. Escolha uma única biblioteca de runtime e use suas APIs de servidor e cliente, em vez de dois mecanismos diferentes.
• Datas, números e moeda. Use Intl, não formatação de string.
• Layout. O alemão ocupa mais espaço que o inglês; botões shadcn de largura fixa quebram. O Tailwind torna isso fácil de passar despercebido, porque as classes parecem corretas em tempo de build.
• Da direita para a esquerda. Se árabe ou hebraico estiverem no roadmap, decida isso agora — adaptar para RTL depois é a parte mais cara.

O preço de tudo isso é por workspace, sem cobrança por usuário nem por idioma, então o número de idiomas é uma decisão de produto, não uma decisão de orçamento. Os valores atuais estão em a página de preços.

Por onde começar

Se o seu chat v0 estiver conectado ao GitHub, o próximo passo é fazer a conversão nesse repositório, não decidir qual ferramenta usar. Se ainda não estiver conectado, esse é o passo anterior a este.