Você torna um app Replit multilíngue conectando seu repositório Git ao GitHub e mantendo os catálogos de tradução nesse repositório como arquivos versionados. O Replit já armazena cada checkpoint do Agent como um commit no Git, então o repositório existe antes mesmo de você pensar em idiomas; o trabalho é colocá-lo no GitHub e deixar que os catálogos voltem pelo mesmo histórico. O globalize.now é uma infraestrutura de localização baseada em IA: ele produz as chaves e os arquivos de locale, e a biblioteca de runtime que seu app já usa os serve. Nenhum dashboard fica no caminho de execução, e nada traduz a página depois que ela já carregou.
Por que pedir ao Agent para traduzir o app não funciona?
Porque não há para onde traduzir. Quando você pede ao Replit Agent um dashboard, ele escreve <h2>Your bookings</h2> dentro de um componente, não uma busca em um catálogo. Todo título, botão, estado vazio, toast e erro de validação cai no JSX como um literal, no idioma em que você fez o prompt.
Então, quando depois você pede ao Agent para "traduzir o app para o afrikaans", você recebe um de dois resultados pela metade: uma segunda cópia dos componentes com o texto trocado, ou um objeto translations montado à mão cobrindo as telas que o Agent calhou de olhar. Nenhum dos dois é uma camada de locale de verdade. A próxima feature volta a sair em inglês. Documentamos essa mesma recorrência em Cursor fica adicionando strings fixas; o Replit Agent se comporta do mesmo jeito, porque ele resolve o prompt que tem na frente, não a arquitetura por trás dele.
A correção é estrutural: dar chaves às strings, colocar as traduções em arquivos e fazer o runtime ler a partir desses arquivos. É isso que "multilíngue" significa em uma base de código, e é uma mudança que se faz uma única vez.
O que o Replit Agent realmente gera?
Um projeto web convencional, e essa é a boa notícia. Os tipos de app selecionados pelo Replit são construídos em torno de React com ShadCN UI no front-end, geralmente combinado com um servidor Express no mesmo projeto, tudo em TypeScript. Desde setembro de 2025, o Agent também funciona com qualquer framework que você já use, incluindo repositórios importados do GitHub, então um projeto em Next.js ou Vue é possível; o caminho padrão continua sendo a stack React.
Para localização, a stack é o único fato que importa, e é terreno conhecido. React com Vite e TypeScript é a combinação mais suportada no ecossistema de i18n: i18next, Lingui e react-intl atendem diretamente a ela. Se o Agent tivesse construído um app Next.js em vez disso, a escolha seria entre next-intl, react-i18next e Lingui, e essa comparação é assunto para outro post.
O que muda em relação a um construtor voltado só para o front-end é a segunda metade do projeto. Um app do Replit geralmente tem um servidor, e servidores também têm strings. Mais sobre isso adiante.
Onde fica o repositório Git em um app do Replit?
Ele já está lá. O controle de versão do Replit é Git por baixo dos panos, e os checkpoints do Agent são commits nesse repositório. Toda vez que o Agent termina uma feature e oferece um ponto de rollback, ele fez um commit. A própria documentação do Replit recomenda migrar para commits Git comuns para acompanhamento de longo prazo quando você trabalha com repositórios externos, que é exatamente o caso aqui.
Para colocá-lo no GitHub:
- Adicione a ferramenta Git na seção Tools do editor do projeto.
- Conecte sua conta do GitHub em serviços conectados e, em seguida, conecte o repositório pelo painel Git. Se o projeto ainda não foi inicializado, o painel oferece fazer isso primeiro.
- Faça o push. O painel envia com um clique e permanece sincronizado com tudo que você rodar no Shell, então
git push origin maintambém funciona.
O Replit também suporta GitLab e Bitbucket, e o mesmo fluxo se aplica. O ponto não é o provedor; é que o repositório agora está em algum lugar onde um job de localização pode abrir um pull request.
Faça isso antes de tocar em uma única string. Trabalho de localização é trabalho com arquivos, e um diff é o lugar certo para revisá-lo.
O que significa "sem dashboard" para um app do Replit?
Significa que as strings traduzidas são arquivos no repositório e o app as serve como qualquer outro asset. Sem tag de script, sem fetch externo no carregamento da página, sem conta de fornecedor entre o visitante e o seu texto.
A alternativa é um widget de runtime que troca o texto depois que a página já foi renderizada. Os custos disso são estruturais: a primeira renderização é em inglês, o texto traduzido não está no HTML que os crawlers leem primeiro, um script de terceiros fica no seu caminho de produção, e suas strings ficam armazenadas no fornecedor, então sair de lá significa fazer uma exportação. A versão desse argumento para o Lovable está em Localize um app Lovable sem dashboard e se aplica ao Replit sem alterações.
Há um motivo específico do Replit que torna isso ainda mais relevante aqui. O Replit faz o deploy do app para você, então a cópia em execução no seu domínio Replit é exatamente o que está no projeto no momento do deploy. Um widget traduziria esse deploy de fora para dentro. Catálogos no repositório significam que o deploy já contém todos os idiomas, e o preview do Replit mostra a versão em alemão antes mesmo de você publicar.
A contrapartida é real e vale mencionar: uma mudança de texto exige um commit e um novo deploy, não um simples botão de salvar. Para quem constrói sozinho e publica direto do Replit, isso não é um problema; para quem espera editar texto ao vivo sem tocar no projeto, é uma limitação.
Como funciona a configuração nativa de repositório?
Conecte o repositório no app globalize.now. A conversão roda uma vez sobre a base de código: as strings fixas viram unidades de catálogo com chaves, e os componentes passam a ler de uma biblioteca de runtime em vez de conterem literais. É uma operação única, não algo que roda de novo depois.
Depois da conversão, jobs de push traduzem novas unidades de catálogo conforme o app cresce. Peça ao Agent uma nova página de configurações, faça o push, e as novas unidades são traduzidas; as existentes permanecem intactas. Os catálogos voltam como arquivos commitados, JSON ou PO dependendo da biblioteca de runtime, em um pull request que você revisa como qualquer outra mudança.
Duas fronteiras, porque a categoria costuma gerar confusão. O globalize.now não substitui a biblioteca de runtime; i18next, Lingui e next-intl continuam fazendo o trabalho delas. E também não é um motor de tradução competindo com o DeepL. É a camada intermediária que produz as chaves e os arquivos de locale. A visão geral para desenvolvedores traz os detalhes técnicos.
Como as traduções voltam para o Replit?
Pelo mesmo painel Git, no sentido contrário. Essa é a etapa que difere do Bolt ou do Lovable, porque o Replit também é onde o app roda.
- Revise e faça o merge do pull request no GitHub.
- No painel Git do Replit, selecione Pull. Se você ou o Agent alteraram os mesmos arquivos nesse meio-tempo, o painel destaca os conflitos e você os resolve no editor antes de concluir o merge.
- Faça um novo deploy. Os catálogos agora fazem parte do projeto, então o deploy passa a carregar todos os idiomas.
Um detalhe específico do Replit: os checkpoints do Agent restauram todo o estado do projeto, incluindo arquivos. Se você voltar a um checkpoint criado antes de puxar a branch de tradução, os catálogos voltam junto. Trate o merge como um marco, deixe o Agent criar um checkpoint depois dele, e faça rollback para esse checkpoint em vez de um anterior.
Quais strings ficam no servidor?
Aquelas que o front-end nunca vê como JSX. Um app do Replit com back-end em Express tem uma segunda superfície de strings: mensagens de erro de API, respostas de validação, assuntos de e-mail, corpos de notificação, cabeçalhos de CSV, qualquer coisa que o servidor formata antes de enviar. Um catálogo de front-end não alcança essas strings, e um widget não consegue vê-las de forma alguma, porque elas nunca chegam ao DOM.
O padrão é o mesmo do cliente, aplicado no lado do servidor. Dê ao servidor uma cópia da biblioteca de runtime, leia o locale do visitante a partir da requisição (um cabeçalho Accept-Language ou um campo de locale no registro do usuário) e formate as respostas a partir do catálogo em vez de literais de string. O namespace de chaves permanece compartilhado, então errors.booking.overlap significa a mesma coisa em um toast e em uma resposta 409.
Pule essa etapa e o app parece multilíngue até o primeiro erro, quando volta a falar inglês.
O que verificar antes de adicionar um segundo idioma?
Revise estes pontos antes da conversão, porque cada item é mais barato de corrigir agora do que depois que cinco idiomas já estiverem em produção:
- Strings concatenadas.
"Welcome back, " + user.namenã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 cima de
count === 1está errado na maioria dos idiomas. - Datas, números e moeda. Use
Intl, não formatação manual de strings, tanto no cliente quanto no servidor. - Layout. Alemão e finlandês rendem textos mais longos que o inglês. Botões de largura fixa quebram, e classes do Tailwind parecem estar corretas até o texto real chegar.
- Direção da escrita (RTL). Se árabe ou hebraico estão no roadmap, decida isso agora. Adaptar para RTL depois é a parte cara.
- Desalinhamento de catálogos. Uma vez que os catálogos existem, uma chave adicionada em um idioma e esquecida nos outros é um bug silencioso. Por que os arquivos de tradução saem de sincronia explica como isso acontece e o que um job de push faz a respeito.
O preço é por workspace, sem cobrança por usuário e sem cobrança por idioma, então o número de idiomas é uma decisão de produto, não uma linha de orçamento. Os valores atuais estão na página de preços. Para o mesmo passo a passo com outros construtores de apps, a visão geral para vibe coders é o ponto de partida.
Por onde começar
Se o seu projeto Replit já está conectado ao GitHub, o próximo passo é rodar a conversão sobre esse repositório, não decidir qual ferramenta usar. Se ainda não está conectado, o painel Git é o passo anterior a este.
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