Lista kontrolna niezawodności tłumaczeń Contentful

Tłumaczenie może być językowo znakomite, a mimo to nie przejść wydania.

Mógł zostać użyty niewłaściwy migawkowy stan źródła. Struktura rich text mogła się zmienić. Zatwierdzona wartość mogła nie dotrzeć do Contentful. Aktualizacja może być obecna, ale nieopublikowana. Niezawodność wynika z ochrony całej ścieżki, a nie z optymalizowania jednej odpowiedzi modelu.

Przed tłumaczeniem

Zacznij od jasno określonej granicy źródła.

• zidentyfikuj dokładny wpis i środowisko Contentful
• zapisz lokalizację źródłową i docelową
• wczytaj tylko pola kwalifikujące się do tłumaczenia
• zachowaj linki, osadzenia, znaczniki i strukturę nietłumaczalną
• zarejestruj model, prompt i zasady terminologiczne
• pokaż, czy uwzględniono puste pola źródłowe

Jeśli zakres żądania jest niejednoznaczny przed generowaniem, każda późniejsza faza dziedziczy tę niejednoznaczność.

Podczas generowania

Wywołanie dostawcy powinno być obserwowalne i wystarczająco powtarzalne, aby wspierać przegląd.

Zweryfikuj, że odpowiedź zawiera każde oczekiwane pole i chroniony placeholder. Odrzucaj nieprawidłowe dane strukturalne zamiast próbować zapisywać fragmenty, które wyglądają wiarygodnie.

Ponowienia powinny wykorzystywać ten sam zakres żądania. Jeśli wybrano inny model lub prompt, traktuj wynik jako nową próbę, aby recenzenci mogli zrozumieć, dlaczego wersja robocza się zmieniła.

Podczas przeglądu

Przegląd wymaga trzech stanów obok siebie:

1. wartości źródłowej użytej do tłumaczenia
2. bieżącej wartości docelowej w Contentful
3. proponowanej zlokalizowanej wersji roboczej

To ujawnia nieaktualne dane źródłowe i chroni istniejącą pracę lokalizacyjną.

W przypadku rich text sprawdzaj zarówno język, jak i hierarchię. Otwórz podgląd CMS przed zatwierdzeniem, gdy układ, linki lub osadzona treść wpływają na stronę.

Edycje wprowadzone przez recenzenta powinny stać się częścią zapisanej historii wersji roboczych, zamiast znikać w końcowym pushu.

Podczas pushu

Zapisuj możliwie najmniejszą zmianę.

Pushuj tylko zatwierdzone pola lokalizacji docelowej. Ponownie pobierz bieżący wpis Contentful, zachowaj niezwiązane wartości i użyj najnowszej wersji wpisu. Jeśli to samo pole docelowe zmieniło się po rozpoczęciu przeglądu, zatrzymaj się, aby podjąć decyzję, zamiast automatycznie je nadpisywać.

Zarejestruj, które pola Contentful zaakceptował i kiedy. Pomyślna odpowiedź API powinna zostać odwzorowana na trwały stan żądania, zanim UI ogłosi zakończenie.

Podczas publikacji

Push i publikacja to odrębne wyniki.

Potwierdź, że wpis kwalifikuje się do skonfigurowanego trybu publikacji i że użytkownik ma uprawnienia do publikowania. Jeśli publikacja jest automatyczna, zachowaj niezależność jej niepowodzenia od powodzenia tłumaczenia i pushu.

Żądanie powinno wyraźnie pokazywać „wypchnięto, publikacja nie powiodła się”, zamiast sprowadzać cały przepływ pracy do ogólnej awarii.

Podczas odzyskiwania

Niezawodne systemy zakładają, że dostawcy przekraczają limity czasu, sieci przerywają, a wersje CMS wchodzą w konflikt.

• ponawiaj błędy przejściowe w ograniczonych granicach
• wznawiaj od nieudanej fazy
• zachowuj nienaruszone udane tłumaczenia i pushy
• pokazuj najnowszy błąd, na który można zareagować
• pozwalaj na anulowanie tam, gdzie aktywna praca może zostać bezpiecznie zatrzymana
• spraw, by stan końcowy można było odzyskać przez odpytywanie nawet bez zdarzeń czasu rzeczywistego

Odzyskiwanie powinno zachowywać wykonaną pracę, a nie odruchowo ją restartować.

Najważniejszy wniosek

Nie ma jednej funkcji niezawodności dla tłumaczeń Contentful.

Zaufanie wynika z precyzyjnych zabezpieczeń na każdej granicy: jawnego zakresu, chronionej struktury, porównywalnych stanów przeglądu, minimalnych zapisów, oddzielnego stanu publikacji i odzyskiwania świadomego faz. Gdy te mechanizmy działają razem, zespoły mogą działać szybko, nie traktując każdego wielojęzycznego wydania jak hazardu.