Segreguj nieudane tłumaczenia bez utraty wydania

W wielojęzycznym wydaniu „niepowodzenie” nie oznacza jednego stanu.

Żądanie modelu mogło się nie powieść. Tłumaczenie może być gotowe, ale nie dać się wysłać do Contentful. Zlokalizowany wpis może być zaktualizowany, ale nieopublikowany. Zgrupowanie wszystkich trzech pod jednym czerwonym statusem upraszcza panel, ale utrudnia odzyskiwanie pracy.

Zacznij od etapu, na którym wystąpił błąd

Tłumaczenie, wysyłka i publikacja to oddzielne operacje z różnymi zależnościami.

Błąd tłumaczenia może wynikać z przekroczenia limitu czasu po stronie dostawcy, nieprawidłowej odpowiedzi modelu lub walidacji treści chronionej. Błąd wysyłki może dotyczyć uprawnień, walidacji pól lub konfliktu wersji w Contentful. Błąd publikacji może odzwierciedlać stan wpisu, konfigurację środowiska lub tryb publikacji.

Pierwszy filtr klasyfikacji powinien odpowiadać na pytanie: który etap wymaga uwagi?

To natychmiast zawęża odpowiedzialność i kolejne kroki.

Pokaż zakres wpływu

Nieudane żądanie potrzebuje wystarczająco dużo danych identyfikacyjnych, aby można było podjąć decyzję:

• nazwa i ID wpisu
• język źródłowy i docelowy
• partia
• etap, na którym wystąpił błąd
• ostatni błąd
• liczba prób i czas ostatniej próby
• czy późniejsze etapy kiedykolwiek się rozpoczęły

Bez tego kontekstu operatorzy otwierają każde żądanie osobno i ręcznie odtwarzają przebieg wydania.

Widok partii powinien również odróżniać częściowe niepowodzenie od całkowitego. Jeśli 49 z 50 wersji językowych zakończyło się sukcesem, zespół powinien móc iść dalej z ukończoną pracą, jednocześnie odzyskując jedno żądanie.

Ponawiaj od właściwej granicy

Ponowienie powinno wznowić etap, na którym wystąpił błąd, a nie powtarzać każdy wcześniejszy etap zakończony sukcesem.

Jeśli tłumaczenie się udało, a wysyłka nie, zachowaj sprawdzone tłumaczenie i ponów wysyłkę. Jeśli Contentful został zaktualizowany, a publikacja się nie udała, ponów publikację względem bieżącego stanu wpisu.

Restart od tłumaczenia może spowodować powstanie innej treści, unieważnić przegląd, zwiększyć koszt i ukryć pierwotny problem.

Ponowienia świadome etapów utrzymują udaną pracę w stabilnym stanie.

Oddziel błędy przejściowe od trwałych

Niektóre błędy są dobrymi kandydatami do automatycznego ponowienia:

• przekroczenia limitu czasu po stronie dostawcy
• limity szybkości
• krótkie przerwy sieciowe
• możliwe do odzyskania konflikty wersji

Inne wymagają człowieka:

• nieprawidłowa konfiguracja treści
• brak włączonej obsługi języka
• odmowa uprawnień
• chroniona struktura, której nie da się przywrócić
• pole docelowe zmienione po przeglądzie

Polityka ponowień powinna być ograniczona i widoczna. Po osiągnięciu automatycznego limitu żądanie powinno trafić do kolejki obsługiwanej przez człowieka z zachowaniem ostatniego użytecznego błędu.

Utrzymuj listę błędów lekką

Ekrany operacyjne są używane wtedy, gdy coś już idzie nie tak. Nie powinny wywoływać głębokiego hydratowania CMS dla każdego wiersza ani odpytywać tak agresywnie, by strona generowała większe obciążenie niż procesy robocze, które monitoruje.

Najpierw zwracaj stabilne metadane żądań. Pełne szczegóły wpisu pobieraj dopiero wtedy, gdy operator otworzy żądanie.

Szybkie filtrowanie jest częścią odzyskiwania.

Wniosek

Czerwony znacznik nie jest systemem odzyskiwania.

Oddzielaj błędy według etapu, pokazuj zakres wpływu i ponawiaj tylko operację, która się nie powiodła. Automatyzuj odzyskiwanie błędów przejściowych w jasno określonych granicach i zachowuj użyteczne błędy dla wszystkich pozostałych przypadków. Zespoły mogą tolerować pojedyncze niepowodzenia, gdy workflow sprawia, że kolejna decyzja jest oczywista.