Copy drift: o que é, o que causa e como evitar

Drift de copy é quando um texto visível ao usuário se afasta da sua versão aprovada em diferentes telas e ao longo do tempo, sem que exista uma única fonte de verdade da qual esse texto possa se afastar. A string não está faltando nem está quebrada — a redação em si mudou, ninguém decidiu que isso deveria acontecer, e agora a página de marketing, a landing page e o produto dizem coisas ligeiramente diferentes sobre a mesma funcionalidade. O globalize.now é um sistema de gerenciamento de copy nativo em código com localização embutida, e o drift é justamente a falha específica que ele existe para evitar.

O que é copy drift?

Drift de copy é quando um texto visível ao usuário se afasta da sua versão aprovada em diferentes telas e ao longo do tempo, sem que exista uma única fonte de verdade da qual esse texto possa se afastar.

Duas partes dessa definição fazem o trabalho pesado. Afastar-se da versão aprovada significa que, em algum momento, alguém concordou sobre o que aquela string deveria dizer. Nenhuma fonte única de verdade significa que não existe nenhum artefato que ainda guarde esse acordo — logo, não há nada de que se afastar de forma verificável, e é por isso que ninguém consegue apontar o momento exato em que o drift começou.

Drift é normal, não é exceção. Qualquer produto com mais de uma superfície e mais de uma pessoa editando conteúdo vai sofrer drift, a menos que algo estrutural impeça isso.

O que copy drift não é

Três falhas costumam ser jogadas no mesmo saco, mas cada uma exige uma correção diferente. Confundi-las faz os times perseguirem o problema errado.

Uma string hardcoded é um texto escrito diretamente em um componente em vez de estar em um catálogo. Ela é invisível para as suas ferramentas e para a tradução — mas a redação em si pode estar perfeitamente correta. Esse é um problema diferente, que já abordamos em por que ferramentas de codificação com IA continuam criando strings hardcoded.

Arquivos de tradução dessincronizados são catálogos que existem, mas perderam a sincronia entre si. A fonte está correta; as cópias derivadas é que estão desatualizadas.

Copy drift não é nenhum dos dois casos anteriores. A string pode estar corretamente indexada por chave, os arquivos podem estar sincronizados, e mesmo assim o produto pode dizer “Iniciar teste gratuito” em um lugar, “Experimente grátis” em outro, e “Começar” no botão que efetivamente executa a ação.

É possível ter os três problemas ao mesmo tempo. Um não resolve o outro.

O que causa o copy drift?

Três mecanismos, em ordem aproximada de quanto estrago cada um causa.

Superfícies pertencentes a pessoas diferentes, editadas em ferramentas diferentes. O texto de marketing vive em um CMS. A landing page é atualizada mais rápido porque está em constante experimentação. As strings do produto vivem em componentes. Cada superfície pode ser internamente consistente enquanto o produto como um todo não é, e nenhuma pessoa sozinha enxerga as três de uma só vez.

Pequenas edições que ninguém classifica como edições de copy. Alguém encurta um rótulo para caber em um breakpoint mobile. Alguém ajusta a capitalização de um título para manter consistência com uma tela vizinha. Cada mudança é defensável isoladamente. Nenhuma passa por algo parecido com uma revisão de copy, porque, para a ferramenta, é apenas uma string literal em um atributo JSX.

Agentes de codificação. Um agente encarregado de adicionar um estado de carregamento pode acabar reescrevendo um rótulo só por estar mexendo no arquivo — ajeitar uma string parece exatamente igual a ajeitar código. A resposta que a comunidade tem dado até agora é um arquivo de regras: AGENTS.md, .cursorrules, um bloco de política de copy de UI no prompt. Isso ajuda e vale a pena ter. Mas uma convenção não é uma verificação. Ela reduz a frequência com que seu texto é reescrito; não avisa quando isso acontece mesmo assim.

Por que nada detecta o copy drift?

Porque nada quebra.

Um rótulo alterado compila normalmente. Ele renderiza normalmente. O verificador de tipos vê uma string válida e o linter vê uma sintaxe válida. Se um teste de snapshot falha, a resposta padrão é atualizar o snapshot, o que registra o drift em vez de sinalizá-lo. Nenhum build fica vermelho, nenhum alerta dispara, nenhum painel fica amarelo.

O drift só é visível para algo que saiba qual era a redação aprovada. A maioria das cadeias de ferramentas não mantém esse registro, então o primeiro a detectar geralmente é uma pessoa — uma resposta de suporte que cita palavras diferentes das que aparecem na interface, um cliente perguntando se “Workspace” e “Project” são a mesma coisa, ou um tradutor perguntando qual das três variações em inglês ele deve traduzir.

Quanto o copy drift realmente custa?

Sinceramente: ninguém mediu isso, nós inclusive, e não vamos inventar um número.

Vale dizer isso claramente, porque essa categoria está cheia de números que não resistem a uma checagem na fonte — dados de pesquisas sobre branding e receita, custos de suporte por chamado, porcentagens de chamados atribuídas a documentação inconsistente. Já descartamos vários desses números internamente em vez de repeti-los. A medição que de fato responderia a essa pergunta — quanto drift existe em bases de código reais, e o que isso causa lá na frente — ainda não foi feita por ninguém.

O que dá para descrever sem usar um número é o mecanismo, e esse mecanismo é cumulativo:

• É invisível até se tornar caro. Nada revela o drift enquanto ele ainda é barato de corrigir. Ele aparece quando alguém precisa que as palavras sejam iguais, geralmente sob pressão de prazo.
• Cada superfície é uma correção separada. Mudar uma frase significa encontrar todos os lugares onde ela foi reformulada, e não existe uma lista desses lugares.
• A localização multiplica o problema. Esse é o ponto mais crítico. Envie três formas diferentes de dizer a mesma coisa para tradução e você recebe três traduções, em cada idioma. Uma inconsistência que antes ficava contida no inglês agora se replica em cada um dos seus idiomas, e para um falante nativo isso soa como três recursos diferentes.

Esse último ponto é o motivo pelo qual consistência de copy e localização não são projetos separados. Se você não consegue dizer qual redação é a aprovada, não consegue traduzir nenhuma delas corretamente — a fonte já era ambígua antes mesmo de chegar ao tradutor. A arquitetura que resolve os dois problemas é a mesma, e é o que detalhamos em copy de produto nativa em código.

Como evitar o copy drift?

Dê à redação um único lar, e torne as mudanças nela revisáveis. O resto é consequência.

Um único catálogo. Toda string visível ao usuário vive em um único lugar, em vez de espalhada em linha pelos componentes. Agora existe algo com o que ser consistente.

Chaves, não literais. Os componentes referenciam uma chave em vez de repetir as palavras. A mesma redação não pode existir em dois lugares e se afastar silenciosamente, porque ela só existe uma vez.

Mudanças aparecem no diff. Uma alteração de copy aparece na revisão do mesmo jeito que qualquer outra mudança. É essa etapa que faz o trabalho de verdade: a consistência deixa de depender de alguém se lembrar do guia de estilo e passa a ser visível justamente no momento em que alguém está, de fato, prestando atenção.

As superfícies fora do produto — marketing, landing pages — são a metade mais difícil, e vamos ser diretos sobre onde isso está: padronizar o texto entre marketing, landing pages e produto como um único sistema é o que estamos construindo no globalize.now, não algo que você já pode ativar hoje. O mecanismo é o mesmo descrito acima, só que estendido para além dos limites do aplicativo: se toda superfície referencia a string aprovada por chave, em vez de repeti-la, mudar uma frase se torna uma única decisão em vez de três.

Times que lançam produtos com ferramentas de codificação com IA esbarram nisso primeiro, e é por isso que escrevemos sobre o tema tanto para desenvolvedores quanto para quem está construindo com ferramentas de IA.

Um guia de estilo resolve o copy drift?

Não — um guia de estilo e uma fonte de verdade resolvem problemas diferentes, e os times costumam comprar o primeiro esperando obter o segundo.

Um guia de estilo descreve como um bom texto deve ser: tom, capitalização, terminologia, quando dizer “excluir” e quando dizer “remover”. Ele é genuinamente útil e todo time deveria ter um. O que ele não consegue fazer é avisar que uma string mudou. Ele não guarda nenhum registro da redação anterior nem tem qualquer gancho no momento da mudança, então só pode ser aplicado por alguém que, por acaso, esteja olhando para a tela certa naquele momento.

Drift é um problema de estado, não de gosto. A correção precisa morar onde o estado mora.

O drift começa no momento em que as mesmas palavras passam a existir em dois lugares. O globalize.now centraliza essas palavras em uma única fonte, dentro do repositório que você conecta, e deriva cada idioma a partir dessa única cópia.