Reliability · 1. 7. 2026
Aktualizace překladu v reálném čase by měly být užitečné, ne povinné
Živý stav je cenný, ale překladové operace by měly zůstat správné, i když infrastruktura pro realtime není dostupná nebo je záměrně vypnutá.

Sledovat, jak se překlad posouvá ze stavu zařazeno do fronty přes zpracovává se až po připraveno, je užitečné. Týmy mohou vidět průběh bez obnovování, rychle otevřít dokončenou práci a všimnout si neúspěšného požadavku, dokud je vydání stále aktivní.
Živé aktualizace jsou ale prezentační schopnost. Neměly by být mechanismem, který zajišťuje správnost workflow.
Trvalý stav je na prvním místě
Databáze a systém úloh by měly vlastnit stav překladu. Každý přechod mezi fázemi je potřeba zaznamenat bez ohledu na to, zda je prohlížeč připojen:
- požadavek zařazen do fronty
- překlad zahájen a dokončen
- push zahájen a dokončen
- publikování zahájeno a dokončeno
- události selhání a opakování
Realtime událost může tuto trvalou změnu oznámit. Neměla by být jediným záznamem o tom, že ke změně došlo.
Toto rozlišení chrání uživatele, kteří zavřou kartu, ztratí přístup k síti nebo pracují v prostředí, kde je websocket infrastruktura vypnutá.
Realtime má provozní náklady
Broadcasting přináší více pohyblivých částí: websocket službu, autorizaci připojení, konfiguraci kanálů, podporu proxy a chování opětovného připojení v prohlížeči.
Pro týmy, které potřebují živou koordinaci, se tyto náklady mohou vyplatit. Pro menší nasazení může být běžné polling jednodušší a zcela dostačující.
Když je realtime volitelný, může si každé prostředí zvolit provozní profil, který zvládne podporovat, aniž by přišlo o základní chování překladu.
Navrhněte elegantní záložní variantu
UI by mělo dosáhnout stejného konečného stavu pomocí realtime událostí nebo periodického obnovování.
Praktický přístup je:
- načíst aktuální trvalý stav
- přihlásit se k odběru relevantních událostí, když je realtime povolen
- slučovat příchozí aktualizace podle ID požadavku a verze
- dotazovat se v rozumném intervalu, dokud zbývá aktivní práce
- zastavit časté dotazování, když dávka dosáhne koncového stavu
Realtime dává obrazovce pocit okamžitosti. Polling uzavírá mezery po opětovném připojení a poskytuje záložní variantu.
Tyto dvě cesty by neměly vytvářet konkurenční pravidla pro stav.
Vyhněte se tomu, aby se aktualizace změnily v šum
Ne každá interní událost patří do rozhraní. Broadcastování každého tokenu, heartbeat workeru nebo průběžného uložení může stránku destabilizovat a zvýšit zátěž infrastruktury.
Uživatelé obvykle potřebují smysluplné přechody mezi fázemi a aktualizované počty. Seskupení rychlých nízkoúrovňových změn do menší sady trvalých milníků udržuje prostředí klidné a snadno čitelné.
Stejný princip platí i pro notifikace. Dokončená dávka si může zasloužit pozornost. Každé dokončené locale pravděpodobně ne.
Otestujte tichou cestu
Je snadné testovat se zapnutým realtime a předpokládat, že záložní varianta funguje. Spolehlivost vyžaduje opačné cvičení:
- vypnout broadcasting
- spustit dávku pro více locale
- opustit stránku a vrátit se na ni
- potvrdit, že se průběh dorovná
- zopakovat neúspěšný požadavek
- ověřit konečné počty a dostupné akce
Pokud tato cesta funguje, je realtime vylepšením místo skryté závislosti.
Shrnutí
Živé aktualizace zlepšují překladové operace, když stojí nad trvalým stavem.
Nejprve zaznamenávejte každý přechod, udělejte broadcasting konfigurovatelným a zachovejte umírněnou záložní variantu s pollingem. Workflow by mělo zůstat důvěryhodné, i když není k dispozici nejbezprostřednější doručovací kanál.