Stavy překladu by měly odpovídat na další otázku

Překladové systémy vytvářejí spoustu stavů. Úlohy se řadí do fronty, poskytovatelé odpovídají, koncepty se ukládají, Contentful se aktualizuje, záznamy se publikují a spouštějí se opakované pokusy.

Zobrazit veškerou tuto aktivitu automaticky neznamená, že je pokrok jasný.

Užitečný stav by měl odpovědět na další otázku, kterou editor má.

Jeden požadavek má několik životních cyklů

Vícejazyčný požadavek se často pohybuje třemi hlavními fázemi:

1. překlad
2. odeslání
3. publikování

Každá fáze může být nečinná, ve frontě, probíhající, úspěšná, přeskočená nebo neúspěšná. Sloučit tyto stavy do jednoho slova znamená ztratit důležité informace.

„Dokončeno“ může znamenat, že je návrh překladu připraven ke kontrole, že cílové národní prostředí bylo zapsáno do Contentful, nebo že je záznam živě publikovaný. To jsou podstatně odlišné výsledky.

Rozhraní by mělo pojmenovat fázi i její stav společně.

Stav a akce patří k sobě

Editoři čtou stav, aby se rozhodli, co mohou udělat dál.

• Hotový překlad lze zkontrolovat.
• Schválený překlad lze odeslat.
• Úspěšné odeslání lze publikovat.
• Přechodné selhání lze zopakovat.
• Aktivní práci může být možné zrušit.

Pokud dostupná akce neodpovídá zobrazenému stavu, produkt působí nekonzistentně. Tlačítko pro publikování vedle požadavku, který se nikdy neodeslal, není jen matoucí; oslabuje důvěru v podkladový workflow.

Backend by měl určovat dostupnost na základě trvalého stavu a oprávnění a UI by pak mělo toto rozhodnutí konzistentně odrážet.

Počty pokroku potřebují stabilního jmenovatele

Pokrok dávky začíná být zavádějící, když každá fáze používá jiný celkový počet, aniž by to vysvětlila.

Dávka s deseti požadavky na překlad může mít deset překladů, osm odeslání a šest publikování, protože některá národní prostředí byla jen ke kontrole nebo byla automatizace vypnutá.

Ukazatel pokroku by měl rozlišovat:

• celkový počet požadavků
• požadavky způsobilé pro aktuální fázi
• dokončené, aktivní, neúspěšné a přeskočené požadavky

Přeskočeno je obzvlášť důležité. Je to konečné rozhodnutí, nikoli nedokončená práce.

Zachovejte historii, aniž by zahltila obrazovku

Aktuální stav by měl zůstat kompaktní, ale operátoři stále potřebují historii, když se něco pokazí.

Rozbalitelná časová osa událostí může ukázat, kdy se požadavek zařadil do fronty, který pokus selhal, zda proběhl automatický opakovaný pokus a kdy Contentful přijal aktualizaci. To podporuje ladění, aniž by se z každého řádku tabulky stal prohlížeč logů.

Pro hlavní stav používejte srozumitelný jazyk a technické identifikátory i časová razítka ponechte v detailním zobrazení.

Konečné stavy by měly zůstat konečné

Události z pollingu a realtime přenosu mohou dorazit v nesprávném pořadí. Starší událost „probíhá“ nesmí posunout dokončený požadavek zpět. Obnovená stránka by neměla dočasně ukazovat stav ve frontě poté, co databáze už zaznamenala úspěch.

Přechody stavů potřebují řazení a idempotenci. Rozhraní by mělo slučovat aktualizace podle autoritativního časového razítka nebo verze, ne jednoduše přijmout poslední zprávu doručenou do prohlížeče.

Shrnutí

Návrh stavů je součástí workflow, ne dekorace kolem něj.

Oddělte fáze překladu, odeslání a publikování. Spárujte každý stav s akcí, kterou umožňuje, počítejte přeskočenou práci poctivě a mějte podrobnou historii nablízku. Nejlepší stav je ten, který jasně ukazuje další rozhodnutí.