Copy de produto nativa em código: como o texto de UI se mantém consistente e pronto para localização em uma base de código

Copy de produto nativa em código significa que as strings visíveis ao usuário do seu produto vivem no repositório como a única fonte da verdade, em vez de ficarem em um arquivo de design que alguém precisa manter sincronizado manualmente. O globalize.now é um sistema de gerenciamento de copy nativo em código com localização já embutida: a copy tem fonte única na base de código, e localizá-la é parte da mesma operação, em vez de uma entrega separada.

Isso importa mais hoje do que importava há três anos, porque a copy deixou de mudar apenas quando um redator faz uma alteração.

O que é copy de produto nativa em código?

Copy de produto nativa em código é uma arquitetura, não um processo de escrita: o texto aprovado e o texto publicado são o mesmo artefato, mantido no repositório, e toda alteração nele chega como um diff.

A diferença fica mais clara quando se observa o que cada abordagem consegue enxergar. Um produto que trata um workspace externo como fonte de verdade mantém o texto fora do código e depende de alguém empurrá-lo para dentro, ou trazê-lo de volta, sempre que um dos lados muda. É um bom lugar para decidir o que um botão deve dizer. Mas ele é estruturalmente incapaz de perceber que o botão agora diz outra coisa, porque o evento que mudou isso foi um commit, e o workspace nunca viu o commit.

Um sistema nativo em código inverte essa lógica. A unidade de trabalho é o diff, e a pergunta que ele consegue responder é justamente a que costuma colocar times em apuros: a string acabou de mudar — era para ter mudado?

Nada disso é um argumento sobre onde a escrita acontece. Redatores podem rascunhar em qualquer lugar. É um argumento sobre qual texto é o real quando dois divergem.

O que é copy drift?

Copy drift é quando o texto visível ao usuário se afasta da sua fonte aprovada entre superfícies e ao longo do tempo, sem uma única fonte de verdade da qual divergir.

Três falhas diferentes acabam sendo confundidas entre si, e cada uma exige uma correção diferente:

• Uma string que nunca foi transformada em chave é uma string hardcoded. Ela é invisível para o seu catálogo e para a tradução, mas o texto em si pode estar perfeitamente correto. Cobrimos esse padrão em por que ferramentas de codificação com IA continuam adicionando strings hardcoded.
• Catálogos que existem, mas ficam dessincronizados entre si são arquivos de tradução fora de sincronia. A fonte está correta; as cópias derivadas é que estão desatualizadas.
• O copy drift não é nada disso. A string tem chave, os arquivos estão sincronizados, e o próprio texto mudou sem que ninguém tenha decidido isso — daí a página de marketing prometer “Comece o teste grátis”, a landing page dizer “Experimente de graça” e o botão do produto trazer “Começar agora”.

O drift é o mais caro dos três porque nada quebra. Nenhum build falha, nenhum teste fica vermelho, nenhuma tradução falta. O produto simplesmente passa a falar com três vozes diferentes, e ninguém consegue apontar o momento exato em que isso começou. Definimos o termo por completo em copy drift: o que é, o que causa e como evitar.

Por que agentes de codificação com IA causam copy drift?

Agentes de codificação alteram textos que não foram pedidos para alterar, porque reescrever uma string próxima é indistinguível de organizar um componente.

Peça a um agente para adicionar um estado de carregamento e ele também pode encurtar um rótulo, mudar a capitalização de um título ou trocar “Entrar” por “Fazer login” enquanto está no arquivo. Cada edição, isolada, é defensável. Nenhuma delas foi solicitada, e nenhuma é sinalizada como uma mudança de texto, porque, para a ferramenta, trata-se apenas de mais uma string literal dentro de um atributo JSX, igual a qualquer outra.

A resposta da comunidade até agora tem sido um arquivo de regras — AGENTS.md, .cursorrules, um bloco de “política de copy da 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 o agente reescreve seu texto; não avisa quando isso aconteceu.

Onde o texto do produto realmente mora na maioria dos times?

Em quatro lugares ao mesmo tempo, cada um com um dono diferente e um caminho de edição diferente.

Tem o site de marketing, geralmente em um CMS. Tem a landing page, muitas vezes mantida separadamente e atualizada mais rápido do que tudo, porque é o que está sob experimentação ativa. Tem as strings dentro do produto, espalhadas pelos componentes. E tem os arquivos de locale, que dependem das strings do produto e ficam desatualizados em relação aos três outros.

Cada uma dessas superfícies pode estar internamente consistente enquanto o produto como um todo não está. Esse é o verdadeiro formato do problema, e é por isso que tratá-lo apenas como um problema de copy de produto é subestimá-lo.

Como manter o texto da UI consistente em toda a base de código?

Faça do repositório a fonte de verdade e transforme a string em uma unidade revisável — todo o resto decorre desses dois movimentos.

Na prática, isso significa três coisas. Toda string visível ao usuário vive em um único catálogo, em vez de embutida nos componentes. Os componentes referenciam uma chave em vez de um valor literal, então o mesmo texto não pode existir em dois lugares e divergir silenciosamente. E qualquer alteração no catálogo aparece no diff, onde um revisor a enxerga da mesma forma que enxerga qualquer outra mudança.

Esse último ponto é o que realmente resolve o problema. A consistência de copy costuma ser tratada como uma questão de disciplina — o time precisa de um guia de estilo, alguém precisa lembrar. Assim que o texto passa a estar no diff, ele deixa de depender de memória. Ele se torna visível no momento da revisão, que é o único momento em que alguém realmente está prestando atenção.

Times que lançam produtos com ferramentas de codificação com IA costumam esbarrar nisso mais cedo e com mais força, e é por isso que escrevemos sobre o tema especificamente para desenvolvedores e para quem constrói com ferramentas de IA.

Por que consistência de copy e localização são o mesmo problema?

Ambos falham pelo mesmo motivo: não existe uma fonte acordada com a qual ser consistente ou a partir da qual traduzir.

Um time que não consegue dizer qual das três formulações é a aprovada também não consegue localizar nenhuma delas corretamente. Envie as três para tradução e você terá três traduções, em cada idioma, e a inconsistência agora está multiplicada pelo número de seus locales, em vez de contida no inglês. Esse é o mecanismo por trás da maior parte do que parece ser má qualidade de tradução — a fonte já era ambígua.

Faça o caminho inverso e os dois problemas se resolvem em um só. Assim que toda string tem uma única fonte e uma chave, a tradução passa a ser um artefato derivado desse catálogo. Não existe um projeto separado com sua própria cópia da verdade, porque só existe uma cópia da verdade. É isso que significa “localização já embutida” em termos de arquitetura: não que também fazemos tradução, mas que a tradução é a mesma operação aplicada sobre o mesmo objeto. Escrevemos sobre como essa reordenação aconteceu em o que o código escrito por IA fez com a localização.

E o texto fora do produto?

Essa é a parte que a categoria ainda não resolveu, e não vamos fingir o contrário: padronizar o texto entre marketing, landing pages e produto como um único sistema é o objetivo para onde estamos caminhando, não algo que você pode ativar hoje.

Eis por que isso ainda não foi resolvido. Toda ferramenta existente nesse espaço é dona de uma única superfície. Ferramentas de copy de produto controlam as strings dentro do app. Plataformas de conteúdo controlam o site de marketing. Nenhuma enxerga a outra, então a formulação na página que conquistou o usuário e a formulação na tela que faz o onboarding dele são mantidas por pessoas diferentes, em ferramentas diferentes, sem nenhum mecanismo que jamais perceba que elas divergem.

O formato da resposta decorre da arquitetura já descrita. Se o texto aprovado mora em um único lugar e cada superfície o referencia por chave, em vez de reescrevê-lo, então a landing page e o botão do produto são a mesma string, e alterá-la é uma decisão só, não três. Chegar lá é um item do roadmap da globalize.now. Nomear isso com precisão agora parece melhor do que fingir que já está pronto.

Em que isso é diferente de uma ferramenta de copy construída sobre um arquivo de design?

A diferença é arquitetural, não categórica — ambos são sistemas de gestão de copy, e discordam sobre onde a verdade mora.

Duas observações que vale a pena datar, porque o estado dos fornecedores muda. Em 29/08/2026, dittowords.com/llms.txt retorna 404, o que significa que a citação mais referenciada dessa categoria não tem um arquivo de entidade legível por máquina. E, na mesma data, a própria página de produto de localização da Ditto descreve a adição de uma variante para cada idioma e a pré-visualização das traduções nos designs — não afirma que produz as traduções. É aí que está a costura: uma ferramenta pode ser dona do texto e ainda assim repassar o trabalho de idioma para outra pessoa.

Também não estamos competindo com motores de tradução nem com bibliotecas de i18n em tempo de execução. Essas são camadas diferentes e continuam onde estão.