Tłumocze… tłucze… przekład*

Marta Bartnicka

Uwaga: tekst powstał 20 lat temu, więc należy go traktować jako materiał archiwalny. Pod pewnymi względami w branży lokalizacyjnej zmieniło się wszystko, pod innymi jednak — bardzo niewiele.

Polska, rok 1990. Na komputerach PC króluje DOS i wszelkie programy dla niego; polskich znaków i wszelkich polskości unika się, jeśli można, a jeśli nie można, to każdy koduje i nazywa po swojemu. UNIX to odległa egzotyka. TeX już istnieje, ale czy ktoś go widział? Windows 3.0 właśnie wychodzi w USA, ale jeszcze nie obsługuje poprawnie polskich znaków, nie mówiąc o polskiej wersji językowej. W księgarni można kupić książki Bieleckiego albo Marciniaka, z tym, że „każdy informatyk zna przecież angielski”, więc w dobrym tonie jest raczej czytanie oryginalnej dokumentacji, o ile ma się do niej dostęp. Inne publikacje techniczne, na przykład z elektroniki, są tłumaczone na polski tradycyjnie, wolno i zwykle starannie.

Polska, rok 2000. Brak obsługi polskiej strony kodowej jest nie do pomyślenia, myśli się co najwyżej o wyborze standardu (ech, ten cep…). Polskie Windows i polski pakiet Office wychowały  całkiem pokaźną rzeszę użytkowników, którzy owszem, komputer obsługiwać umieją, owszem, całkiem sprawnie napiszą dokument, wydrukują go, pocztę wyślą i odbiorą — ale po angielsku ani, ani, bo im to niepotrzebne! Inni producenci oprogramowania dla Windows też zresztą tłumaczą „na pniu” — wydając wersję polską równocześnie lub tuż po angielskiej. Systemy UNIX tłumaczy się mniej lub bardziej. Księgarnie są dosłownie zasypane polską literaturą informatyczną — w tym, w dużej mierze, przekładami oryginalnych publikacji.

W tej sytuacji tłumaczyć każdy może — gdyż przy tak szybkim wzroście ilości polskich programów i publikacji na rynku (1990–2000) popyt na tłumaczy i tłumaczenia był i pozostaje ogromny. Ale jak(ość) — czasem, ech, w gardle staje… Postaram się rozważyć w kilku prostych punktach, dlaczego tak jest i co robić, żeby nie było.

0. Przeczytać, zrozumieć, napisać swoimi słowami, czyli o co chodzi.

Przyzwoite tłumaczenie powstaje w następujący sposób:

1. Tłumacz czyta frazę tekstu oryginalnego ze zrozumieniem (fraza może być opcją menu, komunikatem, zdaniem lub kilkoma powiązanymi zdaniami).
2. Tłumacz wyjaśnia wszelkie wątpliwości, czyli sprawdza to, czego nie zrozumiał (mogą to być kwestie merytoryczne albo niuanse językowe).
3. Tłumacz pisze frazę w języku „docelowym”, przy czym tekst wynikowy jest zgodny merytorycznie z oryginałem oraz poprawny i klarowny w języku, w jakim jest napisany.

Niby banał, a jednak — ta podstawowa procedura dobrego, ba, poprawnego tłumaczenia jest najczęściej łamana. Każdy tłumacz, zapytany, czy tłumaczy „słowo po słowie”, śmiertelnie się obrazi, tymczasem… Jeśli goni termin, jeśli dopadło lenistwo, jeśli zleceniodawca płaci „od słowa” – w głowie zaczyna stukać licznik, a wyłącza się myślenie.

Po pierwsze: przestaje się dociekać, o co tak naprawdę w tekście chodzi, a bez tego szanse na poprawne przełożenie spadają do zera. Po drugie: przesąd, że tłumacz musi przede wszystkim znać język, z którego tłumaczy, zakorzenił się mocno i wciąż jeszcze ma się dobrze. Tymczasem jest to bzdura absolutna, bo tłumacz musi znać język „źródłowy” na tyle, żeby tekst przeczytać i zrozumieć – a więc biernie – natomiast językiem ojczystym musi władać bardzo biegle, bo w tym języku będzie de facto tworzył.

Teza, że tekstu informatycznego nie dotyczą reguły gramatyki polskiej, obali się sama po rozważeniu następnych punktów – niegramatyczność prowadzi do niezrozumiałości. Teza, że tłumacz może być specem merytorycznym, a język wyczyści korektor-polonista, też obala się sama jak pijane dziewczę na szpilkach: większego tekstu odpowiednio źle przetłumaczonego nie poprawi żaden korektor, bo prościej taki chłam wyrzucić i przetłumaczyć od nowa.

Załóżmy zatem, że mamy kogoś, kto jest w stanie bez bólu i w miarę bezbłędnie napisać list do cioci czy podanie do spółdzielni mieszkaniowej. Ów ktoś zna również język, z którego chcemy tłumaczyć – przyjmijmy, że angielski – na tyle, żeby tekst zrozumieć, a gdy nie rozumie, to ma chlubny zwyczaj sprawdzania i dopytywania się do skutku. W ogóle jest to osobnik dociekliwy, obłożony z jednej strony słownikami angielsko-polskimi, a z drugiej – słownikami polskimi i poradnikami gramatycznymi. Co do dziedziny, w której będzie tłumaczenie, to nasz hipotetyczny tłumacz niekoniecznie jest w niej ekspertem, ale zna podstawy, a co do reszty, to dokładnie wie, gdzie szukać lub kogo pytać. (Czasem wydaje mi się, że wręcz nie powinien być ekspertem. Ekspert napisze mętnie, zastosuje mnóstwo skrótów myślowych i nie zobaczy w tym nic złego, bo on i tak wie, o co chodzi).

Rozważmy teraz parę zagadnień, których właściwe potraktowanie pozwoli tłumaczowi hipotetycznemu stać się tłumaczem (prawie) idealnym. Aby zawęzić zagadnienie do rozsądnego zakresu, przyjmijmy, że chodzi o tłumaczenia pisemne z języka angielskiego na język polski, a tłumaczone materiały to oprogramowanie (opcje menu, komunikaty ekranowe, pomoc) oraz dokumentacja i inne książki o tematyce informatycznej.

1. Kto kogo czym, czyli raz jeszcze – zrozumieć.

Kto kogo czym to hasło nawołujące do rozbioru gramatycznego frazy (zdania lub więcej) tekstu oryginalnego. Nasz hipotetyczny tłumacz nie musi w tym celu być filologiem angielskim ani rysować skomplikowanych wykresów, ale prawidłowa analiza oryginału często pozwala, nawet bez dokładnej znajomości zagadnienia, zrozumieć tekst.

Przykładowo: File type %1 name %2 cannot be parsed.
Jeśli mamy do przetłumaczenia taki komunikat bez żadnego kontekstu, to można przetłumaczyć go po prostu Typ pliku %1 nazwa %2 nie może być przeanalizowany. Ale – nie wiedząc nawet dokładnie, o jakiej operacji tu mowa – z konstrukcji zdania angielskiego można wywnioskować, że prawidłowe tłumaczenie to: Plik typu %1 o nazwie %2 nie może być przeanalizowany.

2. Możesz chcieć mieć, czyli piszmy jednak po polsku.

Możesz chcieć mieć to okropnie kalekie (od kalki!) tłumaczenie angielskiego you may want to have, popełniane uporczywie przez pewną znaną mi grupę tłumaczy i używane potem jako sztandarowy przykład tłumaczenia byle jakiego.

Uwaga, teraz będzie bardzo serio: pisanie zgodnie z zasadami polskiej ortografii, gramatyki i interpunkcji to w tłumaczeniach informatycznych wcale nie jest „kwiatek do kożucha”. Przestrzeganie zasad powoduje, że tekst mieści się w normie języka i jest zrozumiały dla przeciętnego odbiorcy władającego tym językiem.

Ot, choćby takie zdanie:
You may list several alternate master servers the zone can be copied from inside the masters list, separated by ';' (semicolon).
Na polski zostało w pewnym projekcie przetłumaczone w ten sposób:
Możesz wymienić kilka alternatywnych serwerów głównych, z których strefa może być kopiowana w liście masters, oddzielone przez „;”.

Podstawowy błąd tłumacza polegał na tym, że w zdaniu polskim zachował szyk zdania angielskiego. Przez to trudno jest zrozumieć, o co chodzi, co jest oddzielone i przez co.

A przecież można to napisać po polsku, na przykład tak:
W liście masters można wymienić kilka (rozdzielonych średnikami „;”) zapasowych serwerów głównych, z których strefa może zostać skopiowana.

Albo może jeszcze śmieszniejsze:
Please note the `.' at the end of all the full domain names in this file, in contrast to the named.conf file above.

Przetłumaczono to, raczej bez wysiłku, jako:
Zauważ znak ,,.'' na końcu wszystkich pełnych nazw domen w tym pliku, kontrastuje to z plikiem named.conf powyżej.

To nie jest poprawna konstrukcja języka polskiego, więc znowu trudno ją zrozumieć. Poprawnie (i prościej) byłoby:
Zwróć uwagę na znak „,” występujący na końcu wszystkich pełnych nazw domen w tym pliku, inaczej niż w pliku named.conf powyżej.

Pomocą w pisaniu po polsku (a nie po polskawemu, jak niektórzy określają to, czego próbki zacytowałam) są słowniki i podręczniki do gramatyki. Polecam możliwie najnowsze wydania PWN: Słownik poprawnej polszczyzny (zawiera też sporo informacji z gramatyki, ortografii i interpunkcji), Słownik języka polskiego, Słownik ortograficzny, Słownik wyrazów obcych. To nie są tanie słowniki, więc pojedynczy tłumacz może z nich korzystać w bibliotekach lub u znajomej młodej pięknej polonistki, ale już większa grupa tłumaczy pracująca wspólnie nad projektem zdecydowanie powinna się na taki wydatek zdecydować.

3. Gdzie ja mam klawiaturę, czyli o tykaniu i pewnych zaimkach.

Gdy zdarzało mi się robić korektę i spotykałam teksty tylu wpisz na swojej klawiaturze polecenie DIR, zwykłam pytać złośliwie: a gdzie ja niby mam klawiaturę? Wszelkie informacje dla użytkownika, odbiorcy i innej maści klienta są w języku angielskim pisane w drugiej osobie, przy czym używane jest całe mnóstwo magicznego zaimka YOU (lub YOUR). Druga osoba jest stosowana zawsze, YOU kwitnie przede wszystkim w tekstach pochodzenia amerykańskiego, ale nie tak znowu dużo jest programów i dokumentacji brytyjskiej…

Pierwsza pułapka polega na tym, że druga osoba jest w języku angielskim poprawną i przyjętą formą zwracania się do klienta w życiu codziennym, w sklepie, w dokumentach urzędowych, w instrukcji obsługi pralki, w książce kucharskiej i tak dalej. Tymczasem w języku polskim tak nie jest i nigdy dotąd nie było.

1. Książki kucharskie i wszelkie poradniki pisane są najczęściej w pierwszej osobie liczby mnogiej (bierzemy dwa jajka…). Nieprzypadkowo niniejszy tekst jest pisany mniej więcej w ten sposób.
2. Instrukcje obsługi pisano dotąd najczęściej bezosobowo (należy podłączyć pralkę do prądu…).
3. Dokumenty urzędowe otrzymujemy zwykle w trzeciej osobie liczby pojedynczej lub mnogiej, z nieodłącznym Pan/Pani/Państwo lub też Obywatel/ka/le (zechce Pani uiścić zaległe alimenty…, wzywa się Obywateli Kowalskich do stawienia się…).

Uważam, że nie trzeba tu zbyt wiele zmieniać, tradycja to wielka rzecz. Zbyt bezpośrednie, ba, obcesowe zwracanie się do użytkownika jest po polsku rażące i niesympatyczne. You must install the following patches: Musisz zainstalować następujące poprawki:– to tłumaczenie brzmi cokolwiek brutalnie; Należy zainstalować następujące poprawki: znaczy dokładnie to samo, a nie uraża ego przeciętnego Polonusa 🙂

Jedynym w zasadzie przypadkiem, gdzie tryb rozkazujący i druga osoby liczby pojedynczej stanową najrozsądniejszy wybór, są instrukcje „krok po kroku” (w programie albo w dokumentacji), mniej więcej tego typu:

• włóż dyskietkę do napędu A,
• wpisz „format a:”,
• naciśnij klawisz Enter…

Z drugiej strony – znam co najmniej jedną firmę, której dokumentacja do programów (zresztą polska, nie tłumaczona) jest konsekwentnie pisana w formie grzecznościowej jak w punkcie C powyżej (naciskacie Państwo klawisz Enter) i jest bardzo czytelna i zrozumiała.

Drugą pułapką jest wymienione YOU/YOUR. W co najmniej połowie przypadków można je w ogóle pominąć, bo jest zbędne, a nawet prowadzi do zabawnych skojarzeń: You must install the following patches on your hard disk: Należy zainstalować następujące poprawki na swoim dysku twardym: – to sugeruje, że użytkownik ma zamontowany dysk twardy; Należy zainstalować następujące poprawki na dysku twardym: – w większości wypadków jest wystarczająco jednoznaczne.

Czasami jednak chodzi o TWÓJ komputer (a nie sąsiedni) – wtedy nie należy, rzecz jasna, magicznego zaimka wyrzucać, bo to by zmieniło sens tekstu: You must install all patches on your hard disk, except for patch 5, which should be installed on the server. Należy zainstalować wszystkie poprawki na dysku twardym swego komputera, oprócz poprawki 5, którą należy zainstalować na serwerze.

4. Słownik, ustalenia co do stylu i inne zbędne utrudnienia.

Żarty były w tytule tego rozdziału, a teraz poważnie. Słownik i ustalenia co do stylu są niezbędne nawet przy tłumaczeniu wykonywanym przez jedną osobę, nie mówiąc już o pracy grupowej. „Wszyscy znamy polski” czy „terminologia komputerowa jest powszechna” to kolejne przesądy. Nawet oparcie się na jednym z dostępnych na rynku czy w Internecie słowników informatycznych nie pomoże, bo podstawowe słowa mają po kilka poprawnych tłumaczeń. Niestety, tłumaczenia informatyczne to nie literatura piękna i jeśli HTML link nazwaliśmy raz odsyłaczem, to musimy się tego trzymać i nie nazywać go odnośnikiem – w przeciwnym razie tekst czy program będzie trudny do zrozumienia (na przykład jeśli add link to dodaj odsyłacz, a delete link to usuń odnośnik).

Podobnie jest ze stylem – trzeba się na coś zdecydować, choćby w kwestii stylu zwracania się do użytkownika/czytelnika, co zostało opisane w punkcie 3. Można ustalić, że piszemy konsekwentnie bezosobowo (wariant B), można się zdecydować na inną formę, ale musi to być przestrzegane. Niepotrzebnie mieszane style nie tylko wyglądają niechlujnie, ale i utrudniają odbiór programu czy dokumentacji.

(Wyższą szkołą jazdy jest KONSEKWENTNE stosowanie kilku stylów: polecałabym standardowo bezosobowy, w instrukcjach „krok po kroku” rozkazujący, tak jak to jest opisane w punkcie 3).

W ogóle złotą reguła tłumaczeń jest, Państwo wybaczą, może być chujowo, byle jednakowo**. A nie tak, jak czytam w JEDNYM pliku, przetłumaczonym przez JEDNEGO tłumacza: Cache expired to Dezaktualizacja bufora cache (po polsku jest deaktualizacja, ale niech mu będzie); Profiling timer expired to dla odmiany Koniec stopera profilującego – byłabym skłonna uwierzyć, że cache i timer podlegają zjawisku expire w różny sposób, co uzasadnia różne tłumaczenia, cóż, kiedy… Timer expired to co prawda Koniec stopera, ale… Virtual timer expired to już Wirtualny stoper wyczerpany.

5. Przeczytaj to jeszcze raz, sam, czyli apoteoza autokorekty. 

Ten rozdział jest w zasadzie uzupełnieniem rozdziału 0: przeczytaliśmy, zrozumieliśmy, napisaliśmy najlepiej, jak umieliśmy. A teraz siusiu, paciorek i spać! Następnego dnia trzeba tekst przeczytać i poprawić, co jest do poprawienia. I – uwaga – nie jest to proces rekurencyjny, nie namawiam do poprawiania w nieskończoność. Ale ten raz, i to koniecznie na drugi dzień, jest niezbędny. (Tu każdy doświadczony tłumacz spyta: JAK TO??? A jak termin goni, jak tłumaczenie jest superpilne? Cóż, wtedy trzeba niestety spanie z procesu wykreślić, ale siusiu, paciorek i, powiedzmy, filiżanka herbaty zostają. Chodzi o to, żeby bezwzględnie spojrzeć na tekst po – choćby niewielkiej – przerwie).

Najwyższy czas na jakieś to, no, zakończenie. Nawiązując do tego, co napisałam na początku – jakość polskich tłumaczeń będzie się poprawiać, bo wymaga tego rynek: odbiorcy robią się wymagający. Ba, już się poprawia! Wystarczy spojrzeć na coraz bardziej polskie i coraz staranniejsze instrukcje na szamponach czy proszkach do prania. Średnia jakość tego, co stoi w księgarniach informatycznych, też się podnosi. Dlatego warto popracować nad warsztatem tłumaczenia, bo coś, co było dobre w tłumaczeniu amatorskim czy w firmie zatrudniającej studentów na szybkie projekty, może się nagle okazać za słabe…

Wszystkim, którzy doczytali do tego miejsca, bardzo dziękuję za uwagę i życzę miłego tłuczenia 🙂

Marta Bartnicka
 

Wszystkie przykładowe tłumaczenia w tym tekście pochodzą z prawdziwych projektów komercyjnych lub niekomercyjnych.

* Tytuł zaczerpnięty z napisów do filmu, ale nie pamiętam ani jakiego,
ani kto go w Polsce dystrybuował 🙁

** Może być chujowo… było oryginalnie regułą dotyczącą pisania programów i pochodzi od szefa pewnej firmy, który nawoływał do zachowania spójności stylu kodowania. Jako że w tłumaczeniach pracuje wiele dam (co zresztą byłoby niezłym tematem na całkiem osobny tekst, gdyby nie istniała już świetna książka Płeć mózgu), więc w praktyce można słowo kluczowe zamienić na kijowo.
 

lokalizacja poradnik tłumaczenie wyzwania