Os Status de Tradução Devem Responder à Próxima Pergunta

Os sistemas de tradução geram bastante estado. Trabalhos entram na fila, provedores respondem, rascunhos são salvos, o Contentful é atualizado, entradas são publicadas e novas tentativas são iniciadas.

Mostrar toda essa atividade não torna automaticamente o progresso claro.

Um status útil deve responder à próxima pergunta que o editor tem.

Uma solicitação tem vários ciclos de vida

Uma solicitação multilíngue geralmente passa por três fases principais:

1. traduzir
2. enviar
3. publicar

Cada fase pode estar inativa, na fila, em andamento, bem-sucedida, ignorada ou com falha. Comprimir esses estados em uma única palavra faz perder informações importantes.

"Concluído" pode significar que o rascunho da tradução está pronto para revisão, que o locale de destino foi gravado no Contentful ou que a entrada está no ar. Esses são resultados materialmente diferentes.

A interface deve nomear a fase e seu estado juntos.

Status e ação pertencem juntos

Os editores leem o status para decidir o que podem fazer em seguida.

• Uma tradução pronta pode ser revisada.
• Uma tradução aprovada pode ser enviada.
• Um envio bem-sucedido pode ser publicado.
• Uma falha transitória pode receber nova tentativa.
• Um trabalho ativo pode ser cancelável.

Se a ação disponível não corresponder ao estado exibido, o produto parece inconsistente. Um botão de publicar ao lado de uma solicitação que nunca foi enviada não é apenas confuso; ele enfraquece a confiança no fluxo de trabalho subjacente.

O backend deve determinar a disponibilidade a partir do estado persistente e das permissões, e então a UI deve refletir essa decisão de forma consistente.

As contagens de progresso precisam de um denominador estável

O progresso em lote se torna enganoso quando cada fase usa um total diferente sem explicá-lo.

Um lote com dez solicitações de tradução pode ter dez traduções, oito envios e seis publicações porque alguns locales eram apenas para revisão ou a automação estava desativada.

O progresso deve distinguir:

• total de solicitações
• solicitações elegíveis para a fase atual
• solicitações concluídas, ativas, com falha e ignoradas

Ignorada é especialmente importante. Trata-se de uma decisão terminal, não de trabalho inacabado.

Preserve o histórico sem lotar a tela

O estado atual deve permanecer compacto, mas os operadores ainda precisam de histórico quando algo dá errado.

Uma linha do tempo de eventos expansível pode mostrar quando a solicitação entrou na fila, qual tentativa falhou, se uma nova tentativa automática foi executada e quando o Contentful aceitou a atualização. Isso dá suporte à depuração sem transformar cada linha da tabela em um visualizador de logs.

Use linguagem humana para o status principal e mantenha identificadores técnicos e timestamps na visualização detalhada.

Estados terminais devem permanecer terminais

Eventos de polling e em tempo real podem chegar fora de ordem. Um evento antigo de "em andamento" não deve fazer uma solicitação concluída regredir. Uma página atualizada não deve mostrar temporariamente na fila depois que o banco de dados já registrou sucesso.

As transições de estado precisam de ordenação e idempotência. A interface deve mesclar atualizações usando o timestamp ou a versão autoritativa, não simplesmente aceitar a última mensagem entregue ao navegador.

Conclusão

O design de status faz parte do fluxo de trabalho, não é decoração ao redor dele.

Separe as fases de tradução, envio e publicação. Associe cada estado à ação que ele habilita, conte o trabalho ignorado com honestidade e mantenha um histórico detalhado por perto. O melhor status é aquele que torna clara a próxima decisão.