Baza wiedzy w kilku językach naraz - co się rozjeżdża i jak to upilnować

Nie całe wpisy się starzeją naraz - najpierw psują się detale. Nazwa przycisku zmienia się w produkcie, a w czterech z pięciu wersji językowych wciąż widnieje stara. Zrzut ekranu pokazuje interfejs sprzed redesignu, bo zrobiono go raz, przy pierwszym tłumaczeniu, i nikt nie wrócił, żeby go odświeżyć w każdej wersji osobno. Krok w procedurze, który zniknął z produktu, wciąż jest opisany w języku, którego akurat nikt nie przeglądał przy ostatniej zmianie. Żadna z tych rzeczy osobno nie wygląda poważnie. Razem oznaczają, że wersja językowa, którą rzadziej czyta zespół wsparcia, cicho oddala się od tego, co produkt faktycznie dziś robi.

Największe straty biorą się nie z tego, że tłumaczenia są złe, tylko z tego, że nikt nie wie, że akurat to jedno wymaga poprawki. Pomaga jedna zasada: zmiana w wersji źródłowej nigdy nie kończy się na samej wersji źródłowej - kończy się na oznaczeniu powiązanych tłumaczeń jako „do przejrzenia", nawet jeśli poprawka poczeka tydzień. Pary językowe trzymane razem (ten sam wpis w różnych wersjach powiązany jednym identyfikatorem) dają coś więcej niż porządek w panelu - dają możliwość zapytania wprost: które wersje tego wpisu nie były aktualizowane odkąd zmienił się oryginał. Bez takiego powiązania odpowiedź na to pytanie wymaga przeglądania każdej wersji ręcznie, co w praktyce nie dzieje się nigdy. Zmiana kosmetyczna (literówka, jedno zdanie) i zmiana merytoryczna (inny krok w procedurze, inna cena, inna nazwa funkcji) to nie ta sama operacja - tylko ta druga naprawdę wymaga, żeby ktoś, kto zna dany język, przeczytał wpis jeszcze raz, a nie tylko podmienił jedno słowo.

Kilka sygnałów, które widać, zanim ktokolwiek przeczyta wpis linijka po linijce i zauważy różnicę: Data ostatniej aktualizacji wpisu w jednym języku jest wyraźnie starsza niż w pozostałych, choć temat od tamtej pory się zmienił - to znak, że akurat ta wersja wypadła z cyklu przeglądów. Zgłoszenia do supportu w jednym języku wracają do tego samego tematu częściej niż w pozostałych, mimo że wpis w bazie wiedzy formalnie na niego odpowiada - zwykle oznacza to, że odpowiedź w tym języku nie pasuje już do obecnej wersji produktu, więc klienci i tak piszą do człowieka. Terminologia w obrębie jednego języka rozjeżdża się między wpisami - ta sama funkcja nazywana jest inaczej w starszym i nowszym artykule, bo tłumaczyły je różne osoby w różnym czasie bez wspólnego słownika pojęć.

Jeden język źródłowy, z którego tłumaczone są pozostałe - bez jasno wskazanego oryginału każda wersja prędzej czy później zaczyna żyć własnym życiem, bo nie wiadomo, względem czego ją porównywać. Wspólny identyfikator łączący wersje tego samego wpisu, żeby dało się zapytać o parę, a nie przeglądać język po języku osobno. Krótki, żywy słownik najważniejszych pojęć produktu per język - nie po to, żeby każdy tłumaczył identycznie, tylko żeby nie trzeba było zgadywać, czy „zgłoszenie" i „ticket" w danym języku to na pewno to samo słowo w każdym artykule. Przegląd nie całej bazy na raz, tylko wpisów powiązanych z tym, co akurat zmieniło się w produkcie - to jedyny przegląd, który realnie się odbywa, bo jest mały i konkretny.

Samo posiadanie wpisu w sześciu językach nie znaczy, że klient w każdym z nich dostaje tę samą jakość odpowiedzi - jeśli jedna wersja jest aktualizowana co tydzień, a pozostałe raz na kwartał, różnica w doświadczeniu klienta jest realna, nawet jeśli w panelu wygląda to na komplet. To też nie jest coś, co rozwiąże samo tłumaczenie maszynowe bez przeglądu - ono poprawia tempo pierwszej wersji, nie pilnuje, czy ta wersja za pół roku wciąż opisuje prawdziwy produkt.

Wielojęzyczna baza wiedzy nie rozjeżdża się dlatego, że ktoś źle przetłumaczył - rozjeżdża się dlatego, że zmiana w jednym miejscu nie ma żadnego sposobu, żeby dotrzeć do pozostałych pięciu. Powiązanie wersji, jeden język źródłowy i przegląd skupiony na tym, co się zmieniło, kosztują mniej niż jedna źle poprowadzona rozmowa z klientem, który trafił na nieaktualną odpowiedź.