O que acontece quando um agente de IA internacionaliza um monorepo real?

Ele extraiu 28 strings candidatas de UI, reescreveu 41 entradas de tradução em vários arquivos, configurou middleware e roteamento, e gerou arquivos de locale para 5 idiomas de destino. Setup, conversão e tradução levaram cerca de 90 minutos, de ponta a ponta. globalize.now é uma infraestrutura de localização baseada em IA, e nós a rodamos em um monorepo de produção para ver o que realmente aconteceria. Sem demo preparada. Sem rede de segurança. Só uma base de código real, com toda a sua complexidade.

A base de código pertencia a um veterano da indústria de localização, que passou mais de uma década como arquiteto em uma das principais plataformas de gestão de tradução.

O que havia no monorepo?

Isso não era um projeto de tutorial. O monorepo continha uma aplicação web em Next.js, um app Android, servidores MCP e uma documentação renderizada por um serviço de terceiros. O desenvolvedor usa Claude Code diariamente, constrói tudo com ferramentas de IA de ponta a ponta, e havia montado toda essa stack em três meses.

O alvo era o frontend em Next.js. O app Android, os servidores MCP, o site de documentação construído no Mintlify — nada disso deveria ser tocado. A questão era saber se um agente de IA conseguiria identificar isso sozinho, sem receber instruções explícitas.

E conseguiu. O agente escaneou o repositório inteiro e focou na aplicação Next.js. Na prática, não foi preciso nenhuma delimitação manual, embora o desenvolvedor tenha comentado que gostaria de ter a opção de dizer “converta só /apps/web” por questão de segurança. É um ponto justo e algo que vale a pena adicionar. Mas isso não travou a conversão.

Como funcionou a configuração?

O desenvolvedor escolheu o modo guiado para entender o processo. A configuração envolveu cinco decisões: gerenciador de pacotes (NPM, apesar de também existir um lockfile legado do PNPM), formato de catálogo (PO/GetText, recomendado por suportar comentários), modo de configuração (guiado), idioma de origem (inglês) e idiomas de destino (espanhol, italiano, húngaro, tcheco e eslovaco).

Uma observação que vale destacar: a pergunta sobre o formato de catálogo gerou hesitação até em alguém com profundo conhecimento em localização. A reação dele foi direta. Ele não achou que essa escolha fosse relevante o suficiente para ser perguntada ao usuário. Automatize isso.

A estratégia de roteamento foi baseada em path. Sem roteamento baseado em domínio, já que o desenvolvedor não possuía domínios extras. O app usa autenticação via OAuth, então os fluxos de login permaneceram em inglês, por design. O agente lidou com isso corretamente.

O que a etapa de conversão faz, na prática?

Essa é a parte que importa. O agente identificou 28 strings candidatas de UI em o app Next.js e processou 41 entradas de tradução. Ele reorganizou arquivos, atualizou o middleware, modificou imports de componentes e gerou arquivos de locale em PO para os 5 idiomas de destino.

A etapa de conversão, sozinha, levou cerca de 30 minutos. Somando o setup e a configuração antes dela, e a conexão das traduções que o desenvolvedor concluiu de forma independente depois, o total de ponta a ponta ficou mais próximo de 90 minutos. Isso não é instantâneo. Para efeito de comparação, um app simples com poucas páginas completa o fluxo inteiro em menos de 15 minutos. Um app complexo, com dezenas de superfícies traduzíveis, leva mais tempo. O tempo escala com o número de strings, não com o tamanho do repositório.

O desenvolvedor acompanhou a etapa de conversão rodar e disse o seguinte: a extração de strings e a reescrita de código são o trabalho pesado. É isso que os desenvolvedores mais temem. Na empresa anterior dele, uma das principais TMS do mercado, os arquivos de tradução no repositório eram só a ponta do iceberg. O trabalho de preparação e internacionalização era a verdadeira dor de cabeça. E foi exatamente essa parte que o agente de IA resolveu.

Isso bate com o que ouvimos de todo desenvolvedor que já passou por i18n manualmente. Ninguém reclama das traduções em si. As reclamações são sobre ter que mexer em 40 arquivos para envolver strings em chamadas de t(), gerar chaves que façam sentido, reestruturar imports e configurar middleware. É exatamente esse o trabalho que o globalize.now automatiza.

Funcionou de ponta a ponta, de fato?

Sim. Depois que a sessão ao vivo terminou, o desenvolvedor concluiu as etapas restantes de forma independente. Ele publicou o branch do globalize.now no Git, conectou o app à plataforma web, configurou o monitoramento para o branch do globalize.now e confirmou que os arquivos foram enviados e traduzidos corretamente.

A avaliação dele sobre a qualidade da tradução em tcheco: quase perfeita. Isso vindo de alguém que passou a carreira avaliando profissionalmente resultados de localização. Não é um “joinha” genérico. É um especialista do setor confirmando qualidade viável para produção em um par de idiomas nada trivial.

Ele apontou dois problemas no app web depois de concluir o fluxo de forma independente. Primeiro, uma nova varredura do repositório mostrou “nenhum arquivo de i18n detectado”, mesmo com o job de tradução realmente rodando em segundo plano. Um estado de UI enganoso, não uma falha real. Segundo, o job de tradução começou sem um consentimento explícito. Qualquer ação que consome créditos deveria exigir confirmação. Os dois são problemas de UX válidos, e já estão sendo corrigidos.

O que deu errado?

Algumas coisas quebraram. Foi um teste de verdade, então vamos ser honestos sobre isso.

O comando de instalação (npx skills add globalize-now/globalize-skills) falhou no PowerShell do Windows. Era a primeira vez que a ferramenta era testada no Windows. As skills tiveram que ser enviadas como um arquivo zip via Swiss Transfer, depois que o Google bloqueou o anexo do e-mail. Atrito total no setup: cerca de 15 minutos antes de o fluxo de verdade começar.

Um conflito entre ES modules e CommonJS apareceu no meio da conversão. O projeto usa CommonJS, e a saída do agente assumiu ES modules em um ponto específico. Não chegou a travar o processo, mas é algo que deveria ser detectado durante o setup e tratado de forma proativa.

No fim da sessão, ao conectar o repositório do GitHub no aplicativo web do globalize.now, a página ficou em branco. O desenvolvedor estava usando o Opera. Nenhuma tela de login, nenhum erro, nenhum conteúdo. A sessão terminou antes que o problema fosse resolvido.

Três bugs. Todos reais. Todos corrigidos ou em andamento.

Por que a extração de strings é o verdadeiro gargalo?

A maior parte do conteúdo sobre i18n foca na qualidade da tradução, na configuração de frameworks ou em comparações de recursos de TMS. Isso ignora onde os desenvolvedores realmente perdem tempo.

Adicionar internacionalização a uma base de código existente significa vasculhar cada componente em busca de strings fixas no código, decidir quais delas são traduzíveis, gerar chaves de tradução com significado, envolver cada string na chamada t() ou <Trans> apropriada, atualizar importações em toda a árvore de arquivos, criar os arquivos de idioma iniciais e configurar o middleware de roteamento. Em um monorepo, some a isso a complexidade de descobrir quais partes da base de código realmente precisam de i18n.

Isso é tedioso, sujeito a erros e é exatamente o tipo de trabalho para o qual agentes de IA são bons. O desenvolvedor que acompanhou tudo isso resumiu bem: do ponto de vista dele, essa é a parte pesada. E é um baita alívio. Os vibe coders que constroem com ferramentas de IA agora podem pular de vez a pior parte de internacionalizar um produto.

O que aprendemos sobre a delimitação de escopo em monorepos?

O agente lidou com a delimitação de escopo do monorepo de forma implícita. Ele se concentrou no aplicativo web em Next.js e ignorou o código Android, os servidores MCP e a documentação em Mintlify sem que ninguém precisasse dizer nada. Esse é o comportamento correto na maioria dos casos.

Mas escopo implícito não é a mesma coisa que escopo explícito. O desenvolvedor queria a possibilidade de dizer "converta apenas meu aplicativo Next.js" como uma etapa de configuração. Em um monorepo com múltiplos frontends web — digamos, um app voltado ao cliente e um painel administrativo —, você vai querer controle preciso sobre qual frontend recebe internacionalização primeiro.

Essa é uma lacuna do produto que estamos fechando. Por enquanto, o agente acerta na prática. Mas o escopo explícito deveria ser uma etapa de configuração, especialmente quando a conversão envolve dezenas de arquivos.

Como isso se compara à configuração manual de i18n?

A configuração manual de i18n em uma base de código dessa complexidade leva dias. Não porque alguma etapa isolada seja difícil, mas porque são dezenas de etapas e cada uma exige atenção. Esqueça uma string, e você lança uma página meio traduzida. Erre o nome de uma chave, e você cria entradas duplicadas que vão te assombrar por meses. Esqueça de atualizar o middleware, e o roteamento de idiomas quebra silenciosamente.

O agente de IA concluiu um trabalho equivalente em cerca de 90 minutos, do início ao fim. O desenvolvedor, alguém que já viu milhares de implementações de i18n profissionalmente, chamou o resultado de elegante.

Para desenvolvedores que constroem com ferramentas de IA, isso muda a conta na hora de decidir quando adicionar novos idiomas. Se configurar i18n leva uma semana, você adia isso até comprovar o product-market fit. Se leva 90 minutos, você pode lançar multilíngue desde o primeiro dia.

O globalize.now resolve isso. Conecte seu repositório e a conversão roda uma única vez, dentro do aplicativo; as skills de npx skills add globalize-now/globalize-skills cuidam do que vem depois, direto no seu editor. Veja como funciona em globalize.now.