Gli stati di traduzione dovrebbero rispondere alla domanda successiva

I sistemi di traduzione producono moltissimi stati. I job entrano in coda, i provider rispondono, le bozze vengono salvate, Contentful si aggiorna, le voci vengono pubblicate e partono i tentativi di nuovo invio.

Mostrare tutta questa attività non rende automaticamente chiaro l’avanzamento.

Uno stato utile dovrebbe rispondere alla domanda successiva che l’editor si pone.

Una richiesta ha diversi cicli di vita

Una richiesta multilingue spesso attraversa tre fasi principali:

1. traduzione
2. invio
3. pubblicazione

Ogni fase può essere inattiva, in coda, in corso, riuscita, saltata o fallita. Comprimere questi stati in una sola parola fa perdere informazioni importanti.

"Completato" potrebbe significare che la bozza di traduzione è pronta per la revisione, che la lingua di destinazione è stata scritta in Contentful oppure che la voce è online. Sono risultati sostanzialmente diversi.

L’interfaccia dovrebbe indicare insieme il nome della fase e il suo stato.

Stato e azione appartengono insieme

Gli editor leggono lo stato per decidere cosa possono fare dopo.

• Una traduzione pronta può essere revisionata.
• Una traduzione approvata può essere inviata.
• Un invio riuscito può essere pubblicato.
• Un errore temporaneo può essere ritentato.
• Un’attività in corso potrebbe essere annullabile.

Se l’azione disponibile non corrisponde allo stato mostrato, il prodotto sembra incoerente. Un pulsante di pubblicazione accanto a una richiesta che non è mai stata inviata non è solo fonte di confusione; indebolisce la fiducia nel flusso di lavoro sottostante.

Il backend dovrebbe determinare la disponibilità in base a stato persistente e permessi, poi l’interfaccia utente dovrebbe riflettere tale decisione in modo coerente.

I conteggi di avanzamento hanno bisogno di un denominatore stabile

L’avanzamento di un batch diventa fuorviante quando ogni fase usa un totale diverso senza spiegarlo.

Un batch con dieci richieste di traduzione può avere dieci traduzioni, otto invii e sei pubblicazioni perché alcune lingue erano solo per revisione oppure l’automazione era disabilitata.

L’avanzamento dovrebbe distinguere tra:

• richieste totali
• richieste idonee per la fase corrente
• richieste completate, attive, fallite e saltate

Saltate è particolarmente importante. È una decisione terminale, non lavoro incompiuto.

Conservare la cronologia senza affollare lo schermo

Lo stato corrente dovrebbe restare compatto, ma gli operatori hanno comunque bisogno della cronologia quando qualcosa va storto.

Una timeline eventi espandibile può mostrare quando la richiesta è entrata in coda, quale tentativo è fallito, se è stato eseguito un nuovo tentativo automatico e quando Contentful ha accettato l’aggiornamento. Questo supporta il debug senza trasformare ogni riga della tabella in un visualizzatore di log.

Usa un linguaggio umano per lo stato principale e conserva identificatori tecnici e timestamp nella vista di dettaglio.

Gli stati terminali dovrebbero restare terminali

Il polling e gli eventi in tempo reale possono arrivare fuori ordine. Un vecchio evento "in corso" non deve riportare indietro una richiesta completata. Una pagina aggiornata non dovrebbe mostrare temporaneamente in coda quando il database registra già il successo.

Le transizioni di stato hanno bisogno di ordinamento e idempotenza. L’interfaccia dovrebbe unire gli aggiornamenti usando il timestamp o la versione autorevole, non semplicemente accettare l’ultimo messaggio consegnato al browser.

Il punto chiave

La progettazione degli stati fa parte del flusso di lavoro, non è una decorazione attorno ad esso.

Separa le fasi di traduzione, invio e pubblicazione. Associa ogni stato all’azione che abilita, conta in modo onesto il lavoro saltato e tieni una cronologia dettagliata a portata di mano. Lo stato migliore è quello che rende chiara la decisione successiva.