Literatura informatyczna: wspominki o tłumaczeniach i korektach

namiekko.pl 6 lat temu

Dawno, dawno temu zajmowałam się tłumaczeniem książek (informatycznych). Początkowo dorabiałam w ten sposób do stypendium doktoranckiego, ale nie bez znaczenia była dla mnie przyjemność płynąca z pracy z językiem oraz możliwość poznania nowych technologii. Żeby coś dobrze przetłumaczyć, należy to najpierw dogłębnie zrozumieć. Drogi na skróty nie ma.

Stan circa 2010, przed nocą oczyszczenia na moich półkach z książkami IT

Dlaczego akurat teraz piszę o tym na blogu?

Po pierwsze, z racji zalania mózgu prolaktyną (jeszcze chwilka!) nie jestem w stanie generować nowych, ciekawych tematów i chciałam odgrzać tekst ze starego bloga. Ostatecznie napisałam artykuł zupełnie od nowa.

Po drugie, odezwał się do mnie mój ulubiony redaktor z propozycją przetłumaczenia nowego wydania książki, nad którą pracowałam dobrych parę lat temu. Nie zgodziłam się (patrz punkt 1), ale zaproponowałam wykonanie korekty merytorycznej tekstu przełożonego przez nowego tłumacza. To było dla mnie zupełnie nowe doświadczenie i chcę podzielić się przemyśleniami.

Po trzecie, znajoma rozważająca wejście w obszar tłumaczeń IT zadała mi kilka pytań o tę pracę, w związku z czym musiałam przypomnieć sobie, jak to było.

Po czwarte, wreszcie, to kolejna ścieżka rozwoju w szeroko rozumianym świecie IT, a przecież o tym jest ten blog.

Jak się dostaje taką pracę?

Wydawnictwa techniczne, inaczej niż czysto literackie, miewają na stronach zaproszenie do współpracy dla tłumaczy. Szukają raczej znających język praktyków niż osób z papierami tłumacza czy filologa.

Rekrutacja polega najczęściej na przetłumaczeniu próbki (za darmo), a następnie już rozdziału książki (za pieniądze). jeżeli po tym doświadczeniu obie strony będą zadowolone, przyszły tłumacz otrzyma propozycję przekładu, kiedy pojawi się coś ze zgłoszonej przez niego dziedziny.

Cały proces może trochę potrwać, choćby kilka miesięcy.

Co jest łatwe, a co jest trudne w przekładach IT?

Kilka uwag poniżej.

1. Amerykańscy autorzy zawsze zwracają się czytelnika bezpośrednio

W pierwszych tłumaczonych przez siebie książkach stosowałam wymyślną ekwilibrystykę form bezosobowych i tradycyjnych zwrotów do “Czytelnika”, ale po jakimś czasie uznałam, iż w literaturze IT i poradnikach przyjęła się już przecież forma bezpośrednia. Problem krążenia wokół bezpośrednich zwrotów wydawał się rozwiązany.

Niestety, w tej sytuacji ujawnił się nowy problem w postaci form czasowników w czasie przeszłym oraz w trybie przypuszczającym. W języku polskim ujawniają one rodzaj gramatyczny podmiotu. Kłopotliwe stały się wszystkie sformułowania typu “if you removed line 3″ (“gdybyś usunął/usunęła linię 3”). jeżeli posiłkuję się słowem “czytelnik”, słowo to wymusza rodzaj i wszystko jest w porządku. Zwracając się do odbiorcy bezpośrednio, mam problem. Jasne, można kombinować, ale gdy autor w co drugim zdaniu używa takich zwrotów, po chwili staje się to męczące dla obu stron (dla tłumacza i czytelnika, autora zostawmy w tym wypadku w spokoju).

W niektórych angielskojęzycznych książkach programista jest kobietą – autorzy stosują zaimek “she” (istnieje jeszcze bezpieczna forma “they”, jeżeli z premedytacją odmawiamy podania płci). Po polsku to by nie przeszło. W naszym języku żeńskie formy są bardzo silnie nacechowane. Gdybym zaczęła zwracać się do czytającego książkę programisty lub studenta “jeśli miałaś kiedyś do czynienia z usługami sieciowymi”, to wprawiłabym w konsternację przedstawicieli obu płci. Techniczna książka ma się czytać płynnie i bezproblemowo.

Finalnie bez poczucia większej żenady stosuję rodzaj męski, zakładając, iż piszę do domyślnego “czytelnika”.

2. Choćby nie wiem jak dziękowali korektorom, książki i tak często są napisane niechlujnie

Klasyczny przykład to zdanie “Możesz wybierać pomiędzy poniższymi trzema dostawcami”, po którym następuja lista złożona z czterech pozycji. Tego typu błędy dość łatwo wychwycić, choć człowiek zachodzi w głowę, czym dokładnie zajmował się wymieniony z nazwiska korektor.

Niestety, problemów często jest więcej:

  • zaimki (“to”) pasujące do trzech różnych wspomnianych wcześniej bytów lub nie pasujące do żadnego,
  • niedziałający kod,
  • twierdzenia, które na pewno nie są prawdziwe,
  • fragmenty kodu niemające nic wspólnego z akapitem, który ma je opisywać,
  • w połowie urwane zdania.

Jako tłumacz zawsze starałam się zrozumieć intencje autora i poprawiałam tego typu rzeczy, jednak ostatnio (o czym niżej) przekonałam się, iż wcale nie jest to uniwersalne podejście.

3. Tłumaczenie książek napisanych po angielsku przez autorów, dla których angielski nie jest językiem ojczystym, to temat na co najmniej rozprawę doktorską

Programowanie jest dziedziną egalitarną. Nie trzeba być rdzennym Brytyjczykiem po Oxfordzie, żeby mieć wartościowy materiał na książkę informatyczną. Książki o popularnych frameworkach piszą więc Polacy i Bułgarzy, zarówno ci pracujący w swoich ojczystych krajach jak i ci na emigracji. Jednym i drugim wydaje się, iż skoro w pracy skutecznie posługują się angielskim, ich znajomość języka wystarczy do napisania książki. No cóż, nie zawsze jest to prawda.

Najgorzej jest, oczywiście, w przypadku książek wydanych własnym sumptem, których autor oszczędzał na korekcie, ale na szczęście takie dzieła rzadko kiedy się tłumaczy. W każdym razie trudno podążyć logicznie za wywodem autora, który nie widzi różnicy pomiędzy rodzajnikiem określonym a nieokreślonym, bo w jego języku nie występują ani jedne, ani drugie.

4. Rdzenni Amerykanie potrafią przyłożyć popkulturą.

Największy koszmar i blokada tłumaczeniowa spotkały mnie przy mojej pierwszej książce, ponad dziesięć lat temu. Autor określił wówczas jakąś aplikację terminem “Borg-like”. Dzisiaj Internet podpowiada nieco więcej. Wtedy tego sformułowania po prostu nie można było znaleźć w Google.

Czego się dowiedziałam po dwóch dniach kminienia? Że Borg to rasa ze Star Treka (jestem geekiem, ale w Star Trek nigdy się nie wciągnęłam, za dużo materiału do nadrobienia), która przemocą asymiluje czy wręcz “wchłania” inne rasy. O to samo można oskarżyć niektóre aplikacje.

Jest choćby taki żarcik o SP2 do Windows XP:

“Windows XP SP2 is often called Windows XP Borg Edition, as it tries to assimilate all other software (or destroys it) as is the custom with the Borg. Also common with the borg, once you install ‘Borg’ edition, resistance is futile”

5. Listingi potrafią ciągnąć się przez cztery strony…

Tłumaczowi, jak wiadomo, płaci się od “strony tłumaczeniowej”, czyli de facto od liczby znaków w wynikowym tekście. Przy listingach jest wyjątkowo mało roboty, tym bardziej, iż w tej chwili większość wydawnictw nie próbuje polonizować np. nazw zmiennych. Szybki zarobek.

6. … ale czasem trzeba z nich wygenerować spolonizowany zrzut ekranu.

Co robi się kłopotliwe, jeżeli listing zawiera błędy i kod zwyczajnie nie chce działać. Wtedy nagle jedna strona może kosztować kilka godzin.

7. Informatyczna nowomowa.

Jakiś czas temu znajomy szykował się do napisania reklamacji do wydawnictwa odpowiedzialnego za polską wersję Millenium Larssona. Otóż na tylnej okładce podobno wydanej po polsku książki pojawiają się słowa “outsiderka” i “researcherka”. Część rozmówców stanęła w obronie tłumacza, pisząc, iż “zasysanie” słów z obcych języków jest procesem naturalnym. Moim zdaniem, tendencja do zasysania obcych słów jest usprawiedliwiona, o ile słowo o danym znaczeniu nie istnieje już w języku polskim. W przeciwnym razie to zwykłe pójście na łatwiznę, niedopuszczalne zwłaszcza w wykonaniu tłumacza, czyli osoby profesjonalnie zajmującej się językiem.

W informatyce angielskie słownictwo jest wszechobecne i obezwładniające. Zgadzam się, iż wymyślanie na siłę narodowych odpowiedników jest kompletnie bez sensu. Zdarza mi się, choć nie jestem z tego dumna, używać (W MOWIE) słów takich jak “zakomitować”, “dump” albo “timeout”. Poddałam się też w końcu na słowie “framework”, z którym kiedyś próbowałam się szarpać. A jednak wiele wprowadzanych w ten sposób słów ma poprawne i zrozumiałe wersje polskie. Con za tym idzie: ie toleruję pluginów (wolę wtyczki), use case’ów (przypadki użycia), forków (rozwidlenia)… Załamuje mnie “diagram kolaboracji” (współpracy, u licha! okupacja za nami). Dla tych, którzy w tej chwili przyrzekają, iż nigdy nie tkną moich tłumaczeń: zawsze podaję wersję oryginalną, która ma ułatwić odnalezienie się osobie, która wcześniej czytała oryginalną dokumentację.

8. Miło jest trzymać w ręku przetłumaczoną przez siebie książkę…

Tłumacz dostaje do ręki egzemplarz autorski! O ile książka jest wydawana na papierze, o co coraz trudniej.

9. … mniej miło, po jej otwarciu na losowej stronie, trafić na przeoczoną wcześniej literówkę.

Co rzeczywiście zdarzyło mi się w przypadku pierwszej książki, mimo iż przeszła przez wszystkie tury korekty (techniczna, merytoryczna, językowa).

Tłumaczenia a sprawa kobieca

Wspomnę poniżej o dwóch aspektach.

1. Żeńskie końcówki

Wracając do wspomnianej powyżej “researcherki”, mam dość silną opinię na temat żeńskich końcówek w nazwach zawodów. Z całego serca ich nienawidzę! Nie rozumiem, dlaczego spory odłam feministek tak bardzo walczy o ich stosowanie.

Dla mnie lekarz to lekarz, nie ma znaczenia jego płeć, tylko kompetencje i, na bliskim drugim miejscu, styl bycia i szacunek do pacjenta. Czym się różni “pisarka” od “pisarza” – pisarz tworzy literaturę, a pisarka powieści dla pensjonarek? Jakie znaczenie ma tutaj płeć?! Sprawę w moim odczuciu dodatkowo pogarsza to, iż żeńskie końcówki często brzmią jak zdrobnienia, mniej poważne wersje pracy, którą wykonują mężczyźni. Nie chcę, nie potrzebuję.

2. Doskonałe żarciki

A skoro o żarcikach mowa, oto przykład, na który natknęłam się kiedyś w przekładanej przez siebie pozycji z branży:

var jack = { read: function(what) { console.log('I just read that ' + what) } }; var jill = { read: function(what) { console.log('You didn\'t hear it from me, but ' + what) } };

Jak wiadomo, i jak wynika z powyższego, mężczyźni zajmują się czytaniem, kobiety zajmują się plotkami. Wszyscy o tym wiedzą. I tu muszę oddać hołd mojemu redaktorowi. Zapytany, czy mogę sprowadzić te dwie osoby do jednej płci (wydawnictwo woli spolszczać imiona w przykładach, więc fragment i tak był do zmiany) odparł, iż jeżeli mi zależy, to mogę choćby je odwrócić

Sumienność, czyli dlaczego już nie polecam tłumaczy

Dwa razy poleciłam swojemu redaktorowi kolegów-informatyków, o których wiedziałam, iż znają się na rzeczy i bardzo dobrze posługują się angielskim. Dwa razy prawie się spaliłam ze wstydu, kiedy okazywało się, iż panowie poprzekraczali wyznaczone terminy w taki sposób, iż zgodnie z umową obcięto im część wynagrodzenia za przekład.

Nie wzięłam pod uwagę tego, iż jedną z najistotniejszych cech tłumacza jest sumienność, pojęcie niezbyt dobrze znane wśród programistów. Programowanie to w dużej mierze szukanie dróg na skróty, sprytnych sposobów, żeby zrobić coś szybciej, łatwiej, mniejszym nakładem sił. Usunięcie 200 linii kodu i zastąpienie ich jedną, która robi to samo (chociaż czasami załącza 3 gigantyczne biblioteki) jest powodem do dumy. Tymczasem przy tłumaczeniach po prostu się tak nie da! Trzeba przetłumaczyć wszystko, każde zdanie (no, prawie), choćby jeżeli autor przez trzy strony po prostu leje wodę, żeby nadmuchać objętość książki.

Inteligencja i rzutki umysł nie pozwolą nam usiąść do tłumaczenia po dwóch miesiącach prokrastynacji i załatwić sprawy w ciągu tygodnia. Z programowaniem czasami tak się udaje.

Czego dowiaduje się korektor

Jak już wspominałam, miałam ostatnio okazję sprawdzić się w roli korektora merytorycznego książki informatycznej. Było to dla mnie przeżycie wstrząsające, ponieważ zrozumiałam, jak różne podejście do przekładu mogą mieć różni tłumacze i jak odmiennie rozumieją swoją odpowiedzialność za tekst.

Opisywałam już powyżej swoje przygody z poszukiwaniem znaczenia terminu „Borg-like”. Utknąć nad stroną książki zdarzało mi się częściej: kiedy autor załączył niedziałający kod, a ja musiałam wygenerować screenshot, więc debugowałam i pisałam kawałki od nowa; kiedy napisał „to” i w ogóle nie było wiadomo, o co mu chodzi, więc musiałam wertować dokumentację na stronie twórcy biblioteki; kiedy podane przez niego przykłady w ogóle nie przystawały do opisywanego zagadnienia i pisałam je od nowa lub sprawdzałam, skąd je ściągnął i co dokładnie mu się pomyliło. Czułam się odpowiedzialna za jakoś tekstu, który ostatecznie podpiszę także moim nazwiskiem.

Ostatnio zasiadłam do korekty merytorycznej i zrozumiałam swoją wielką naiwność…

Co może zrobić tłumacz, kiedy oryginalne zdanie nie ma sensu? Przetłumaczyć je na polski w wersji, która również nie znaczyła zupełnie nic.

Co robi, kiedy nie działa listing i nie dało się łatwo wygenerować screenshotu? Dodaje komentarz „kod nie działa” i na tym kończy swoją pracę.

Połowa czasu spędzonego przeze mnie na „korekcie” była w rzeczywistości wprowadzaniem poprawek w dziurawym kodzie, żeby polska wersja książki, w przeciwieństwie do oryginalnej, pokazywała działające przykłady. Żebym wiedziała, iż tak można, w czasach tłumaczeniowych zarobiłam tę samą kasę w o połowę krótszym czasie.

Okazało się też, iż tłumacze techniczni potrafią mieć ego porównywalne do programistów na backendzie. Pokłóciłam się z tłumaczem o przekład słowa „immutable”, które zamienił na „niemutowalny” (patrz sekcja o nowomowie powyżej). Takiego słowa w języku polskim nie ma, natomiast moim zdaniem spokojnie działają tu „niemodyfikowalny” lub „niezmienny”. W większości tego typu dyskusji zaznaczałam swoje zalecenia i odpuszczałam, ale tutaj nie chciałam się pod czymś takim podpisać. Wtedy tłumacz poinformował mnie, iż „tak się mówi w branży”… Co rozłożyło mnie na łopatki, bo parę stron dalej nie potrafił wygenerować screenshotu z kodu, w którym jedynym problemem był brak wywołania funkcji na koniec.

Chyba napiszę w końcu osobny tekst o ego programistów.

Czy tłumaczenia informatyczne są w ogóle potrzebne?

Z jednej strony, wydaje się, iż coraz mniej. Po pierwsze, naprawdę nie sposób dziś być dobrym, oblatanym programistą bez znajomości angielskiego, a to oznacza, iż coraz więcej informatyków jest w stanie czytać książki w oryginale (chociaż przeszkodą bywa cena!). Po drugie, wiadomo, rozwój sztucznej inteligencji i tłumaczenia maszynowego sprawia, iż niektóre teksty można wrzucić do translatora i mniej więcej zrozumieć, o co chodziło autorowi.

Z drugiej strony, dzisiaj coraz więcej osób interesuje się informatyką i programowaniem. Te tematy stają się coraz bardziej powszechne i coraz silniej wchodzą w nasze życie. O chmurze, bitcoinach i Pythonie czytają nie tylko programiści, ale także starsze dzieci, księgowe i seniorzy. Dla nich obcy język, choćby angielski, jeszcze długo może być zaporą.

Co do automatycznie tłumaczonych tekstów… Translatory są dobre, jeżeli chcemy zrozumieć komunikat systemowy lub odpowiedź na forum. Książki pełne są niuansów i wstecznych odwołań… A także błędów, które tłumacz i korektor mogą skorygować, w przeciwieństwie do automatycznego translatora Wydaje mi się, iż jeszcze przez sporo lat translatory (i pamięci tłumaczeniowe CAT) będą raczej pomocą dla tłumaczy niż konkurencją dla nich.

Choć mimo wszystko odradzałabym swojemu dziecku wybór kariery tłumacza w dzisiejszych czasach.

Quiz

W ramach pół-inteligentnej rozrywki, polecam sprawdzenie, jak w różnych krajach potocznie nazywa się znak @ („małpa”).

Idź do oryginalnego materiału