Statusy tłumaczeń powinny odpowiadać na kolejne pytanie

Systemy tłumaczeń generują wiele stanów. Zadania trafiają do kolejki, dostawcy odpowiadają, wersje robocze się zapisują, Contentful się aktualizuje, wpisy są publikowane i uruchamiają się ponowne próby.

Pokazywanie całej tej aktywności nie sprawia automatycznie, że postęp staje się jasny.

Użyteczny status powinien odpowiadać na kolejne pytanie, jakie ma redaktor.

Jedno żądanie ma kilka cykli życia

Wielojęzyczne żądanie często przechodzi przez trzy główne fazy:

1. tłumaczenie
2. wysyłanie
3. publikacja

Każda faza może być bezczynna, zakolejkowana, w trakcie, zakończona sukcesem, pominięta lub zakończona niepowodzeniem. Sprowadzenie tych stanów do jednego słowa powoduje utratę ważnych informacji.

„Ukończone” może oznaczać, że robocza wersja tłumaczenia jest gotowa do przeglądu, że docelowe ustawienia regionalne zostały zapisane w Contentful albo że wpis jest na żywo. To zasadniczo różne rezultaty.

Interfejs powinien nazywać jednocześnie fazę i jej stan.

Status i działanie powinny iść razem

Redaktorzy odczytują status, aby zdecydować, co mogą zrobić dalej.

• Gotowe tłumaczenie można sprawdzić.
• Zatwierdzone tłumaczenie można wysłać.
• Pomyślne wysłanie można opublikować.
• Przejściowe niepowodzenie można ponowić.
• Trwającą pracę można być może anulować.

Jeśli dostępne działanie nie odpowiada wyświetlanemu stanowi, produkt wydaje się niespójny. Przycisk publikacji obok żądania, które nigdy nie zostało wysłane, jest nie tylko mylący; osłabia zaufanie do całego procesu.

Backend powinien określać dostępność na podstawie trwałego stanu i uprawnień, a następnie UI powinien konsekwentnie odzwierciedlać tę decyzję.

Liczniki postępu potrzebują stabilnego mianownika

Postęp partii staje się mylący, gdy każda faza używa innej sumy bez wyjaśnienia tego.

Partia z dziesięcioma żądaniami tłumaczenia może obejmować dziesięć tłumaczeń, osiem wysłań i sześć publikacji, ponieważ niektóre ustawienia regionalne były tylko do przeglądu albo automatyzacja była wyłączona.

Postęp powinien rozróżniać:

• łączną liczbę żądań
• żądania kwalifikujące się do bieżącej fazy
• żądania ukończone, aktywne, zakończone niepowodzeniem i pominięte

Pominięte jest szczególnie ważne. To decyzja końcowa, a nie niedokończona praca.

Zachowaj historię bez zaśmiecania ekranu

Bieżący stan powinien pozostać zwięzły, ale operatorzy nadal potrzebują historii, gdy coś pójdzie nie tak.

Rozwijana oś czasu zdarzeń może pokazywać, kiedy żądanie trafiło do kolejki, która próba się nie powiodła, czy uruchomiono automatyczne ponowienie i kiedy Contentful zaakceptował aktualizację. To wspiera debugowanie bez zamieniania każdego wiersza tabeli w podgląd logów.

W głównym statusie używaj języka zrozumiałego dla człowieka, a identyfikatory techniczne i znaczniki czasu zachowaj w widoku szczegółów.

Stany końcowe powinny pozostać końcowymi

Zdarzenia z odpytywania i w czasie rzeczywistym mogą docierać w nieprawidłowej kolejności. Starsze zdarzenie „w trakcie” nie może cofnąć ukończonego żądania. Odświeżona strona nie powinna tymczasowo pokazywać stanu zakolejkowanego, skoro baza danych już odnotowuje sukces.

Przejścia stanów wymagają porządku i idempotencji. Interfejs powinien scalać aktualizacje przy użyciu autorytatywnego znacznika czasu lub wersji, a nie po prostu akceptować ostatnią wiadomość dostarczoną do przeglądarki.

Najważniejsza myśl

Projektowanie statusów jest częścią procesu, a nie dekoracją wokół niego.

Rozdziel fazy tłumaczenia, wysyłania i publikacji. Połącz każdy stan z działaniem, które umożliwia, uczciwie licz pominiętą pracę i trzymaj szczegółową historię pod ręką. Najlepszy status to ten, który jasno wskazuje kolejną decyzję.