A detecção de alterações na fonte mantém as revisões de tradução honestas

Uma tradução pode estar correta e ainda assim desatualizada.

Isso acontece quando um editor altera a entrada de origem depois que a tradução começa. O rascunho localizado ainda reflete o snapshot original, mas a tela de revisão pode mostrar a fonte mais recente. A menos que o fluxo marque a diferença, um revisor pode aprovar dois conteúdos que, na prática, nunca foram comparados.

A detecção de alterações na fonte impede que essa incompatibilidade silenciosa chegue a uma publicação.

A tradução começa a partir de um snapshot

Toda solicitação de tradução tem um limite de origem: um conjunto de campos, valores e estruturas de rich text em um determinado momento.

Esse snapshot deve ser salvo com a solicitação. Ele explica o que o modelo recebeu, o que o revisor está avaliando e por que o rascunho de destino diz o que diz.

Buscar novamente a fonte para exibição é útil, mas isso não deve substituir o snapshot histórico. O fluxo precisa de ambos:

• a fonte usada para gerar o rascunho
• a fonte atual no CMS

Sem o primeiro, o rascunho não tem procedência confiável. Sem o segundo, a equipe não consegue ver que a página já mudou.

Nem toda alteração invalida tudo

Um timestamp sozinho pode dizer que uma entrada mudou, mas não se a tradução está desatualizada.

Um editor pode atualizar uma nota interna, adicionar um asset a um campo não localizado ou corrigir um campo que não foi incluído na solicitação. Essas alterações não devem necessariamente bloquear o rascunho localizado.

Compare no nível do campo traduzido. Se o título da fonte mudou, marque o rascunho do título como desatualizado. Se apenas o corpo mudou, mantenha o título revisado intacto e devolva o corpo para atenção.

A invalidação restrita preserva o trabalho concluído enquanto torna explícito o risco restante.

Mostre aos revisores a diferença real

"A fonte mudou" é um aviso, não uma decisão.

Os revisores precisam ver o que mudou entre o snapshot original e o valor atual. Para texto simples, um diff em nível de palavra pode ser suficiente. Para rich text, a comparação também deve destacar alterações estruturais, como um link removido, um novo item de lista ou uma entrada incorporada diferente.

A pergunta útil não é simplesmente se as strings diferem. É se o destino aprovado ainda representa a fonte atual com precisão.

Dê à equipe escolhas deliberadas

Quando um campo de origem traduzido muda, o fluxo pode oferecer um pequeno conjunto de caminhos claros:

1. manter a tradução atual quando a alteração não afeta o significado
2. editar o rascunho localizado manualmente
3. regenerar apenas o campo afetado
4. devolver a solicitação para tradução quando a alteração for ampla

A escolha e o revisor devem ser registrados. Um aviso de desatualização que pode ser descartado sem um registro de auditoria é fácil de ignorar sob pressão de publicação.

Verifique novamente antes do push

Uma revisão pode começar com conteúdo de origem correspondente e terminar depois que outra edição é aplicada.

Execute a comparação da fonte novamente imediatamente antes de fazer push para o CMS. Essa última verificação fecha a lacuna entre aprovação e entrega. Ela deve usar as mesmas regras em nível de campo da tela de revisão e interromper apenas as gravações afetadas.

Para publicação automatizada, a verificação é ainda mais importante. A automação remove uma pausa humana, então o sistema deve ser preciso sobre qual snapshot aprovado está disposto a publicar.

Conclusão

A revisão de tradução só é confiável quando a fonte sendo revisada é a fonte que produziu o rascunho.

Armazene o snapshot original, compare-o com os valores atuais do CMS, identifique alterações por campo e permita que os revisores resolvam diferenças significativas de forma deliberada. A detecção de alterações na fonte não desacelera a localização. Ela impede que as equipes publiquem com confiança a resposta de ontem para o conteúdo de hoje.