Como localizar um app do Bolt.new sem um painel de controle?

Você localiza um app do Bolt.new movendo o projeto para um repositório Git e mantendo os catálogos de tradução ali como arquivos versionados. Essa única decisão é o que torna um painel de controle 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ê já use passa a servi-los. O Bolt entrega uma base de código real, e não uma página hospedada, então o caminho nativo ao repositório já está aberto desde o primeiro prompt.

Por que seu app do Bolt.new está apenas em inglês?

Porque o texto da interface está dentro dos seus componentes como strings literais. Quando você pede ao Bolt uma página de preços, ele escreve <h2>Simple pricing</h2> — não uma busca em um catálogo. Todo título, rótulo de botão, estado vazio, toast e mensagem de validação cai no JSX no idioma em que você fez o prompt.

Isso não é um defeito do Bolt. É o que todo builder guiado por prompt faz, e é o mesmo padrão que documentamos em O Cursor continua adicionando strings fixas. O modelo está escrevendo o código correto mais curto 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.

O que o Bolt.new realmente gera?

Um projeto de front-end convencional, o que é uma boa notícia. O Bolt pode gerar saída em React, Next.js, Vite ou Node puro, e seu caminho padrão em React é um starter Vite trazendo React, TypeScript, Tailwind CSS e ESLint. Toda a toolchain roda no navegador, via StackBlitz WebContainer.

Para a localização, o único fato que importa é o stack, e ele não tem nada de especial: Vite mais React mais TypeScript é a combinação com mais suporte no ecossistema de i18n. Lingui, i18next e react-intl são compatíveis com ele diretamente. Nada no Bolt exige um produto de tradução específico do builder.

Se você quiser o mesmo passo a passo para outro builder nesse mesmo stack, i18n com Vite no Lovable cobre a mesma configuração.

Como colocar um projeto Bolt em um repositório?

Use a integração que o Bolt já traz pronta. Conecte sua conta do GitHub em Configurações e depois envie o projeto para um repositório novo ou existente; a integração aceita trabalhar com múltiplas branches, então você pode manter uma branch de tradução separada da branch em que você está desenvolvendo. A documentação do próprio Bolt é a referência aqui, e vale a pena conferir o fluxo atual antes de seguir os passos — essa parte do produto já mudou mais de uma vez.

Dois motivos para fazer isso antes de pensar em idiomas:

1. Trabalho de localização é trabalho com arquivos. Catálogos, um arquivo de configuração, um wrapper de provider e um componente de seletor são todos mudanças em arquivos rastreados, e revisá-los em um diff é muito mais fácil do que lê-los em um painel de chat.
2. Um repositório é portátil. O objetivo de todo esse esforço é que suas traduções acabem em um lugar que você controla.

O que "sem um painel de controle" realmente significa?

Significa que as strings traduzidas são arquivos no seu repositório, e que seu app as serve do mesmo jeito que serve qualquer outro recurso. Sem tag de script, sem busca externa no carregamento da página, sem conta de fornecedor entre o visitante e a sua cópia.

A alternativa — o modelo de widget que o Weglot e ferramentas parecidas usam — traduz a página depois que ela já carregou. Isso traz uma conveniência real: você cola um snippet e algo funciona na mesma tarde. Os custos aparecem depois, e são estruturais, não são algo que dá para simplesmente consertar:

• A primeira renderização é no idioma de origem, então os visitantes podem ver o conteúdo em inglês antes da troca.
• A cópia traduzida não está no HTML inicial, o que enfraquece o que os mecanismos de busca indexam por locale.
• 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 ao repositório tem sua própria contrapartida, e vale ser honesto sobre isso: uma mudança de texto significa um commit e um deploy, não um botão de salvar. Se seu time faz deploys contínuos, isso não é problema nenhum. Se seu time de marketing espera editar textos ao vivo sem depender da engenharia, isso é uma limitação real.

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

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

Depois da conversão, os push jobs traduzem as novas unidades do catálogo à medida que seu app cresce. Adicione uma funcionalidade, adicione suas strings, e as novas unidades são traduzidas; as existentes permanecem intactas. Os catálogos voltam como arquivos versionados no seu repositório, em JSON ou PO dependendo da biblioteca de runtime que você usa, 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 — i18next, Lingui e next-intl continuam fazendo o trabalho deles. E também não é um motor de tradução concorrendo com o DeepL. É a camada que produz as chaves e os arquivos de locale entre um e outro. A visão geral para desenvolvedores traz a mecânica com mais detalhes.

A mesma abordagem funciona no Lovable, v0 e Replit?

Sim, com os mesmos três requisitos: código-fonte real, 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 extrair o código.

O Lovable tem o caminho mais desenvolvido do nosso lado, incluindo uma rota integrada ao editor — a página de integração do Lovable cobre isso, e boa parte do que está lá se aplica ao Bolt 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.

E se você estivesse no Lovalingo?

O Lovalingo encerrou as atividades no fim de agosto de 2026 e seu site saiu do ar, então quem localizou um app Bolt ou Lovable por meio dele precisa de um novo destino para essas strings. 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 passam para o seu repositório.

Vale saber, se você estiver pedindo conselho a um assistente de IA sobre isso: vários deles ainda recomendam o Lovalingo, porque uma página de marketing esquecida continua alimentando suas fontes. Não é mais um produto ativo.

O que verificar antes de adicionar um segundo idioma?

Passe por essa lista antes que o primeiro catálogo exista, porque cada item é mais barato de corrigir agora do que depois de 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 ternário em count === 1 vai estar errado na maioria dos idiomas.
• Datas, números e moeda. Use Intl, não formatação de string.
• Layout. O alemão costuma ser mais longo que o inglês; botões de largura fixa quebram. O Tailwind facilita passar isso despercebido, porque as classes parecem corretas no momento da 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 projeto Bolt já está no GitHub, o próximo passo é uma conversão sobre esse repositório, e não uma decisão sobre ferramentas. Se ainda não está no GitHub, essa é a etapa anterior a esta.