Gli aggiornamenti di traduzione in tempo reale dovrebbero essere utili, non obbligatori

Vedere una traduzione passare da in coda a in lavorazione a pronta è utile. I team possono osservare i progressi senza aggiornare la pagina, aprire rapidamente il lavoro completato e notare una richiesta non riuscita mentre il rilascio è ancora attivo.

Ma gli aggiornamenti in tempo reale sono una capacità di presentazione. Non dovrebbero essere il meccanismo che rende corretto il flusso di lavoro.

Lo stato durevole viene prima

Il database e il sistema di job dovrebbero essere i proprietari dello stato della traduzione. Ogni transizione di fase deve essere registrata indipendentemente dal fatto che un browser sia connesso oppure no:

• richiesta messa in coda
• traduzione avviata e completata
• push avviato e completato
• pubblicazione avviata e completata
• eventi di errore e di retry

Un evento realtime può annunciare quel cambiamento durevole. Non dovrebbe essere l'unica registrazione del fatto che il cambiamento è avvenuto.

Questa distinzione protegge gli utenti che chiudono la scheda, perdono l'accesso alla rete o lavorano in un ambiente in cui l'infrastruttura websocket è disabilitata.

Il realtime ha un costo operativo

Il broadcasting introduce più parti in movimento: un servizio websocket, l'autorizzazione delle connessioni, la configurazione dei canali, il supporto proxy e il comportamento di riconnessione del browser.

Per i team che hanno bisogno di coordinamento in tempo reale, quel costo può valerne la pena. Per una distribuzione più piccola, il polling ordinario può essere più semplice e del tutto adeguato.

Rendere il realtime opzionale permette a ogni ambiente di scegliere il profilo operativo che può supportare senza perdere il comportamento fondamentale della traduzione.

Progetta un fallback graduale

L'interfaccia utente dovrebbe raggiungere lo stesso stato finale tramite eventi realtime o aggiornamento periodico.

Un approccio pratico è:

1. caricare lo stato durevole corrente
2. sottoscriversi agli eventi rilevanti quando il realtime è abilitato
3. unire gli aggiornamenti in arrivo per ID richiesta e versione
4. eseguire polling a un intervallo moderato finché rimane lavoro attivo
5. interrompere il polling frequente quando il batch raggiunge uno stato terminale

Il realtime rende la schermata immediata. Il polling colma le lacune dopo le riconnessioni e fornisce un fallback.

I due percorsi non dovrebbero creare regole di stato in competizione.

Evita di trasformare gli aggiornamenti in rumore

Non tutti gli eventi interni appartengono all'interfaccia. Trasmettere ogni token, heartbeat del worker o salvataggio intermedio può rendere la pagina instabile e aumentare il carico dell'infrastruttura.

Di solito gli utenti hanno bisogno di transizioni di fase significative e conteggi aggiornati. Raggruppare i rapidi cambiamenti di basso livello in un insieme più piccolo di traguardi durevoli mantiene l'esperienza calma e facile da consultare.

Lo stesso principio si applica alle notifiche. Un batch completato può meritare attenzione. Probabilmente non ogni lingua completata.

Testa il percorso silenzioso

È facile testare con il realtime abilitato e presumere che il fallback funzioni. L'affidabilità richiede l'esercizio opposto:

• disabilitare il broadcasting
• avviare un batch multi-lingua
• lasciare e tornare alla pagina
• confermare che i progressi si aggiornino
• ritentare una richiesta non riuscita
• verificare i conteggi finali e le azioni disponibili

Se quel percorso funziona, il realtime è un miglioramento invece di una dipendenza nascosta.

Il punto chiave

Gli aggiornamenti in tempo reale migliorano le operazioni di traduzione quando si appoggiano su uno stato durevole.

Registra prima ogni transizione, rendi configurabile il broadcasting e mantieni un fallback di polling misurato. Il flusso di lavoro dovrebbe rimanere affidabile anche quando il canale di consegna più immediato non è disponibile.