Gestire le traduzioni non riuscite senza perdere la release

In una release multilingue, "fallito" non è un'unica condizione.

La richiesta al modello potrebbe non essere riuscita. La traduzione potrebbe essere pronta ma impossibilitata a eseguire il push su Contentful. La voce localizzata potrebbe essere aggiornata ma non pubblicata. Raggruppare tutte e tre sotto un unico stato rosso rende la dashboard più semplice e il lavoro di recupero più difficile.

Inizia dalla fase non riuscita

Traduzione, push e pubblicazione sono operazioni separate con dipendenze diverse.

Un errore di traduzione può derivare da un timeout del provider, una risposta del modello non valida o una validazione del contenuto protetto. Un errore di push può riguardare permessi, validazione dei campi o un conflitto di versione in Contentful. Un errore di pubblicazione può riflettere lo stato della voce, la configurazione dell'ambiente o la modalità di pubblicazione.

Il primo filtro di triage dovrebbe rispondere a questa domanda: quale fase richiede attenzione?

Questo restringe immediatamente la responsabilità e i passaggi successivi.

Mostra l'estensione dell'impatto

Una richiesta non riuscita ha bisogno di abbastanza elementi identificativi per supportare una decisione:

• nome e ID della voce
• lingua di origine e lingua di destinazione
• batch
• fase non riuscita
• errore più recente
• numero di tentativi e ora dell'ultimo tentativo
• se le fasi successive sono mai iniziate

Senza questo contesto, gli operatori aprono ogni richiesta singolarmente e ricostruiscono la release a mano.

La vista batch dovrebbe anche distinguere un fallimento parziale da un fallimento totale. Se 49 lingue su 50 sono andate a buon fine, il team dovrebbe poter andare avanti con il lavoro completato mentre recupera una richiesta.

Riprova dal confine corretto

Un nuovo tentativo dovrebbe riprendere dalla fase non riuscita, non ripetere ogni fase riuscita precedente.

Se la traduzione è riuscita e il push non è riuscito, conserva la traduzione revisionata e riprova il push. Se Contentful è stato aggiornato e la pubblicazione non è riuscita, riprova la pubblicazione sullo stato corrente della voce.

Riavviare dalla traduzione può creare un testo diverso, invalidare la revisione, aumentare i costi e nascondere il problema originale.

I tentativi consapevoli della fase mantengono stabile il lavoro riuscito.

Separa i fallimenti transitori da quelli permanenti

Alcuni errori si prestano bene a un nuovo tentativo automatico:

• timeout del provider
• limiti di velocità
• brevi interruzioni di rete
• conflitti di versione recuperabili

Altri richiedono una persona:

• configurazione del contenuto non valida
• abilitazione della lingua mancante
• negazione dei permessi
• struttura protetta che non può essere ripristinata
• un campo di destinazione modificato dopo la revisione

La policy di retry dovrebbe essere limitata e visibile. Dopo aver raggiunto il limite automatico, la richiesta appartiene a una coda umana con l'ultimo errore utile intatto.

Mantieni leggera la lista dei fallimenti

Le schermate operative vengono usate quando qualcosa sta già andando storto. Non dovrebbero attivare un'idratazione profonda del CMS per ogni riga né interrogare con un polling così aggressivo da far generare alla pagina più carico dei worker che monitora.

Restituisci prima metadati stabili della richiesta. Recupera i dettagli completi della voce solo quando un operatore apre la richiesta.

Il filtro rapido fa parte del recupero.

Conclusione

Un badge rosso non è un sistema di recupero.

Separa i fallimenti per fase, mostra l'ambito interessato e riprova solo l'operazione che non è riuscita. Automatizza il recupero transitorio entro limiti chiari e conserva errori attuabili per tutto il resto. I team possono tollerare fallimenti individuali quando il flusso di lavoro rende evidente la decisione successiva.