Wykrywanie zmian w źródle utrzymuje uczciwość przeglądów tłumaczeń

Tłumaczenie może być poprawne, a mimo to nieaktualne.

Dzieje się tak, gdy redaktor zmienia wpis źródłowy po rozpoczęciu tłumaczenia. Zlokalizowany szkic nadal odzwierciedla pierwotny stan, ale ekran przeglądu może pokazywać najnowszą wersję źródła. Jeśli przepływ pracy nie oznaczy tej różnicy, recenzent może zatwierdzić dwa fragmenty treści, które w rzeczywistości nigdy nie zostały ze sobą porównane.

Wykrywanie zmian w źródle zapobiega przedostaniu się tej cichej rozbieżności do wydania.

Tłumaczenie zaczyna się od migawki

Każde żądanie tłumaczenia ma granicę źródła: zestaw pól, wartości i struktur rich-text w określonym momencie.

Ta migawka powinna zostać zapisana wraz z żądaniem. Wyjaśnia, co otrzymał model, co ocenia recenzent i dlaczego szkic docelowy mówi to, co mówi.

Ponowne pobranie źródła do wyświetlenia jest przydatne, ale nie może zastąpić historycznej migawki. Przepływ pracy potrzebuje obu rzeczy:

• źródła użytego do wygenerowania szkicu
• bieżącego źródła w CMS

Bez pierwszego szkic nie ma wiarygodnego pochodzenia. Bez drugiego zespół nie może zobaczyć, że strona poszła już dalej.

Nie każda zmiana unieważnia wszystko

Sam znacznik czasu może powiedzieć, że wpis się zmienił, ale nie wskaże, czy tłumaczenie jest nieaktualne.

Redaktor może zaktualizować wewnętrzną notatkę, dodać zasób do pola nielokalizowanego albo poprawić pole, które nie było uwzględnione w żądaniu. Takie zmiany nie powinny koniecznie blokować zlokalizowanego szkicu.

Zamiast tego porównuj na poziomie tłumaczonego pola. Jeśli zmienił się tytuł źródłowy, oznacz szkic tytułu jako nieaktualny. Jeśli zmieniła się tylko treść, zachowaj zatwierdzony tytuł bez zmian i przywróć treść do ponownej uwagi.

Wąskie unieważnianie pozwala zachować ukończoną pracę, jednocześnie jasno pokazując pozostałe ryzyko.

Pokaż recenzentom rzeczywistą różnicę

„Źródło uległo zmianie” to ostrzeżenie, a nie decyzja.

Recenzenci muszą zobaczyć, co zmieniło się między pierwotną migawką a bieżącą wartością. W przypadku zwykłego tekstu może wystarczyć porównanie na poziomie słów. W przypadku rich text porównanie powinno także ujawniać zmiany strukturalne, takie jak usunięty link, nowy element listy lub inny osadzony wpis.

Przydatne pytanie nie brzmi po prostu, czy ciągi znaków się różnią. Chodzi o to, czy zatwierdzony tekst docelowy nadal wiernie oddaje bieżące źródło.

Daj zespołowi świadome wybory

Gdy zmieni się tłumaczone pole źródłowe, przepływ pracy może zaoferować niewielki zestaw jasnych ścieżek:

1. zachować bieżące tłumaczenie, gdy zmiana nie wpływa na znaczenie
2. ręcznie edytować zlokalizowany szkic
3. wygenerować ponownie tylko pole, którego dotyczy zmiana
4. odesłać żądanie z powrotem do tłumaczenia, gdy zmiana jest szeroka

Wybór i recenzent powinni zostać zapisani. Ostrzeżenie o nieaktualności, które można odrzucić bez śladu audytowego, łatwo zignorować pod presją wydania.

Sprawdź ponownie przed wysłaniem

Przegląd może rozpocząć się przy zgodnej treści źródłowej i zakończyć po tym, jak trafi kolejna edycja.

Uruchom porównanie źródła ponownie bezpośrednio przed wysłaniem do CMS. Ta ostatnia kontrola zamyka lukę między zatwierdzeniem a dostarczeniem. Powinna używać tych samych reguł na poziomie pól co ekran przeglądu i zatrzymywać tylko te zapisy, których dotyczy problem.

W przypadku zautomatyzowanej publikacji ta kontrola jest jeszcze ważniejsza. Automatyzacja usuwa moment ludzkiej pauzy, więc system musi precyzyjnie określać, którą zatwierdzoną migawkę jest gotów opublikować.

Najważniejszy wniosek

Przegląd tłumaczenia jest wiarygodny tylko wtedy, gdy źródło poddawane przeglądowi jest tym samym źródłem, które posłużyło do utworzenia szkicu.

Zapisz pierwotną migawkę, porównaj ją z bieżącymi wartościami w CMS, identyfikuj zmiany według pól i pozwól recenzentom świadomie rozstrzygać istotne różnice. Wykrywanie zmian w źródle nie spowalnia lokalizacji. Zapobiega temu, by zespoły z przekonaniem publikowały wczorajszą odpowiedź na dzisiejszą treść.