Vertaalstatussen moeten de volgende vraag beantwoorden

Vertaalsystemen produceren veel status. Taken komen in de wachtrij, providers reageren, concepten worden opgeslagen, Contentful wordt bijgewerkt, items worden gepubliceerd en retries starten.

Al die activiteit tonen maakt voortgang niet automatisch duidelijk.

Een bruikbare status moet de volgende vraag beantwoorden die de redacteur heeft.

Eén verzoek heeft meerdere levenscycli

Een meertalig verzoek doorloopt vaak drie hoofdfasen:

1. vertalen
2. pushen
3. publiceren

Elke fase kan inactief, in de wachtrij, bezig, succesvol, overgeslagen of mislukt zijn. Die toestanden comprimeren tot één woord verliest belangrijke informatie.

"Voltooid" kan betekenen dat het vertaalconcept klaar is voor review, dat de doellocale naar Contentful is geschreven, of dat het item live staat. Dat zijn wezenlijk verschillende uitkomsten.

De interface moet de fase en de status samen benoemen.

Status en actie horen bij elkaar

Redacteuren lezen de status om te beslissen wat ze hierna kunnen doen.

• Een gereedstaande vertaling kan worden gereviewd.
• Een goedgekeurde vertaling kan worden gepusht.
• Een succesvolle push kan worden gepubliceerd.
• Een tijdelijke fout kan opnieuw worden geprobeerd.
• Lopend werk kan mogelijk worden geannuleerd.

Als de beschikbare actie niet overeenkomt met de getoonde status, voelt het product inconsistent. Een publicatieknop naast een verzoek dat nooit is gepusht is niet alleen verwarrend; het verzwakt het vertrouwen in de onderliggende workflow.

De backend moet de beschikbaarheid bepalen op basis van duurzame status en rechten, waarna de UI die beslissing consistent moet weerspiegelen.

Voortgangsaantallen hebben een stabiele noemer nodig

Batchvoortgang wordt misleidend wanneer elke fase een ander totaal gebruikt zonder dat uit te leggen.

Een batch met tien vertaalverzoeken kan tien vertalingen, acht pushes en zes publicaties hebben omdat sommige locales alleen voor review waren of automatisering was uitgeschakeld.

Voortgang moet onderscheid maken tussen:

• totaal aantal verzoeken
• verzoeken die in aanmerking komen voor de huidige fase
• voltooide, actieve, mislukte en overgeslagen verzoeken

Overgeslagen is vooral belangrijk. Het is een definitieve beslissing, geen onvoltooid werk.

Behoud geschiedenis zonder het scherm te overladen

De huidige status moet compact blijven, maar operators hebben nog steeds geschiedenis nodig wanneer er iets misgaat.

Een uitklapbare gebeurtenistijdlijn kan tonen wanneer het verzoek in de wachtrij kwam, welke poging mislukte, of een automatische retry is uitgevoerd en wanneer Contentful de update accepteerde. Dat ondersteunt foutopsporing zonder van elke tabelrij een logviewer te maken.

Gebruik begrijpelijke taal voor de hoofdstatus en behoud technische identifiers en tijdstempels in de detailweergave.

Terminale statussen moeten terminaal blijven

Polling en realtime-gebeurtenissen kunnen buiten volgorde aankomen. Een ouder "bezig"-event mag een voltooid verzoek niet terugzetten. Een ververste pagina mag niet tijdelijk "in de wachtrij" tonen nadat de database al succes heeft geregistreerd.

Statustransities hebben ordening en idempotentie nodig. De interface moet updates samenvoegen met behulp van de gezaghebbende tijdstempel of versie, en niet simpelweg het laatste bericht accepteren dat in de browser is afgeleverd.

Conclusie

Statusontwerp is onderdeel van de workflow, geen decoratie eromheen.

Scheid vertaal-, push- en publicatiefasen. Koppel elke status aan de actie die ermee mogelijk wordt, tel overgeslagen werk eerlijk mee en houd een gedetailleerde geschiedenis dichtbij. De beste status is degene die de volgende beslissing duidelijk maakt.