Oversættelsesstatusser bør besvare det næste spørgsmål

Oversættelsessystemer producerer masser af tilstand. Jobs sættes i kø, udbydere svarer, kladder gemmes, Contentful opdateres, poster publiceres, og genforsøg starter.

At vise al den aktivitet gør ikke automatisk fremskridt tydelige.

En nyttig status bør besvare det næste spørgsmål, redaktøren har.

Én anmodning har flere livscyklusser

En flersproget anmodning bevæger sig ofte gennem tre hovedfaser:

1. oversæt
2. push
3. publicér

Hver fase kan være inaktiv, i kø, i gang, vellykket, sprunget over eller mislykket. At komprimere disse tilstande til ét enkelt ord mister vigtig information.

"Fuldført" kan betyde, at oversættelseskladde er klar til gennemgang, at målsproget blev skrevet til Contentful, eller at posten er live. Det er væsentligt forskellige resultater.

Grænsefladen bør navngive fasen og dens tilstand sammen.

Status og handling hører sammen

Redaktører læser status for at afgøre, hvad de kan gøre som det næste.

• En klar oversættelse kan gennemgås.
• En godkendt oversættelse kan pushes.
• Et vellykket push kan publiceres.
• En midlertidig fejl kan prøves igen.
• Aktivt arbejde kan muligvis annulleres.

Hvis den tilgængelige handling ikke matcher den viste tilstand, føles produktet inkonsekvent. En publiceringsknap ved siden af en anmodning, der aldrig blev pushet, er ikke blot forvirrende; det svækker tilliden til det underliggende workflow.

Backend bør afgøre tilgængelighed ud fra vedvarende tilstand og tilladelser, og derefter bør UI afspejle den beslutning konsekvent.

Fremskridtstællinger har brug for en stabil nævner

Batchfremskridt bliver misvisende, når hver fase bruger et forskelligt totalantal uden at forklare det.

En batch med ti oversættelsesanmodninger kan have ti oversættelser, otte pushes og seks publiceringer, fordi nogle sprogvarianter kun var til gennemgang, eller automatisering var deaktiveret.

Fremskridt bør skelne mellem:

• samlede anmodninger
• anmodninger, der er kvalificerede til den aktuelle fase
• fuldførte, aktive, mislykkede og oversprungne anmodninger

Oversprunget er især vigtigt. Det er en terminal beslutning, ikke ufærdigt arbejde.

Bevar historikken uden at overfylde skærmen

Den aktuelle tilstand bør forblive kompakt, men operatører har stadig brug for historik, når noget går galt.

En udvidelig hændelsestidslinje kan vise, hvornår anmodningen blev sat i kø, hvilket forsøg der mislykkedes, om et automatisk genforsøg kørte, og hvornår Contentful accepterede opdateringen. Det understøtter fejlfinding uden at forvandle hver tabelrække til en logviser.

Brug menneskeligt sprog til hovedstatussen, og behold tekniske identifikatorer og tidsstempler i detaljevisningen.

Terminale tilstande bør forblive terminale

Polling og realtime-hændelser kan ankomme i forkert rækkefølge. En ældre "i gang"-hændelse må ikke flytte en fuldført anmodning baglæns. En opdateret side bør ikke midlertidigt vise i kø, efter at databasen allerede har registreret succes.

Tilstandsovergange kræver rækkefølge og idempotens. Grænsefladen bør sammenflette opdateringer ved hjælp af det autoritative tidsstempel eller versionsnummer, ikke blot acceptere den sidste besked, der blev leveret til browseren.

Konklusionen

Statusdesign er en del af workflowet, ikke dekoration omkring det.

Adskil faserne oversættelse, push og publicering. Knyt hver tilstand til den handling, den muliggør, tæl oversprunget arbejde ærligt, og hold en detaljeret historik lige ved hånden. Den bedste status er den, der gør den næste beslutning klar.