Realtime-oversættelsesopdateringer bør være nyttige, ikke påkrævede

At se en oversættelse gå fra køet til i gang til klar er nyttigt. Teams kan se fremskridt uden at opdatere siden, åbne færdigt arbejde hurtigt og opdage en mislykket forespørgsel, mens releasen stadig er aktiv.

Men live-opdateringer er en præsentationsfunktion. De bør ikke være den mekanisme, der gør arbejdsgangen korrekt.

Holdbar tilstand kommer først

Databasen og jobsystemet bør eje oversættelsestilstanden. Hver faseovergang skal registreres, uanset om en browser er forbundet eller ej:

• forespørgsel sat i kø
• oversættelse startet og fuldført
• push startet og fuldført
• publicering startet og fuldført
• fejl- og genforsøgshændelser

En realtime-hændelse kan annoncere den holdbare ændring. Den bør ikke være den eneste registrering af, at ændringen fandt sted.

Denne skelnen beskytter brugere, der lukker fanen, mister netværksadgang eller arbejder i et miljø, hvor websocket-infrastruktur er deaktiveret.

Realtime har en driftsomkostning

Broadcasting introducerer flere bevægelige dele: en websocket-tjeneste, forbindelsesautorisation, kanalkonfiguration, proxy-understøttelse og browserens genforbindelsesadfærd.

For teams, der har brug for live-koordinering, kan den omkostning være det værd. For en mindre installation kan almindelig polling være enklere og fuldt ud tilstrækkelig.

At gøre realtime til et tilvalg lader hvert miljø vælge den driftsprofil, det kan understøtte, uden at miste grundlæggende oversættelsesadfærd.

Design et robust fallback

UI'et bør nå den samme endelige tilstand via realtime-hændelser eller periodisk opdatering.

En praktisk tilgang er:

1. indlæs den aktuelle holdbare tilstand
2. abonnér på relevante hændelser, når realtime er aktiveret
3. flet indgående opdateringer efter forespørgsels-ID og version
4. poll med et moderat interval, mens aktivt arbejde stadig er i gang
5. stop hyppig polling, når batchen når en terminal tilstand

Realtime får skærmen til at føles øjeblikkelig. Polling lukker huller efter genforbindelser og giver et fallback.

De to veje bør ikke skabe konkurrerende statusregler.

Undgå at gøre opdateringer til støj

Ikke enhver intern hændelse hører hjemme i interfacet. At broadcaste hvert token, worker-heartbeat eller mellemliggende gem kan gøre siden ustabil og øge infrastrukturbelastningen.

Brugere har som regel brug for meningsfulde faseovergange og opdaterede tællinger. At gruppere hurtige lavniveauændringer i et mindre sæt holdbare milepæle holder oplevelsen rolig og overskuelig.

Det samme princip gælder for notifikationer. En fuldført batch kan fortjene opmærksomhed. Hvert fuldført locale gør sandsynligvis ikke.

Test den stille vej

Det er let at teste med realtime aktiveret og antage, at fallbacket virker. Pålidelighed kræver den modsatte øvelse:

• deaktiver broadcasting
• start en batch med flere locales
• forlad og vend tilbage til siden
• bekræft, at fremskridtet indhenter det forsømte
• prøv igen på en mislykket forespørgsel
• verificér de endelige tællinger og tilgængelige handlinger

Hvis den vej virker, er realtime en forbedring i stedet for en skjult afhængighed.

Konklusion

Live-opdateringer forbedrer oversættelsesoperationer, når de ligger oven på holdbar tilstand.

Registrér hver overgang først, gør broadcasting konfigurerbar, og behold et afmålt polling-fallback. Arbejdsgangen bør forblive troværdig, selv når den mest umiddelbare leveringskanal er utilgængelig.