As atualizações de tradução em tempo real devem ser úteis, não obrigatórias

Acompanhar uma tradução passar de enfileirada para em andamento e depois pronta é útil. As equipes podem ver o progresso sem atualizar a página, abrir rapidamente o trabalho concluído e perceber uma solicitação com falha enquanto a liberação ainda está ativa.

Mas as atualizações ao vivo são um recurso de apresentação. Elas não devem ser o mecanismo que torna o fluxo de trabalho correto.

O estado durável vem primeiro

O banco de dados e o sistema de jobs devem ser os responsáveis pelo estado da tradução. Cada transição de fase precisa ser registrada, esteja ou não um navegador conectado:

• solicitação enfileirada
• tradução iniciada e concluída
• envio iniciado e concluído
• publicação iniciada e concluída
• eventos de falha e nova tentativa

Um evento em tempo real pode anunciar essa mudança durável. Não deve ser o único registro de que a mudança ocorreu.

Essa distinção protege usuários que fecham a aba, perdem acesso à rede ou trabalham em um ambiente em que a infraestrutura de websocket está desativada.

Tempo real tem um custo operacional

A transmissão adiciona mais partes móveis: um serviço de websocket, autorização de conexão, configuração de canal, suporte a proxy e comportamento de reconexão do navegador.

Para equipes que precisam de coordenação ao vivo, esse custo pode valer a pena. Para uma implantação menor, o polling comum pode ser mais simples e totalmente adequado.

Tornar o tempo real opcional permite que cada ambiente escolha o perfil operacional que consegue suportar sem perder o comportamento principal da tradução.

Projete um fallback elegante

A interface deve chegar ao mesmo estado final por meio de eventos em tempo real ou atualização periódica.

Uma abordagem prática é:

1. carregar o estado durável atual
2. assinar eventos relevantes quando o tempo real estiver ativado
3. mesclar atualizações recebidas por ID de solicitação e versão
4. fazer polling em um intervalo moderado enquanto houver trabalho ativo
5. parar o polling frequente quando o lote atingir um estado terminal

O tempo real faz a tela parecer imediata. O polling fecha lacunas após reconexões e fornece um fallback.

Os dois caminhos não devem criar regras de status concorrentes.

Evite transformar atualizações em ruído

Nem todo evento interno pertence à interface. Transmitir cada token, heartbeat do worker ou salvamento intermediário pode tornar a página instável e aumentar a carga da infraestrutura.

Os usuários normalmente precisam de transições de fase significativas e contagens atualizadas. Agrupar mudanças rápidas de baixo nível em um conjunto menor de marcos duráveis mantém a experiência calma e fácil de examinar.

O mesmo princípio se aplica às notificações. Um lote concluído pode merecer atenção. Cada localidade concluída provavelmente não.

Teste o caminho silencioso

É fácil testar com o tempo real ativado e presumir que o fallback funciona. Confiabilidade exige o exercício oposto:

• desative a transmissão
• inicie um lote com vários locais
• saia e volte para a página
• confirme que o progresso se atualiza
• tente novamente uma solicitação com falha
• verifique as contagens finais e as ações disponíveis

Se esse caminho funcionar, o tempo real será um aprimoramento em vez de uma dependência oculta.

A principal conclusão

As atualizações ao vivo melhoram as operações de tradução quando ficam sobre um estado durável.

Registre cada transição primeiro, torne a transmissão configurável e mantenha um fallback de polling comedido. O fluxo de trabalho deve continuar confiável mesmo quando o canal de entrega mais imediato estiver indisponível.