Tłumaczenie maszynowe: wywiad z Martą Bartnicką – informatykiem i specjalistką w tej dziedzinie

MARTA BARTNICKA – informatyk (nie tyczka, jak sama mówi), specjalizująca się w lokalizacji i tłumaczeniu maszynowym.

Tłumaczenie maszynowe większości ludzi kojarzy się z Google Translate i śmiesznymi wpadkami (na przykład publikowanymi na Engrish.com). A jak to jest naprawdę i czy lokalizację i MT je się łyżkami? Zapytałam Martę o kilka najbardziej interesujących kwestii – zapraszam na rozmowę o białku, seksie i kontekście!

Na początek coś, co wszyscy chcą wiedzieć: kiedy tłumaczy białkowych zastąpi MT z AI, a branża wymrze i na forach dla tłumaczy będą toczyć się krzaki rodem z westernów?

Jeszcze nie. Na standardowe pytanie o zmierzch zawodu tłumacza odpowiadam równie standardowo, że to nie zmierzch – to kurz od eksplozji. Na razie MT – paradoksalnie – nakręca rynek lokalizacji i dostarcza więcej pracy tłumaczom białkowym. Działa to mniej więcej w ten sposób, że MT (coraz lepsze, coraz bardziej dostępne) wymiata „doły” – hektary stron serwisowych, czatboty, komentarze w sklepach internetowych i inne (proszę wybaczyć) śmietniki, czyli miejsca, gdzie na tłumaczenie profesjonalne i tak nie byłoby ani czasu, ani budżetu. Przy tym rośnie apetyt użytkowników na komunikację w ich własnym języku, przez co tłumacze są potrzebni tam, gdzie jeszcze parę lat temu użytkownik grzecznie akceptował angielski, by nie rzec – chiński. Do tej kategorii należą najczęściej czytane strony serwisu, FAQ czatbota czy katalog produktów w sklepie. Nawet jeśli użyjemy tu MT, to jako materiału wstępnego do postedycji, czyli mówiąc po ludzku – jako podpowiedzi, którą fachowo zredaguje tłumacz jak najbardziej białkowy.

W MT z AI, czyli sztuczną inteligencją, udał się spory skok technologiczny, jakim jest neural MT – to znaczy do powszechnego użytku weszły maszyny wytrenowane na pracy tłumaczy, z mechanizmem uczenia opartym na sieci neuronowej. Neural MT ulęgło się kilka lat temu w mateczniku uczelni i projektów rozwojowo-badawczych, a w 2017 roku dokonał się skok właściwy: na rynek. Neural MT wdrażają wszyscy po kolei – Google, Facebook, Kantan czy IBM Watson. W zeszłym roku wystartował też czarny koń maszynówki – niemiecki DeepL.

Zatem skok się udał. Neural MT jest zauważalnie lepsze od poprzedniej generacji (czyli MT statystycznego – SMT), zwłaszcza pod względem płynności językowej i „wychwytywania” gramatyki/frazeologii języka, na który tłumaczy. Pod względem kompletności i dokładności tłumaczenia jest przynajmniej nie gorsze niż starsze SMT. A co z tym robią dostawcy nowej technologii maszynowej? Zaczynają na niej zarabiać! Przewiduję, że NMT nie będzie się w najbliższym czasie jakoś gwałtownie zmieniać na lepsze. Zapewne w zaciszu akademickich serwerowni szykuje się jakaś kolejna generacja, ale dowiemy się o niej dopiero za jakiś czas. Swoją drogą, „zacisze” to w tym przypadku wyjątkowo kiepska metafora: NMT generuje się na potężnych serwerach, a takie nie kojarzą się z pracą bezszmerową. Wspomniana firma DeepL chwali się farmą serwerową w Islandii, gdzie jest tani prąd i dobre chłodzenie.

Czy polski rzeczywiście jest „trudny” dla MT? Oprócz oczywistej kwestii odmiany, czy jest coś, co szczególnie przeszkadza w tworzeniu reguł w silnikach?

Seks, chciałam powiedzieć gender, a konkretnie – rodzaje. Polski jest trudny dla MT mniej więcej tak samo, jak wszystkie języki słowiańskie, czyli grupa o dość bogatej morfologii. Jeszcze jeden aspekt: duża liczba przestawień wyrazów, jakie trzeba wykonać, żeby przekształcić przeciętną frazę angielską w polską czy rosyjską; języki romańskie – hiszpański, włoski czy rumuński – są (w parze z angielskim) znacznie łatwiejsze dla maszyny. MT z hiszpańskiego na angielski czy z angielskiego na rumuński wypadało przyzwoicie już na etapie SMT.

Ale nie mamy najgorzej: języki aglutynacyjne (węgierski, fiński) to jest dopiero zabawa! Branża MT patrzy z utęsknieniem, kto pierwszy wyjdzie przed szereg z wystarczająco dobrym NMT obejmującym grupę ugrofińską. Spore nadzieje pokładam w MT współfinansowanym przez Komisję Europejską (eTranslation), przy którym podjęto decyzję, żeby przejście z SMT na NMT zacząć właśnie od najtrudniejszych par językowych.

Jak trafiłaś do lokalizacji/MT?

Dla pieniędzy. Po studiach informatycznych na Politechnice Wrocławskiej pracowałam w zawodzie, to znaczy jako programistka (taka sobie), dorabiając tłumaczeniami technicznymi. Kiedy przychody z fuchy przekroczyły pensję bodaj trzykrotnie, wykonałam krótki proces tentegowania w głowie, pożegnałam się z kodowaniem (zachowując parę świetnych wspomnień ze świata młodego polskiego biznesu) i na dobre przeszłam do lokalizacji.

Zaczęło się śmiesznie, bo zlecenie „będziesz wyrównywać okienka po tłumaczeniu” okazało się półrocznym prowadzeniem projektu lokalizacyjnego liczonego w milionach słów (ktoś jeszcze wie, co to był OS/2 Warp wersja 4, nazwa kodowa Merlin?), a potem już poszło z górki.

MT to prosta konsekwencja: weszło do branży, trzeba było sprawdzić i wdrażać. I tu przydało się przygotowanie politechniczne, bo chociaż bez dłuższego szkolenia nie umiałabym postawić serwera MT (ani poprzedniej, ani nowej generacji), to rozumiem, co jest napisane w specyfikacji, a przede wszystkim – co mówi do mnie główny technolog od danego rozwiązania. Podstawy lingwistyki komputerowej pomagają też wdrożyć procedury oceny MT (pomaga/przeszkadza tłumaczowi? którą maszynę wybrać? dlaczego generuje takie, a nie inne błędne tłumaczenia?), bo metody liczenia podobieństwa tekstów wymyślono na długo przed NMT, Google’em czy CAT-ami.

Posłuchaj rozmowy z Martą Bartnicką oraz Agenorem Hofmannem-Delborem w podcaście \”PRZEtłumacze\”!

Bardzo często lokalizacją zajmują się biura/tłumacze bez pojęcia o tym, czym ona jest – to takie „inne tłumaczenie”. Ale jak się tej lokalizacji nauczyć, gdzie szukać pomocy, inspiracji, źródeł, konferencji, książek?

Nie umiem odpowiedzieć na to pytanie bez autopromocji. Podręcznik do lokalizacji oprogramowania, który wydaliśmy w 2017 roku (nakładem Helionu) wspólnie z dr. Agenorem Hofmannem-Delborem, to wciąż jedyna taka pozycja na polskim rynku: https://helion.pl/ksiazki/programisci-i-tlumacze-wprowadzenie-dolokalizacji- oprogramowania-agenor-hofmann-delbor-marta-bartnicka,protlu.htm Jeśli pojawiła się ciekawa alternatywa, to chętnie się o niej dowiem!

Kurs/warsztaty z lokalizacji oprogramowania współprowadzę z wyżej wymienionym, pod szyldem Localize.pl

Oczywiście poszczególne biura prowadzą własne szkolenia z lokalizacji oprogramowania, a producenci narzędzi CAT oferują lekcje wprowadzające do obsługi typów plików właściwych dla oprogramowania. Widziałam też w Internecie kursy ogólnodostępne, niestety jeszcze nic po polsku. Może nie było komu przetłumaczyć interfejsu? Jeśli chodzi o miejsca, gdzie ja jeżdżę się uczyć, to wymienię trzy: Translation and Localization Conference, soap! i EAMT.

Jakie najczęstsze babole popełniają: inżynierowie plików, tłumacze, osoby obsługujące projekty lokalizacyjne?

Od ponad 20 lat te same! Programiści na przykład piszą interfejs i komunikaty, łącząc teksty dynamicznie. Co ciekawe, robią to nawet Słowianie, bardzo szybko zapominając, że od wczesnego dzieciństwa posługują się językiem fleksyjnym. Narzędzie zbrodni wygląda mniej więcej tak:

String1=New
String2=Open
String3=Save
String4=Configuration
Option1=String1+String4
Option2=String2+String4
Option3=String3+String4

…a ofiarą pada interfejs nawet po bezbłędnym tłumaczeniu:

Inną chroniczną, nawracającą przypadłością branży lokalizacyjnej jest dostarczanie tekstów (stringów) do tłumaczenia oprogramowania w Excelu, najlepiej posortowanym alfabetycznie. Dlaczego robią to programiści, inżynierowie, biura tłumaczeń? Bo robił tak tatko, tatki tatko i jego tatko też. Bo tłumacze i CAT-y to przecież umieją albo w Worda, albo w Excela, prawda? No więc wcale nie, od dość dawna umieją też w .properties Javy, w przeróżne XML-e, w JSON-a i inne fikuśne formaty. Albo dają się nauczyć. Wywalenie tekstów do Excela to utrata kontekstu, często też komentarzy od autora, a dodatkowo ryzyko pomyłki przy przenoszeniu tego z powrotem do właściwego formatu.

Dużo ciekawych możliwości spaprania daje też oddzielne tłumaczenie interfejsu użytkownika (UI) od pomocy do niego (UA) – niepojęte, ale pomysł zatrudnienia do tego dwóch oddzielnych firm albo ekip ma się świetnie i powraca z przygnębiającą regularnością. Zawsze mówię tłumaczom, że użytkownik naciskający F1 czy zerkający do pomocy w Internecie już ma jakiś problem, więc może nie czyńmy jego życia jeszcze cięższym? Rozwiązaniem nudnym, pracochłonnym, ale skutecznym jest np. utrzymywanie słownika opcji interfejsu i dostarczanie go tłumaczom plików pomocy.

I na koniec KKK, czyli Kontekst, Koniecznie Kontekst! W lokalizacji oprogramowania, a coraz częściej też na stronach internetowych i nawet w dynamiczniej generowanej dokumentacji, o kontekst bywa trudno. Rzetelny programista ułatwia życie tłumaczowi, dodając komentarze. Z takiego komentarza można się np. dowiedzieć, że tajemniczy tekst {0} at {1} oznacza „{dnia} o {godzinie}”, czyli „at” należy przełożyć na „o”, a nie „na”, „w” czy inny potencjalnie pasujący przyimek. Tłumacz skorzysta z tego udogodnienia, jeśli zadziała cały łańcuszek: programista skomentuje, CAT umożliwi podejrzenie komentarza, a osoba przygotowująca paczkę do tłumaczenia należycie skorzysta z tej możliwości.

Czego Państwu i sobie życzę!

_______________________

Wywiad został przeprowadzony przez Panią Tatianę Saternus na łamach fanpage\’a Babole.