Um erro de digitação na origem é o tipo de erro que você só tem uma chance de corrigir — antes que ele se multiplique. Um job assíncrono distribui um único payload de origem para cada idioma de destino, e cada idioma traduz o texto que recebeu. Então, um erro ortográfico, uma palavra omitida ou uma frase quebrada na origem não fica restrito a um único problema. Ele vira um problema em alemão, o mesmo problema em francês e o mesmo problema em todos os outros idiomas que o job alcança — cada um agora exigindo sua própria correção depois.
A edição por IA antes da localização (preEdit) resolve essa lacuna na origem. Ela é a primeira etapa do pipeline assíncrono de localização: antes de a etapa principal de tradução entrar em ação, um agente de IA faz uma revisão do payload de origem e corrige erros de digitação, gramática e ortografia. É essa versão limpa da origem que segue para tradução — então você corrige uma vez, antes da distribuição, em vez de encontrar o mesmo erro em uma dúzia de saídas.
Esta é uma etapa do pipeline assíncrono, então ela só roda em jobs criados por meio da API de localização assíncrona. O endpoint síncrono /localize executa apenas a etapa principal de tradução e ignora as configurações do pipeline.
O que esta etapa faz#
preEdit atua na origem, não na tradução. Um agente de IA lê seu payload de origem e o reescreve para remover erros superficiais — digitação, gramática, ortografia — e depois entrega o texto corrigido para a etapa principal de localização. Cada idioma de destino traduz a partir dessa origem limpa.
O escopo é intencionalmente estreito — e esse é justamente o ponto. Esta é uma passada de limpeza de texto, não uma reescrita: ela ataca o tipo de ruído superficial que torna o texto de origem ambíguo para um modelo de tradução, para que o modelo concentre sua atenção em traduzir em vez de tentar adivinhar o que uma frase truncada queria dizer. Uma origem mais limpa gera traduções mais consistentes entre idiomas — porque cada idioma parte do mesmo texto corrigido, em vez de cada modelo interpretar o mesmo erro por conta própria.
Para uma saída idiomática, com cara de texto nativo — reescrever a própria tradução para que pareça escrita por um redator local — essa é outra etapa. Veja Reescrever para soar natural. preEdit limpa a entrada; rephrase refina a saída.
Ela não pode piorar o job#
A primeira pergunta que um engenheiro cuidadoso faz sobre uma etapa de IA que edita seu conteúdo antes da tradução é a pergunta certa: o que acontece quando essa etapa erra, ou nem chega a rodar?
preEdit é uma etapa não crítica. Se a chamada de pré-edição falhar ou expirar, a origem original segue adiante sem alterações e o job continua para a etapa de tradução exatamente como se a etapa estivesse desativada. Uma falha aqui custa a limpeza naquele job — não o job. A tradução ainda é entregue.
E se a pré-edição falhar ou expirar?
O job não falha. Etapas não críticas fazem fallback para a própria entrada: em caso de falha de preEdit, a origem sem edição é traduzida como está, e o job segue até a conclusão. O status do job passa a ser completed_with_warnings, a etapa preEdit é registrada como failed, e o motivo vai para o array warnings do job — para que você possa ver que isso aconteceu sem bloquear a entrega. A leitura desses registros de etapa é abordada em Observar execuções do pipeline.
Então, aqui vai a forma mais honesta de colocar o piso dessa etapa: ativar preEdit não pode fazer um job falhar se ele teria sido bem-sucedido de outra forma. No pior cenário, ela simplesmente não ajuda naquele job e sai discretamente de cena.
O que ela não é#
Vale deixar isso claro justamente no momento em que você mais gostaria que ela fosse além: preEdit é uma etapa de melhor esforço, focada em limpar erros superficiais do texto — não é um revisor que entende o seu domínio nem um verificador de fatos que valida suas afirmações. Ela corrige erros de digitação, gramática e ortografia. Ela não verifica se um preço está correto, se o nome de um produto está atualizado ou se uma frase diz o que você quis dizer. Se a sua origem estiver factualmente errada, preEdit vai corrigir fielmente a gramática de uma frase errada e traduzi-la de forma limpa para todos os idiomas.
Para termos que precisam permanecer exatamente como foram escritos, independentemente de qualquer passada de IA — nomes de produtos, marcas registradas, identificadores de código — fixe-os na origem. Marque-os como não traduzíveis no glossary do seu engine ou, para campos estruturais em um payload específico, exclua-os com lockedKeys. Essas são garantias sobre os dados; preEdit faz uma limpeza por melhor esforço ao redor delas.
Quando ativar#
preEdit vale a passada extra quando a sua origem tende a trazer ruído — e é redundante quando a origem já está limpa.
- Ative quando o conteúdo de origem for gerado por usuários, extraído por máquina, raspado, obtido por OCR ou produzido fora de um processo editorial — casos em que erros superficiais são comuns e o custo de multiplicá-los entre idiomas é real.
- Ignore em conteúdo curado que já passou por editorial ou revisão humana. Se a origem já está limpa, não há nada para a etapa corrigir, e você estaria pagando por uma passada de IA sem trabalho a fazer. Cada etapa ativada é mais um passo que o job executa e mais uma linha no custo — vale a pena quando a qualidade da origem é incerta; é desperdício quando não é.
Essa é a troca completa: gastar uma passada logo no início, nos jobs em que a qualidade da origem é incerta, para corrigir uma vez antes da distribuição — em vez de corrigir o mesmo erro em todos os idiomas depois da entrega.
Você ativa preEdit na aba Pipeline do engine, onde ela se aplica a todo job assíncrono roteado para esse engine, ou a substitui para uma única submissão com pipelineConfig na requisição de criação de jobs. As duas camadas, e como uma etapa omitida herda o padrão do engine, são abordadas em Configurar o pipeline.
