Swego czasu zapowiedziałam na fejsbuku, że
jak będę duża, to napiszę monografię pt. „Dlaczego lokalizacja oprogramowania nie polega na wyciągnięciu z kodu wszystkich trzystu tysięcy stringów, wklejeniu ich do Excela, posortowaniu alfabetycznie, wycięciu duplikatów i wysłaniu do tłumacza bez podania nazwy i przeznaczenia lokalizowanego narzędzia”.
[Disclaimer dla nienerdów: stringi słusznie kojarzą się Wam z bielizną damską (dziękuję, preferuję szorty biodrówki), ale tu chodzi po prostu o składające się na interfejs programu ciągi znaków, zwane również łańcuchami, pozdrowienia dla pana Płoskiego].
Nie wiem, czy już jestem wystarczająco duża, ale nadal dobrze pamiętam pierwszy duży projekt lokalizacyjny, przy którym pracowałam, było to grube kilkanaście lat temu i polegało właśnie na tłumaczeniu stringów, tyle że z takim jeszcze zabawnym ograniczeniem, że tłumaczenie nie mogło być dłuższe od oryginału. Nazwę firmy i produktu pominę, ale jak ktoś trafił kiedyś na system, w którym okienka zamykało się przyciskiem „Wyj.”, to wie. I zapewne wył — jako i ja wyłam.
Wydawałoby się jednak, że wspomniane grube kilkanaście lat to sporo i wiele się w tym czasie w metodologii software developmentu zmieniło. W tłumaczeniach zmieniło się na pewno, mamy koty, Google Translate, DeepL i tłumaczenia maszynowe, big data i dyskusje o tym, kiedy maszyna zastąpi człowieka i dlaczego (nie) musimy się tego bać. Ale metoda z obrabianiem listy stringów w Excelu trzyma się mocno.
Nie, oczywiście że nie wszędzie. Różne firmy z różnym powodzeniem powdrażały różne narzędzia, które (w zamierzeniu, a czasem i w praktyce też) mogą naprawdę ogromnie ułatwić lokalizację. Zdarza się nawet, że tłumacz może sobie tłumaczonego oprogramowania naprawdę poużywać. Zdarza się też, że robi się rzetelną kontrolę jakości tłumaczenia (o czym może przy innej okazji) i korektę finalnego produktu (że czasem polega to na malowaniu po zrzutach ekranu? No doprawdy, nie bądźmy drobiazgowi). Ale równie często zdarza się, że nie. Po prostu nie.
Dlaczego to jest złe? Trzy powody: kontekst, kontekst, kontekst. I czwarty: fleksja. I piąty, który został już po mistrzowsku omówiony tu: your $variable will not work in Polish (no, it really won’t).
Angielski jest prosty. Na lewo, do lewej, po lewej, lewy, lewa, lewe, lewej, lewemu, lewym, lewych, wyszedł, porzuciła i jeszcze do tego pozostało — wszystko da się poprawnie wyrazić jednym słowem: left. W drugą stronę to niestety nie działa i żeby przetłumaczyć to left dobrze, naprawdę muszę zobaczyć, gdzie się znajduje na ekranie i do czego służy. Tak samo jest z right (wyrównaj do prawej? przepis prawa? uprawnienie użytkownika? dobrze, masz rację?) i setkami innych słów, które się w interfejsie przeciętnego programu pojawiają wiele, wiele razy. Tak, może się tak zdarzyć, że na dziesięć wystąpień słowa access każde będzie trzeba przetłumaczyć inaczej. I to nie będzie błąd ani nawet rażące niezachowanie spójności terminologii. Że się nie da, bo przed wysłaniem tabelki do tłumacza wycięto z niej duplikaty? Ojej.
Polski nie jest prosty. Mamy na przykład śmieszne zasady dotyczące liczebników i rzeczowników. Każdy z nich może mieć mniej więcej $number wariant(-y/-ów), gdzie $number jest dowolną liczbą całkowitą. To ile osób skomentował(-a/-y/-o) Twój ostatni post?
Polski nie jest prosty. Mamy siedem przypadków, z których co najmniej sześciu używamy na co dzień (wołaczu, nie wymieraj!). Mamy dwie liczby, trzy rodzaje i ładnych kilka wariantów deklinacji. Plus wyjątki. Nie ma takiej siły, żeby dało się te wszystkie możliwe formy opędzić jednym $adjective $noun(s).
Polski nie jest prosty. Każdy czasownik rządzi swoim dopełnieniem bliższym i dalszym, a robi to w sposób autokratyczny i fanaberyjny. Próba ułatwiania sobie życia przez konstrukcje w rodzaju Send file to $device, gdzie $device = (disk,memory,email client,webpage,calendar,trash,whatever), to przepis na (wcale nie piękną) katastrofę.
Ale oczywiście, czasy są ciężkie, dedlajny napięte, żyć trzeba a Klient(ka) nasz(a) pan(i). Nawet jak jest niewychowywalny, nawala u niego myślenie, czytanie ze zrozumieniem i komunikacja a jeszcze wczoraj myślał, że inflection to nazwa choroby skóry.
Reasumując, drogi czytelniku: jeśli następnym razem zobaczysz, że apka na Twoim smartfonie mówi do Ciebie słuchać! albo przeczytasz coś o latających daktylach i o tym, że w Morzu Północnym żyją ryby, delfiny i uszczelniacze, pomyśl sobie o tym nieszczęsnym tłumaczu, który kopał się z tabelką w Excelu jak z koniem. I być może nawet miał dość czasu i siły, żeby zapytać o to, w jakim kontekście występuje to listen albo seal, jaka to jest część mowy i w którym miejscu na ekranie się pojawia, ale w odpowiedzi na to pytanie — i szereg innych podobnych — dostał jedynie poradę please tlanslate litelally lub, jeszcze lepiej, OK. Albo, nader powszechna praktyka, w ogóle nic.
I jeszcze na deser plotka-anegdotka o tym, jak w pewnej korporacji wymyślono, żeby lokalizować produkty za pomocą narzędzia, które pozwoli tłumaczom na bieżąco podglądać kontekst produkowanego właśnie tłumaczenia. I projekt został uwalony z powodu „braku wartości biznesowej”.
Pewnie, że to nie ma wartości biznesowej. Łatwiej zlecić tłumaczenie tabelki z Excela, potem wygenerować z tego zlokalizowaną wersję interfejsu i dać do sprawdzenia wewnętrznie jakiemuś pseudonatiwowi biorącemu 8 złotych za godzinę, który stwierdzi oczywiście, że wyszły bzdury (gdyż, jak powszechnie wiadomo, jak dasz śmieci, nie dostaniesz mahoniu, diamentów ani długo dojrzewającego parmezanu). Zareklamować więc jakość w biurze tłumaczeń i zapłacić dwie trzecie wcześniej uzgodnionej kwoty, zlecić poprawę największych baboli wspomnianemu pseudonatiwowi i w końcu wypuścić produkt na rynek. I będzie dobrze i tanio i wszyscy będą zadowoleni, a te tłumacze to, proszę panią, niekompetentne barany są i w ogóle to przesąd, że się nie pisze 27 luty, posiadać duże znaczenie ani użyj tą funkcjonalność.