A localização está migrando para o início do fluxo porque a premissa central do pipeline antigo se quebrou: a de que o código mudaria lentamente o suficiente para exportar um catálogo de strings estável, traduzi-lo em outro lugar e importar os resultados antes do próximo lançamento. Os agentes de codificação com IA acabaram com essa premissa. O globalize.now é uma infraestrutura de localização com IA construída para a nova posição: localização que roda dentro do fluxo de desenvolvimento e é entregue como um pull request. Este ensaio é sobre por que posição, e não qualidade de tradução, é o que realmente mudou.
O que significa mover a localização para o início do fluxo?
Significa que a unidade de trabalho de localização deixa de ser um catálogo de strings e passa a ser um commit. No modelo antigo, a localização começa depois que o código está pronto. No modelo de início de fluxo, ela acontece onde o código está, no momento em que o código muda, e seu resultado é código: um PR localizado que você compara, revisa e mescla.
Os dois pipelines funcionam assim.
Traditional: build → internationalize → export → translate → review → import → ship
Upstream: code → push → localized PR → merge → ship
O primeiro pipeline tem sete etapas e sai do repositório duas vezes. O segundo tem cinco, e nenhuma delas sai do repositório. Essa diferença estrutural, e não qualquer recurso isolado, é o assunto deste ensaio.
Como funciona o pipeline tradicional de localização?
Funciona como um ciclo de ida e volta, e cada seta nesse fluxo é uma fila de espera. Você constrói o recurso. Você o internacionaliza, extraindo os textos em chaves — supondo que sua equipe ou seu agente de IA tenha gerado um código estruturado desde o início. Você exporta o catálogo para uma plataforma de tradução. Tradutores ou um mecanismo de tradução automática o processam. Alguém revisa. Você importa os resultados, resolve os conflitos que se acumularam enquanto o catálogo estava fora, e coloca no ar.
Cada repasse existe porque o trabalho acontece em um lugar diferente, sob responsabilidade de pessoas diferentes, em um ritmo diferente. Isso fazia sentido quando os lançamentos eram trimestrais e os textos mudavam em lotes. A dependência oculta desse pipeline é a estabilidade: o catálogo precisa ficar parado tempo suficiente para completar o ciclo de ida e volta.
Só que ele não fica mais parado. No relatório DORA 2025 State of AI-Assisted Software Development, 90% dos profissionais de software relataram usar ferramentas de IA no trabalho, e o estudo de impacto da DX do quarto trimestre de 2025 mediu que o código escrito por IA representa 22% do código mesclado na empresa mediana analisada. Código que antes mudava semanalmente agora muda entre o almoço e a reunião diária.
Como fica a localização dentro do ciclo de desenvolvimento?
Como qualquer outra verificação automatizada que roda a cada push. Você converte a base de código uma única vez: os textos são extraídos, as chaves geradas, os arquivos de idioma criados, e a integração em tempo de execução colocada no lugar. Depois disso, a sincronização roda a cada push. Quando um commit introduz textos novos, as traduções voltam como um pull request na sua branch, no seu repositório, estruturado do mesmo jeito que o resto da aplicação.
Isso não é um número hipotético. Em uma execução que registramos em agosto de 2026 num repositório de demonstração, um commit enviado voltou como um PR localizado cobrindo 30 unidades de tradução em alemão, francês e espanhol em 49 segundos. Menos de um minuto, do commit ao PR pronto para revisão, sem nenhuma intervenção humana até a revisão. Compare isso com qualquer pipeline que inclua a palavra "exportar".
A conversão única, para deixar claro, não é instantânea. Em aplicações reais, ela leva cerca de 30 minutos, porque está reestruturando código: extraindo textos, gerando chaves, integrando um runtime. Essa é a porta de entrada. O ciclo que roda a cada push depois disso é o produto em si.
A característica importante desse ciclo não é a velocidade. É o fato de que nada sai do repositório. Não existe um catálogo parado em uma plataforma externa se distanciando aos poucos da branch principal. A execução em monorepo que publicamos anteriormente mostrou a conversão única em escala; o ciclo é o que mantém o resultado vivo depois disso. Merge ou close, os mesmos dois verbos que regem qualquer outra mudança. Se você já trabalha desse jeito, a documentação para desenvolvedores mostra como configurar.
Por que os agentes de codificação de IA forçam essa mudança?
Porque eles deslocaram o gargalo. A restrição em localização costumava ser a capacidade de tradução: a velocidade com que um fornecedor ou um mecanismo conseguia processar um catálogo bem estruturado. Os agentes geram código muito além dessa restrição e criaram uma nova, anterior a ela. O recurso escasso agora é a sanidade arquitetural depois da geração: manter as chaves consistentes, os arquivos de idioma completos e a estrutura intacta enquanto um agente adiciona interface à base de código diariamente.
Um agente instruído a criar uma página de checkout produz uma página de checkout funcional com os textos fixos diretamente no JSX. Detalhamos essa anatomia em A IA quebrou a localização: um projeto React analisado continha 1.284 textos de interface espalhados em 312 arquivos, sem nenhuma estrutura de i18n. O catálogo que o pipeline tradicional quer exportar simplesmente não existe nessa base de código. E amanhã a base de código vai parecer diferente de novo, porque o agente continua lançando código.
Um pipeline posterior encontra essa realidade permanentemente atrasado. O que quer que ele tenha exportado já está desatualizado no momento da importação. A única posição a partir da qual a localização consegue acompanhar código gerado por IA é dentro do próprio ciclo que o gera, e isso vale tanto para código vindo do Cursor, do Claude Code ou do Lovable.
A tradução por IA não é a mesma coisa?
Não, e é aí que a conversa do mercado se perde. A Lokalise se descreve como uma plataforma de localização com IA; a Phrase oferece o Language AI para tradução automática em escala. Ambas são capacidades reais. Ambas tornam uma única seta do pipeline antigo mais rápida: a etapa de tradução. O catálogo continua sendo exportado, continua vivendo numa plataforma externa, continua voltando por meio de uma importação.
Uma seta mais rápida em um ciclo de sete etapas é uma otimização. Eliminar o ciclo é um produto completamente diferente. Essa é a distinção real de camadas: plataformas construídas em torno dos fluxos de trabalho de tradutores ocupam a camada de gestão, e o globalize.now ocupa a camada de infraestrutura logo abaixo, gerando as chaves e os arquivos de idioma a partir do próprio código, dentro do repositório. "Com IA" descreve as duas. Não diferencia nenhuma. A posição, sim.
O que ainda continua sendo trabalho posterior?
O julgamento humano em conteúdos de alto risco. Textos jurídicos, alegações regulamentadas, a voz da marca em um mercado que você leva muito a sério: esses casos merecem um tradutor profissional e uma etapa de revisão, e equipes com essa necessidade vão continuar usando ferramentas construídas em torno dos fluxos de trabalho de tradutores. Nada na localização feita na origem impede isso; o PR localizado é uma superfície revisável, e uma pessoa pode aplicar qualquer padrão de qualidade antes do merge.
O que acaba é a era em que toda equipe precisava adotar uma plataforma voltada a fluxos de trabalho de tradutores só para lançar um segundo idioma. Um desenvolvedor solo com um produto construído por IA não tem tradutores para gerenciar. Ele tem commits. As ferramentas deveriam encontrá-lo ali.
O ciclo é o produto
Se o seu código é lançado por meio de pull requests, suas traduções também deveriam ser. O globalize.now converte a base de código uma única vez e depois a mantém localizada a cada push: PR entra, PR é mesclado, está no ar.
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