Como localizar um app Base44 sem usar um painel de controle?

Você localiza um app Base44 conectando-o ao GitHub com a sincronização bidirecional que o Base44 oferece e mantendo os catálogos de tradução nesse repositório como arquivos commitados. O Base44 já espelha toda mudança entre o editor e o repositório, então, assim que os arquivos de idioma chegam à branch main, eles passam a fazer parte do app. O globalize.now é uma infraestrutura de localização com IA: ele produz as chaves e os arquivos de idioma, e a biblioteca de runtime do seu projeto os serve. Nenhum painel de controle fica no caminho de execução, e nada traduz a página depois que ela carrega.

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

Porque o texto de interface está fixo dentro dos seus componentes como strings literais. Quando você pede ao Base44 uma página de reservas, ele escreve <h2>Your bookings</h2> dentro de um componente React, não uma busca em um catálogo. Todo título, rótulo de botão, estado vazio, notificação e mensagem de validação acaba em JSX, no idioma em que você escreveu o prompt.

Isso não é um defeito do Base44. É o que qualquer builder guiado por prompts faz, e é o mesmo padrão que documentamos em O Cursor continua adicionando textos fixos. O modelo escreve o código correto mais curto possível para o pedido que você fez, e você não pediu por uma camada de idiomas.

Pedir ao Base44 para "traduzir o app para alemão" também não resolve. Você recebe uma cópia em alemão das telas que o modelo conseguiu inspecionar, ou um pequeno objeto de textos que ele inventa na hora. O próximo prompt volta a escrever texto novo em inglês, porque nada no projeto determina que o texto precisa passar por um catálogo.

O que o Base44 realmente gera?

Um projeto React padrão construído com Vite. A própria documentação de estrutura de projeto do Base44 mostra a organização que você encontra na aba Code e em um repositório conectado: src/pages guarda um arquivo por rota, então Home.jsx vira / e Settings.jsx vira /settings; src/components guarda as peças reutilizáveis com uma pasta ui/ de componentes prontos; src/api, src/hooks, src/lib e src/utils guardam o cliente do SDK, os hooks e os utilitários.

Dois diretórios importam mais que os outros para a localização. functions/ guarda a lógica do seu backend, um arquivo TypeScript por função, e esses arquivos formatam texto que os usuários leem: respostas de erro, e-mails, documentos gerados. entities/ guarda o seu modelo de dados como arquivos de esquema JSON, e, sob a sincronização bidirecional, as entidades são gerenciadas no Base44, e não no repositório.

Então um app Base44 tem duas superfícies de texto que os catálogos conseguem cobrir, o cliente React e as funções de backend, e uma que eles não cobrem, os dados dentro das entidades. Esse último ponto volta a aparecer mais adiante.

Como colocar um app Base44 em um repositório?

O Base44 já vem com a conexão pronta. No editor, abra o Dashboard, clique no ícone do GitHub e conecte. Você autoriza o app Base44 Builder na sua conta ou organização do GitHub, escolhe quais repositórios ele pode acessar e cria um novo repositório para o app. A partir daí, o repositório e o editor permanecem alinhados nas duas direções.

Duas regras da documentação do Base44 moldam tudo o que vem a seguir. Primeiro, a sincronização é automática: as mudanças que você faz no Base44, incluindo as que a IA faz a partir de um prompt, são commitadas no repositório sem uma etapa de push, e não existe um botão para enviar manualmente. Segundo, o caminho de volta é a branch main. Tudo que é mesclado em main passa a aparecer no app Base44, e master ou qualquer outro nome de branch padrão não é suportado. Depois de um merge, você clica em Publish para colocar a nova versão no ar para os usuários.

A sincronização bidirecional exige o plano Builder ou superior, e só o dono do app pode fazer a conexão inicial. Se a sua conta configurou a integração antiga de exportação unidirecional para o GitHub, o painel do GitHub tem um link para desconectá-la e reconectar com a sincronização bidirecional; o caminho unidirecional nunca traz nada de volta para o editor, exatamente a direção de que a localização precisa.

Para trabalhar localmente, clone o repositório, rode npm install, instale a CLI do Base44 e depois base44 login e base44 link para apontar o clone para o seu app. base44 dev roda o frontend contra um backend local. Fazer o merge da sua branch local em main é o que sincroniza tudo de volta.

O que significa "sem um painel de controle" para um app Base44?

Significa que os textos traduzidos nunca ficam num serviço hospedado que seu app precise chamar ou de onde você precise exportar algo. Eles vivem em src/locales/de.json, ao lado de src/pages/Home.jsx, versionados nos mesmos commits, revisados nos mesmos pull requests e implantados pelo mesmo clique em Publish.

As alternativas cobram um preço específico no contexto do Base44. Um widget de runtime que traduz a página no navegador deixa o código-fonte intocado, então o repositório continua dizendo que o app é em inglês, e cada visitante paga o atraso da tradução no carregamento. Uma ferramenta de tradução hospedada com editor próprio guarda a verdade fora do repositório, então a sincronização bidirecional que o Base44 construiu acaba sincronizando uma base de código que não contém os idiomas. As duas colocam um segundo sistema entre você e um texto que já vive em arquivos que são seus.

O formato nativo de repositório usa a sincronização exatamente como ela foi projetada. Catálogos são arquivos. Arquivos são commitados. Arquivos commitados chegam à main. A main chega ao editor. Esse é todo o pipeline, e nada nele é específico de localização.

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

Conecte o repositório em o app e rode a conversão uma única vez. A conversão encontra os textos literais nos seus componentes e funções de backend, dá chaves a eles, configura uma biblioteca de runtime como o i18next ou o Lingui caso o projeto ainda não tenha uma, e abre um pull request no seu repositório com o catálogo de origem e os primeiros idiomas de destino. Esse pull request é toda a entrega. Revise-o no GitHub como faria com qualquer outra mudança, faça o merge em main, e o Base44 vai espelhá-lo no editor.

A partir daí, os push jobs traduzem as novas unidades do catálogo. Quando você pede ao Base44 uma nova funcionalidade e a sincronização faz o commit, as novas chaves no catálogo de origem são traduzidas e entregues como um pull request. Basta dar merge, clicar em Publicar, e a funcionalidade fica no ar em todos os idiomas. Nada nos seus hábitos de prompting precisa mudar, e nada no seu app chama um serviço externo em tempo de execução.

A mesma abordagem funciona no Lovable, Bolt, v0 e Replit, e a mecânica é idêntica porque os quatro entregam um projeto de front-end convencional. O tutorial do Lovable traz mais detalhes sobre a estrutura do catálogo, o guia do Bolt cobre a etapa de exportação para um builder sem sincronização nativa, e o guia do Vite para o stack clássico do Lovable é o que mais se aproxima da saída em React e Vite do Base44 no nível do código. Se você está comparando builders em vez de já ter escolhido um, a visão geral para vibe coders é o melhor ponto de partida.

Quais strings ficam nas funções de backend?

Qualquer coisa que um usuário leia e que seja gerada no servidor. Um erro de validação retornado por uma função, o assunto de um e-mail enviado por ela, o corpo de um PDF que ela gera, o texto de uma notificação. Essas strings nunca aparecem como JSX, então um catálogo de front-end não as contém e um widget em tempo de execução não consegue enxergá-las.

O padrão é o mesmo do lado do cliente. Leia o locale solicitado na requisição recebida, carregue o catálogo daquele locale no lado da função, e compartilhe o namespace de chaves com o cliente, para que uma mensagem signifique a mesma coisa na interface e em uma resposta de API. Como o diretório functions/ está no repositório, a conversão trata esses arquivos como qualquer outro código-fonte, e os catálogos ficam ao lado deles.

E o conteúdo dentro das entities?

Este é o limite específico do Base44. As entities são o seu modelo de dados, gerenciado dentro do Base44, e, na sincronização bidirecional, elas não fazem parte do repositório. Um registro como o nome de um produto, a descrição de um serviço ou um artigo de ajuda é dado, não texto de interface, e nenhum catálogo jamais o conterá.

Conteúdo em forma de dados precisa de uma dimensão de idioma na própria entity: um campo de locale, ou um campo por idioma, além de queries que leiam o locale do visitante. A configuração é a mesma que descrevemos para conteúdo de banco de dados em apps Lovable, e é uma decisão de modelo de dados que você toma no editor de entities do Base44, não uma decisão de ferramenta de localização. Planeje isso cedo, porque adaptar um campo de idioma em uma entity com registros já existentes dá muito mais trabalho do que adicioná-lo a uma nova.

E se você estivesse no Lovalingo?

O Lovalingo encerrou as atividades no fim de agosto de 2026, e seus casos de uso publicados incluíam o Base44 junto com Lovable, v0 e Bolt. Quem localizou um app Base44 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.

O que verificar antes de adicionar um segundo idioma?

Confirme que a sincronização é bidirecional, e não a exportação legada. Abra o painel do GitHub no Base44 e verifique se ele indica um repositório conectado; se aparecer o link "Procurando a configuração antiga?", você está no caminho unidirecional e precisa reconectar.

Confirme que sua branch padrão é main. O Base44 só espelha essa branch de volta, então um pull request feito em qualquer outra nunca chega ao editor.

Procure por uma biblioteca de runtime. Se em algum momento você pediu ao Base44 suporte a idiomas, ele pode ter adicionado o i18next ou um contexto feito à mão; a conversão mantém o que já existe e o alimenta.

Decida onde o conteúdo das entities vai obter seu campo de idioma antes de adicionar registros em um segundo idioma. Os catálogos não vão fazer essa parte por você.

Verifique o seu roteamento. As páginas do Base44 são baseadas em arquivos, então um prefixo de locale na URL é uma decisão de roteamento que você toma uma única vez, e ela define como os mecanismos de busca enxergam cada idioma. O guia de seletor de idioma e hreflang cobre as opções, e elas se aplicam diretamente aqui.

Por onde começar

Ative a sincronização bidirecional do GitHub no Base44, se ainda não estiver ativa, confirme que a branch é main, e conecte o repositório em o app. O primeiro pull request converte a base de código. Depois disso, é só merge, um clique em Publicar, e os idiomas que você pediu. A página de integração do Lovable descreve o mesmo fluxo para um builder com rota integrada ao editor, e boa parte do que está lá se aplica ao Base44 sem alterações.