Por que os arquivos de tradução ficam sempre fora de sincronia?

Os arquivos de tradução ficam fora de sincronia porque dois sistemas são donos dos mesmos dados e nenhum deles prevalece. Seu repositório muda quando um desenvolvedor faz merge. Seus arquivos de tradução mudam quando alguém se lembra de atualizá-los. São relógios diferentes, e o intervalo entre eles é onde vivem as chaves ausentes, as chaves órfãs e as strings desatualizadas. O globalize.now é uma infraestrutura de localização com IA que fecha essa lacuna gerando as chaves e os arquivos de locale no mesmo lugar em que o código é escrito, para que não exista um segundo relógio para ficar atrasado.

O que realmente causa a dessincronização dos arquivos de locale?

Um arquivo é de fato escrito, e os demais apenas são mantidos — e isso não é o mesmo trabalho.

Um desenvolvedor construindo uma funcionalidade edita en.json porque é nesse arquivo que a string vai entrar. Os outros locales são problema de outra pessoa, em outro cronograma. Um desenvolvedor que escreveu sobre esse padrão no DEV descreveu as duas formas de falha: chaves são adicionadas ao arquivo em inglês e esquecidas nos outros, então parte do app volta silenciosamente para o inglês, e chaves são removidas em um locale mas sobrevivem em outro, então entradas mortas se acumulam. O mecanismo de descoberta em ambos os casos é uma reclamação de cliente, semanas depois.

Nenhum dos dois casos é um problema de tradução. Nada foi mal traduzido. As strings simplesmente nunca foram roteadas para lugar nenhum.

Esse é o modo de falha que sobrevive a qualquer atualização de ferramentas, porque as ferramentas ficam a jusante do ponto em que a string foi criada. Se a string nunca entra no pipeline, um pipeline melhor não ajuda em nada. A mesma causa raiz aparece mais cedo na cadeia quando um agente de código escreve strings que nunca foram sequer transformadas em chaves.

Por que os arquivos de locale geram tantos conflitos de merge?

Porque são dados gerados sendo editados manualmente, em um formato feito para máquinas escreverem.

Um arquivo de locale é um mapa simples de chaves para strings. Duas branches que adicionam uma funcionalidade cada uma acrescentam entradas a esse mapa, geralmente perto do mesmo lugar, geralmente na mesma vizinhança alfabética. O Git vê duas edições em linhas adjacentes, num arquivo sem nenhuma estrutura semântica que ele compreenda, e pede para um humano resolver.

A pessoa que resolve o conflito é um desenvolvedor que não lê o idioma de destino. A jogada segura é manter os dois lados, e é assim que surgem chaves duplicadas. A jogada rápida é manter só um, e é assim que traduções somem sem ninguém perceber.

Ninguém resolve conflitos de lockfile manualmente. Regeneram o arquivo. Os arquivos de idioma merecem o mesmo tratamento no momento em que deixam de ser documentos escritos por pessoas.

Quanto tempo uma tradução fica velha enquanto espera na revisão?

Velha o suficiente para deixar de descrever o produto — e isso é mensurável publicamente.

Um relatório de campo publicado no DevOps.com acompanhou cinco pull requests reais de localização em projetos open-source. O mais revelador é o PR #8377 do Kilo Code: as checagens automatizadas passaram limpas, a revisão do mantenedor chegou depois, e o repositório já tinha evoluído por baixo dela. O PR foi fechado com um convite para reenviar contra a arquitetura atual. O mesmo relatório registra uma issue do OpenClaw em que voluntários ofereceram traduções em espanhol, japonês, português, coreano, chinês e vietnamita, e os mantenedores disseram não ter como absorvê-las.

Leia isso como relatórios de latência, não de qualidade. As traduções estavam corretas quando escritas. A interface mudou enquanto elas esperavam na fila.

Esse é o custo que ninguém calcula ao comparar ferramentas de localização. Todo mundo mede a tradução. Quase ninguém mede quanto tempo uma string passa em trânsito, nem o que a interface fez enquanto ela estava fora.

Quanto custa de fato essa ida e volta?

Mais em coordenação do que em tradução — por isso a fatura nunca explica a dor.

O custo visível é por palavra, por chave ou por assento, e aparece na conta uma vez por mês. O custo invisível é um desenvolvedor perguntando “qual arquivo eu edito”, um segundo desenvolvedor resolvendo um conflito num idioma que não lê, um terceiro percebendo que o build em alemão está faltando onze chaves, e o autor original da funcionalidade sendo questionado sobre uma string que escreveu cinco semanas atrás.

Nada disso aparece numa comparação de preços. Tudo isso é pago em tempo de desenvolvedor, a preço de desenvolvedor, a cada sprint. Uma ferramenta com preço de etiqueta baixo que custa dois engenheiros um dia por semana não é barata.

É a ida e volta que gera esse custo. Mover arquivos entre o lugar onde as strings são criadas e o lugar onde são traduzidas é a etapa cara, e ela continua cara não importa de quem você compre. É também por isso que a localização continua subindo rio acima no ciclo de desenvolvimento.

O que muda quando as chaves são geradas onde o código é escrito?

O segundo relógio desaparece, e não sobra de onde vir a defasagem.

A sequência deixa de ser: o desenvolvedor escreve uma string fixa no código, alguém a encontra depois, alguém a transforma em chave, alguém envia o arquivo para fora, alguém traduz, alguém traz de volta. Passa a ser: a string já nasce como chave com um valor, no mesmo commit da funcionalidade, e a tradução segue a partir daí.

Com o globalize.now isso começa com uma conversão única. Você conecta seu repositório no app e as strings fixas existentes são extraídas em chaves e arquivos de idioma numa única passada. Depois disso, as agent skills fazem com que agentes de código como Cursor e Claude Code já escrevam strings com chave desde o início, em vez de fixá-las no código, e os jobs de push traduzem as novas unidades do catálogo assim que surgem.

A palavra importante é uma vez. A conversão é a parte difícil e acontece uma única vez. O que vem depois é a parte que antes era manual, rodando no mesmo ritmo do código — e esse é justamente o objetivo de colocá-la dentro do fluxo de trabalho do desenvolvedor, em vez de ao lado dele.

As bibliotecas de runtime não são afetadas. O i18next e o next-intl continuam lendo os arquivos de idioma exatamente como antes. Nada muda em como as traduções são servidas. O que muda é quem escreve os arquivos.

Como diferenciar defasagem de um problema real de tradução?

Pergunte se algum tradutor já viu aquela string.

Se o arquivo em alemão está sem uma chave, nenhum tradutor falhou. A string nunca chegou a um. Isso é uma falha de roteamento, e adicionar etapas de revisão só piora as coisas, acrescentando tempo de fila a um processo cujo problema já é latência.

Se o arquivo em alemão tem a chave e a redação está errada para o contexto, aí sim é um problema real de tradução, e merece uma pessoa que fale alemão e consiga ver onde a string aparece. Esses casos valem o tempo investido.

A maioria das equipes tem muito mais do primeiro tipo do que do segundo e trata os dois como o mesmo problema — por isso a localização parece não ter fim. Separe-os e a carga de trabalho cai, porque a metade de roteamento deixa de ser trabalho humano por completo. Essa distinção importa ainda mais quanto menor a equipe, e é por isso que aparece com mais força para desenvolvedores solo e equipes pequenas lançando rápido.

Um teste útil: conte quantos dos seus últimos dez bugs de localização eram palavras erradas versus palavras faltando. Se a maioria era falta, você não tem um problema de tradução. Você tem um problema de encanamento, e encanamento é automatizável de um jeito que julgamento não é. A mesma lógica se aplica quando você está calculando quanto a localização deveria realmente custar.

A defasagem de arquivos de idioma é um problema de roteamento disfarçado de problema de tradução. Conecte o repositório uma vez e o roteamento deixa de ser tarefa sua.