RADY DLA TŁUMACZY
Sławomir Dzieniszewski

1. Systematyczność i organizacja        

To co często ratuje skórę początkującemu tłumaczowi to pewna elementarna systematyczność w pracy: proste i na pozór zbędne zabiegi organizacyjne. Mam tu na myśli tworzenie odpowiedniej struktury katalogów, zarówno na dysku, jak i w programie pocztowym, przygotowanie szablonów, słowników, itp. W przypadku wszelkiego rodzaju tekstów specjalistycznych szczególnie ważne jest przygotowywanie prywatnego słowniczka do książki.

Ma on trzy podstawowe zalety:

• Przypomina, w jaki sposób tłumaczyliśmy dany termin we wcześniejszych partiach książki.
• Jeśli tłumaczymy książkę zespołowo, ułatwia ujednolicanie stosowanej terminologii z innymi tłumaczami.
• U tłumaczy leniwych wymusza sprawdzanie w słownikach dokładnego znaczenia tłumaczonych terminów.

Oto przykład takiego słownika. Oczywiście każdy tłumacz może przygotować własny format, odpowiedni do jego potrzeb.

GÓRA STRONY

2. Dopowiadanie i nazywanie        

W angielskich tekstach informatycznych zazwyczaj nazwy funkcji, programów, klas, obiektów, poleceń podawane są bez wyjaśniania z czym mamy do czynienia:

We can use find to search our directories.

W tłumaczonym tekście polskim trzeba jednak pisać z czym mamy do czynienia. Wymaga to odrobiny wysiłku, bo tłumacz musi wiedzieć, czy przykładowo pisze o funkcji, czy programie, niemniej ten prosty zabieg nawet dwukrotnie poprawia czytelność tekstu informatycznego. Dlatego tam gdzie to tylko możliwe, należy pisać, o czym piszemy:

Możemy użyć funkcji find do przeszukiwania naszych katalogów.

Zamiast krótszej i łatwiejszej, acz mniej profesjonalnej:

Możemy użyć find do przeszukiwania naszych katalogów.

Czytelnicy, a co dla tłumacza ważniejsze, również korektorzy i redaktorzy w wydawnictwie, będą wam wdzięczni za tę odrobinę wysiłku.

GÓRA STRONY

3. Szyk zdania w języku angielskim  

W języku angielskim istnieje coś takiego jak sztywny szyk zdania. O funkcji wyrazu w zdaniu decyduje w znacznej mierze jego położenie w tym zdaniu. Dzieje się tak dlatego, ponieważ w języku angielskim nie ma odmiany rzeczowników przez przypadki i właśnie szyk zdania pozwala ustalić, czy dany rzeczownik jest z podmiotem (wykonawcą czynności), dopełnieniem (przedmiotem czynności), czy przydawką (opisem podmiotu lub dopełnienia). 

Ponadto jest jeszcze pewien zestaw wyrazów, które wyglądają dokładnie tak samo gdy są rzeczownikami, jak i gdy są czasownikami: access, link, save, fork, store, address, etc.  

Oto uproszczony szyk zdania orzekającego:

określenia podmiotu	podmiot	orzeczenie		określenia dopełnienia	dopełnienie
Access (1)	address (2)	links (3)	the	file (4)	handle (5)

Adres (2)      dostępu (1)      jest połączony z (3)      uchwytem (5)      pliku (4). 

To co należy zapamiętać, to że: określenia rzeczownika zawsze idą przed tym rzeczownikiem! Jak widać, odwrotnie niż w naszym tłumaczeniu. Co gorsza, czasem mogą tworzyć konstrukcję rekurencyjną: rzeczownik wraz z określeniem używany jest jako określenie kolejnego rzeczownika. Oto kilka prostych przykładów

the access address link          łącze adresu dostępu

the access link address          adres łącza dostępu   

the address access link          łącze dostępu do adresu

the address link access          dostęp do łącza adresu

the link access address          adres dostępu do łącza

the link address access          dostęp do adresu łącza

Proste, prawda? Wystarczy tylko zapisać wszystko od tyłu! Niezupełnie,  rzecz zaczyna się komplikować, gdy jednym z elementów takiego złożonego określenia jest przymiotnik. Czy fast access address tłumaczyć jako: adres szybkiego dostępu, czy może raczej jako szybki adres dostępu (innym przykładem może być tytuł popularnego filmu ze Schwarzeneggerem: Last action hero - źle: bohater ostatniej akcji, czy prawidłowo: ostatni bohater akcji). W takiej sytuacji nie ma prostej odpowiedzi. Może być i tak i tak w zależności od kontekstu. Tłumacz musi po prostu wiedzieć, który z wariantów tłumaczenia będzie w danym kontekście prawidłowy. W tym przypadku  nie ma wyjścia i niezbędna jest znajomość tłumaczonej materii

Co gorsza w polskich przekładach informatycznych zdarzają się solidnie już zadomowione, błędne przekłady takich złożeń, szczególnie w tłumaczeniach akronimów. Wtedty oczywiście nie ma wyjścia i trzeba tłumaczyć zgodnie z ogólnie przyjętą normą, nawet jeśli jest błędna.

Czasami też stosujemy niezupełnie formalnie poprawne tłumaczenie z przyczyn stylistycznych, gdy ścisłe stosowanie się do opisanej powyżej zasady dałoby koszmarny efekt:

gateway choke point  = brama dławiąca, brama tłumiąca (a nie punkt dławienia bramy)

Oczywiście zdania rozkazujące lub pytające mają w języku angielskim trochę inny szyk niż zdanie oznajmujące. Nie będę się tutaj zagłębiał w szczegóły, tym bardziej, że kombinacji jest dużo. Warto tylko wiedzieć, że nawet z najtrudniejszym zdaniem można sobie poradzić wykonując następujący rozbiór:

1. Odnajdujemy orzeczenie (główny czasownik) - zazwyczaj najłatwiejszy do odnalezienia. Nawety jeśli wygląda jak rzeczownik, często można go rozpoznać po braku przedimka (Please handle with care).
2. Odnajdujemy podmiot (główny rzeczownik, wykonujący czynność), zazwyczaj przed orzeczeniem
3. Odnajdujemy dopełnienie (rzeczownik będący przedmiotem czynności), gdzieś za orzeczeniem.
4. Dopiero teraz lokalizujemy wszystkie określenia podmiotu i dopełnienia (a także orzeczenia oczywiście)

Miłej zabawy.

GÓRA STRONY

4. Erudycja         

Warto dużo czytać i to nie tylko książki z branży. Podstawowa korzyść z ogólnego oczytania polega na systematycznym ćwiczeniu umysłu, dzięki któremu łatwiej jest nam formułować zdania, popełniamy mniej błędów stylistycznych, mamy bogatsze słownictwo, znamy standardowe zwroty za pomocą których można zgrabnie przetłumaczyć na polski różne frazy angielskie.

Na szczęście, za wyjątkiem może konieczności tłumaczenia cytatów umieszczanych czasem na początku rozdziału, podczas tłumaczenia książek informatycznych nie jest zazwyczaj niezbędna wiedza spoza informatyki i matematyki. Obowiązkowa jest wyłącznie znajomość serialu Star Trek oraz Gwiezdych Wojen.

GÓRA STRONY

5. Terminy o kilku znaczeniach        

Anglosasi tak szybko wynajdują nowe rozwiązania techniczne, że często zupełnie nowe rzeczy nazywane są wyrazami już istniejącymi w języku angielskim, co gorsza bardzo często jeden wyraz używany jest jako nazwa kilku całkowiczie różnych rzeczy (u nas dobrym przykładem takiego wyrazu może być np. mostek).

Posłuże się przykładem wyrazu hash. Oto kilka jego znaczeń w informatyce:

1. Znak # w zestawie znaków lub na klawiaturze.
2. Hash. Efekt funkcji haszującej (lub mieszającej), która "szyfruje" zrozumiały tekst w losowy łańcuch znaków - hashu nie można potem odszyfrować, ale dwa identyczne wyrazy szyfrowane tą samą metodą dadzą ten sam hash, co przydaje się przy sprawdzaniu haseł.
3. W języku programowania Perl tablica asocjacyjna. Tablica w której każdej wartości przypisywany jest odpowiedni klucz (słowo-etykieta) ułatwiające odnajdywanie wartości w tablicy.
   
4. W bazach danych hash. Tabela (ew. indeks) bardzo podobna co do zasady do tablicy asocjacyjnej Perla, ale utarło się niezręczne tłumaczenie hash.
   

Cztery całkowicie różne znaczenia!

A takich terminów jest multum. Wymienię tylko kilka przykładów: node, link, window, tag, key, frame. Zasada jest prosta. Jeśli mamy najmniejsze wątpliwości, należy rzecz sprawdzić w słowniku. Między innymi dlatego szczególnie wygodny jest słownik Marcina Miłkowskiego (łącze do niego znajdziesz na mojej stronie ze słownikami), gdyż podaje przy teminie po kilka znaczeń.

GÓRA STRONY

6. Importy a polskie odpowiedniki      

Moje trzy grosze do dyskusji, czy przekładając angielskie terminy należy wymyślać polskie odpowiedniki, czy też importować je w wersji angielskiej.

Odpowiedź jest prosta i niezbyt odkrywcza: Tak jak wszędzie, należy znaleźć złoty środek między oboma strategiami. Obie mają swoje zalety i wady.

Wymyślanie polskich odpowiedników ma następujące wady:

1. W przypadku szybko rozwijających się dziedzin takich jak informatyka jest technicznie niewykonalne. Nowe terminy pojawiają się tu dziesiątkami, czy nawet setkami każdego miesiąca. Nikt nie jest w stanie wymyślać polskich odpowiedników w takim tempie. Ponadto istnieje ryzyko, że różni tłumacze wymyślą zupełnie różne odpowiedniki, co powoduje nieunikniony chaos (na ogromną skalę zważywszy na tempo pojawiania się nowych terminów) i niezmiernie utrudnia życie czytelnikowi.
   
2. Tworzenie polskich odpowiedników spowalnia rozwój informatyki tworząc barierę językową między polską a światową terminologią techniczną. Jest to szczególnie dotkliwe, gdy czytelnik próbuje studiować angielską dokumentację techniczną (a musi, bo na język polski jest siłą rzeczy tłumaczone tylko z 10% tekstów potrzebnych obecnie informatykowi do pracy) i zmuszony jest w bólach porównywać pomysły tłumacza z oryginalną terminologią.
   

Nie ukrywam, że osobiście uważam iż większym powodem do narodowej dumy jest wymyślenie nowego rozwiązania technicznego (i zmuszenie innych, by uczyli się naszej terminologii, jak np. dywan Sierpińskiego, notacja polska), niż fałszywe umacnianie dumy narodowej poprzez wymyślanie nowych nazw dla cudzych idei, dodatkowo spowalniając w ten sposób rozwój własnej nauki.

Niemniej od każdej reguły są wyjątki
Oto najważniejsze sytuacje w których należy jednak znajdować polskie odpowiedniki dla obcych terminów:

1. Gdy istnieje polski odpowiednik mający bardzo zbliżoną nazwę do obcego oryginału: (mouse-mysz, daemon-demon, class-klasa, object-obiekt, table-tabela, function-funkcja). Jak widać są to wyrazy albo wywodzące się ze wspólnego indoeuropejskiego pnia, albo zaimportowane już dawniej do języka polskiego np. z łaciny (nihil novi sub sole).
   
2. Gdy angielski termin wziął się od czynności lub funkcji wykonywanej przez obiekt: (browser-przeglądarka, directory-katalog, recycling bin-kosz, dispatcher-proces rozsyłający, switch-przełącznik, link-łącze/powiązanie) lub czasem od wyglądu (window-okno, bar-pasek). Tutaj tłumaczenie ułatwi zwykłym ludziom (a również i specjalistom, patrz dispatcher, switch) zrozumienie funkcji obiektu, więc jest jak najbardziej uzasadnione. W tym przypadku mamy do czynienia z sytuacją odwrotną: to zastosowanie angielskiego oryginału stworzyłoby barierę utrudniającą zrozumienie technologii!!!
   
3. Gdy z jednej strony możemy przewidywać, że dany termin będzie używany bardzo często (tag-znacznik, page-strona), a dodatkowo automatyczne importowanie terminu spowoduje niezręczności: np. błędne skojarzenie (directory-dyrektor), kłopoty z odmianą (window, file), gdy termin angielski jest dłuższy i mniej poręczny (recycling bin) niż polski odpowiednik lub po prostu brzmi idiotycznie (Web = sieć WWW, nie sieć Web)  itp.
4. Gdy zobowiązuje nas do tego tradycja. Tzn. gdy polski odpowiednik jest już od dawna używany i zadomowiony w języku, a więc (matrix=macierz, digital=cyfrowy, maultiplication=mnożenie). Po pierwsze jesteśmy osadzeni w pewnej tradycji językowej (wymyślanie nowych tłumaczeń dla już przetłumaczonych terminów nie świadczy o inteligencji tłumacza), po drugie wreszcie w przypadku np. terminów z matematyki, statystyki jest to wyraz elementarnej rzetelności. Dlatego własnie polecam słownik Jacka Szaniawskiego (łącze do niego znajdziesz na mojej stronie ze słownikami), w którym terminy informatyczne tłumaczone są w sposób tradycyjny.

Ponadto przy dobieraniu tłumaczeń warto pamiętać o jeszcze paru pułapkach:

• Szukanie polskiego odpowiednika na siłę naraża nas na różne pułapki. Weźmy za przykład wyrazy: procedure, function, method i routine - wszystko są to odmiany procedur (ew., ffunkcji), niemniej obecnie w programowaniu obiektowym istnieją bardzo ścisłe rozróżnienia między tymi terminami. Tłumacz próbujący spolszczania na siłę (wszędzie procedura lub funkcja, zamiast odpowiednio procedura, funkcja, metoda, rutyna) naraża się na popełnienie poważnego błędu merytorycznego. Dlatego ostrożnośc przede wszystkim: jesli ni mamy 100% pewności, o co chodzi, należy trzymać się możliwie blisko angielskiego oryginału (wiem co mówię, sam popełniłem kilka takich błędów).

• Zasada uzusu: należy stosować się do tłumaczeń obowiązujących w branży lub rozpowszechnionych wśród ludzi. Nawet jeśli wydają się nam idiotyczne (serwer proxy, tabela haszowana), albo są wynikiem popełnionego kiedyś błędu. Na szczęście sporo takich nieudanych tłumaczeń zanika (vide np. krotka w bazach danych)

• Stosując powyższą zasadę uzusu warto pamiętać, że język mówiony rządzi się innymi prawami niż język pisany, który jest bardziej formalny. Np. w mowie potocznej powiemy wyłącznie email, mail natomiast już w tekstach pisanych warto stosować i formę email i dłuższą poczta elektroniczna, wiadomość elektroniczna, żeby uniknąć powtórzeń, uzyskać większą precyzję techniczną (nasz rozmówca zazwyczaj wie, o czym mówimy, czytelnik niekoniecznie), itp.

• Warto pamiętać, że nawet bardzo zbliżony termin angielski może obejmować inny zakres znaczeń niż termin polski (więc machine to komputer, nie maszyna, a technology to czasem technologia a czasem technika, że o bilion=miliard nie wspomnę).

• Należy unikać tłumaczenia angielskich akronimów (tj. skrótowców: HTML, DBCA, SQL TCP/IP, SMTP itd.). Większość takich tłumaczeń albo brzmi idiotycznie jeśli zachowujemy poprawność znaczenia, albo całkowicie przekręca znaczenie, jeśli tłumaczymy akronim słowo po słowie. Dlatego tłumaczymy język HTML, protokół SMTP, asystent DBCA. Skróty takie są w znakomitej większości w informatyce terminami technicznymi, których nie należy przekładać, bo czytelnik będzie miał potem problemy ze studiowaniem dokumentacji. Warto zauważyć, że tu dopuszczalne i wręcz zalecane są pleonazmy (tj. masło maślane) - polegające na użyciu przed akronimem słowa wchodzącego w skład tegoż akronimu (w odróżnieniu od sieci Web, gdzie nie mamy do czynienia z akronimem).

• Nawet jawne błędy należy powielać, jeśli tłumaczymy spolszczony program, w którym zastosowano błędny termin (znów sztandarowy przykład: sieć Web nagminnie używana w polskiej wersji systemu Windows).

• Jeśli polskie tłumaczenie odbiega od angielskiego oryginału (np. array-tablica), należy pamiętać, by w nawiasie podawać co jakiś czas polski odpowiednik. Oczywiście bez przesady i dostosowując się do poziomu wiedzy czytelnika - w książce dla zaawansowanych programisttów przypominanie, że tablica (ang. array), jak najbardziej uzasadnione w książce dla początkujących, zamiast pomóc wywoła tylko irytację czytelnika.
  

To chyba wszystkie najważniejsze zalecenia
Jak widać niektóre stoją ze sobą w sprzeczności. Jeśli mamy wątpliwości, należy rozstrzygać analizując je pod kątem dwóch zasad nadrzędnych:

1. Wygody naszego czytelnika (co bedzie się mu łatwiej czytało, co szybciej zrozumie, co sprawi mu mniej kłopotu, jeśli później będzie musiał przeglądać angielską dokumentację, itp.).
2. Rzetelności merytorycznej (zgodności z oficjalnie przyjętą terminologią, z tłumaczeniami zastosowanymi w programach, itp.).

GÓRA STRONY