W projektach eksportowych tłumaczenie instrukcji obsługi maszyny wysyłanej w świat jawi się zwykle jako jedna z łatwiejszych formalności. Ma być, bo być musi. Najlepiej szybko. Wyśle się do jakiegoś biura tłumaczeń i z głowy. Często zapada też decyzja, żeby wysłać instrukcję do tłumaczenia jeszcze bez zdjęć i rysunków ilustracyjnych, bo grafika „jest w trakcie”, „będzie później” albo „jeszcze się może zmienić”.
Z perspektywy pracy PM-a brzmi to jak rozsądne przyspieszenie projektu. Z perspektywy jakości dokumentacji, jak otwarcie furtki dla błędów, poprawek i iteracji. Tudzież do nieplanowanego wzrostu kosztów.
Jeżeli uważasz, że przesadzam, popatrz na to tak:
Instrukcja obsługi bez ilustracji jest jak mebel bez instrukcji, ale za to z bardzo dokładnym opisem śrubek. Teoretycznie można. W praktyce zawsze ktoś skręci coś odwrotnie.
Taki scenariusz powtarza się w projektach z różnych branż, prowadzonych przez różne zespoły. Za brakiem graficznej warstwy ilustracyjnej w pliku do tłumaczenia zwykle stoją bardzo podobne przyczyny.
Gdyby każdemu takiemu przypadkowi towarzyszył jeden, technicznie uzasadniony powód, świat byłby prostszy. W praktyce jednak brak zdjęć i rysunków w pliku do tłumaczenia rzadko bywa decyzją strategiczną. Zdecydowanie częściej jest efektem pośpiechu, skrótów myślowych i klasycznego Ogarniemy!
To chyba najczęściej występujące wytłumaczenie sytuacji, w której tłumacz dostaje instrukcję ogołoconą z warstwy wizualnej.
Teksty są pisane wcześniej, tak żeby nie przygotowywać instrukcji w ostatniej chwili. W pliku roboczym nie ma zdjęć, ponieważ maszyna nie jest jeszcze gotowa i nie ma czego fotografować.
I tu pojawia się myśl:
Skoro mamy już tekst, to wyślijmy go do tłumaczenia, żeby nie tracić czasu. Potem tylko wstawi się zdjęcia i voila!
Wtedy tłumacz dostaje dokument, w którym brak kontekstu wizualnego i ma przetłumaczyć go tak, jakby ten kontekst wizualny tam był. Nie wiem jak Ty, ale ja widzę to jak coś, co się nie spina. Tłumaczenie instrukcji obsługi to nie magia, tylko precyzyjna praca na kompletnych danych.
Tu wchodzimy na grunt zarządzania projektem. Sprzedaż maszyny klientowi z zagranicy to dla producenta super sprawa, ale wiąże się z tym, że trzeba dopilnować kilku spraw ponad te, które robi się w przypadku sprzedaży krajowej. A ponieważ rzadko który projekt przebiega idealnie według planu, kolejne opóźnienia i klient dopytujący kiedy w końcu maszyna zostanie wysłana sprawiają, że robi się coraz bardziej nerwowo. Pojawiają się różne pomysły na to, jak to wszystko przyspieszyć.
Tłumaczenie instrukcji wydaje się najłatwiejsze do realizacji, nawet jeżeli instrukcja jeszcze nie jest gotowa i jest bez ilustrującej ją dokumentacji graficznej. Plan wygląda z grubsza tak:
Brzmi logicznie tylko do momentu, gdy okazuje się, że:
Wyjątkowo efektowny przypadek w galerii chybionych pomysłów na usprawnienie procesu tłumaczenia. Tak, może i plik waży za dużo. Tak, może i skrzynka nie przyjmuje takich dużych załączników. Tak, ktoś czasem może w związku z tym dojść do wniosku, że wywalenie grafik rozwiąże problem.
I rozwiązuje. Technicznie. Na jakieś pięć minut.
Bo potem okazuje się, że tłumacz nie widzi, o którym elemencie mowa; nie wie, czy włoskie braccio to ruchome ramię, czy po stabilizator; nie ma pojęcia, czy chwytak, to na pewno to samo co odbierak, czy to jednak dwa różne elementy.
Ale za to plik był lżejszy.
Niestety, to nie jest takie proste. Instrukcja bez warstwy ilustracyjnej to nie jest ta sama instrukcja, tylko bez zdjęć i rysunków. To jest zupełnie inny dokument. To naprawdę nie jest tak, że to przecież oczywiste, każdy technik to wie, więc i tłumacz zrozumie, w końcu zna język, więc przetłumaczy.
Tutaj warto zatrzymać się na chwilę i rozprawić z pewnym mitem dotyczącym tego, co tłumacz może zrobić w tłumaczonym tekstem.
Pomimo nieprawdopodobnego wręcz rozwoju technologii, tłumacze techniczni jeszcze nie łączą się telepatycznie z halą produkcyjną, nie widzą maszyny w przekroju 3D i - niestety - nie znają wszystkich rozwiązań konstrukcyjnych świata. I nikogo nie powinno to dziwić. W końcu nawet doświadczeni inżynierowie specjalizują się w jakiejś swojej dziedzinie, a nie we wszystkich możliwych. Specjalista od konstrukcji form wtryskowych nie zaprojektuje doskonałej prasy krawędziowej. A już na pewno nie w tydzień, na podstawie samego opisu prasy.
Tłumacz pracuje na tym, co widzi. Jeżeli widzi tylko tekst bez żadnego odniesienia do obrazu, to pracuje na połowie informacji. A połowa informacji może wystarczyć na usmażenie w miarę smacznej jajecznicy, ale nie na bezbłędne przetłumaczenie instrukcji obsługi linii do cięcia blachy z kręgów.
Tłumacz czyta instrukcję, analizuje to, co zostało napisane i interpretuje sens na podstawie dostarczonego materiału. Dokładnie tak samo, jak później zrobi to użytkownik maszyny. Z tą różnicą, że użytkownik będzie miał przed sobą fizyczne urządzenie. Tłumacz, jeżeli dostanie plik bez kontekstu wizualnego, będzie miał tylko litery. A w kontekście maszyn przemysłowych to rzadko wystarcza.
Instrukcja techniczna działa jak duet: tekst i obraz razem tworzą zrozumiałą całość. Tekst opisuje, co należy zrobić, w jakiej kolejności oraz czego nie wolno robić. Obraz pokazuje, o który element chodzi, gdzie się znajduje, jak wygląda, gdy jest zamontowany dobrze, a jak - gdy jest zamontowany źle.
Gdy rysunku nie ma, cały ciężar precyzji spada na język. W instrukcjach coraz częściej pojawiają się zdania możliwie jak najbardziej uniwersalne. Takie, które mają pasować do wielu maszyn i wielu wersji językowych. To wygodne na etapie tworzenia dokumentacji, ale w momencie tłumaczenia zaczyna się problem.
Uniwersalne zdania bardzo często są tylko pozornie powtarzalne (właśnie dlatego profesjonalne tłumaczenia techniczne wymagają czegoś więcej niż tylko znajomości języka). Dla narzędzi CAT wyglądają identycznie, ale dla tłumacza ich znaczenie zależy od kontekstu. A tego kontekstu bez rysunku często po prostu nie widać.
Dla kogoś, kto ma maszynę przed sobą, nawet najbardziej ogólne zdanie jest oczywiste. Dla tłumacza, który widzi tylko tekst - już niekoniecznie. Bez zdjęć nie widać relacji między elementami ani proporcji, nie widać co z czym sąsiaduje, ani czy giunto to złącze, łącznik, sprzęgło, czy coś jeszcze innego.
A przecież tłumacz nie ma obowiązku znać Twojej maszyny i wiedzieć, jak jest zbudowana i jak działa. Ma obowiązek rzetelnie opracować materiał, który otrzymał. Jeśli tekst nie wyczerpuje tematu, tłumaczenie, siłą rzeczy, też takie będzie.
Kiedy po jakimś czasie pojawiają się zdjęcia czy ilustracje i zostają wstawione do przetłumaczonej instrukcji, mogą pojawić się najróżniejsze pytania. Na przykład:
A dlaczego tu jest tak przetłumaczone?
To chyba miało znaczyć coś innego?
Tutaj rysunek pokazuje odwrotny kierunek…
I w tym momencie mamy klasyczne zderzenie dwóch światów: świat dokumentu, który już istnieje oraz świat rzeczywistości, który właśnie do niego dojechał. Tłumaczenie przestaje być projektem zakończonym. Staje się produktem do poprawienia.
Jeżeli teraz taka instrukcja zostanie odesłana do biura tłumaczeń, prawdopodobnie będzie ją poprawiać ktoś inny, a nie tłumacz, który ją przełożył. Jaki będzie rezultat końcowy, nie wiadomo.
Nawet jeżeli firma prześle instrukcję ze zdjęciami bezpośrednio do współpracującego tłumacza, koszt weryfikacji i poprawy wpływa na całkowite koszty projektu. Trochę jednak głupio, prawda? Do tego koszt ponownego DTP, ponieważ korygowany tekst najprawdopodobniej będzie dłuższy lub krótszy, nie będzie się mieścił w ramce, przeskoczy na kolejną stronę, zmieni się numeracja zdjęć, schematów itp.
Czasem chodzi o poprawienie kilku zdań. Czasem wstawienie zdjęć powoduje kaskadę zmian w całych rozdziałach, bo nagle się okazuje, że trzeba w całej instrukcji zmienić nazwę jakiegoś elementu. Jeżeli nowa nazwa jest innego rodzaju (np. zmiana z rzeczownika męskoosobowego na niemęskoosobowy), dochodzi też zmiana końcówek czasowników, przymiotników itp.
Miało być szybciej i taniej, a wyszło jak zwykle.
Na szczęście cały ten bałagan z brakującymi zdjęciami, domysłami i poprawkami da się bez większego trudu ominąć. Nie potrzeba do tego rewolucji w procesach, nowych systemów ani zespołu konsultantów w garniturach. Wystarczy zdrowy rozsądek i kilka prostych zasad, które oszczędzają wszystkim nerwów.
To jest podstawa. Bez gwiazdek, bez wyjątków typu „wersja tymczasowa/do uzupełnienia/...”.
Zasada jest właściwie tylko jedna. Tłumacz powinien już na samym początku dostać komplet materiałów, z którymi ma pracować, czyli:
Jeżeli w tekście jest „patrz rys. 4”, to ma to jakikolwiek sens tylko wtedy, gdy rysunek 4 naprawdę istnieje w tym samym dokumencie.
To także moment, w którym można tak przygotować dokumentację techniczną, aby realnie obniżyć koszty tłumaczenia w całym projekcie.
Czasem naprawdę nie da się inaczej. Projekt żyje, konstrukcja się zmienia, coś jeszcze dojeżdża. W porządku. Ale to jest dokładnie ten moment, kiedy warto uczciwie powiedzieć, że coś jeszcze nie jest gotowe i może się zmienić. Dzięki temu tłumacz nie traktuje tekstu jako wersji ostatecznej i nie zamyka za szybko pewnych rozwiązań terminologicznych. Późniejsze poprawki nie są zaskoczeniem, tylko naturalnym etapem. Możliwe też, że w takim przypadku koszty tłumaczenia nie wzrosną, ponieważ tłumacz uwzględni poprawki w ofercie i wykona je bez dodatkowych kosztów. Żadnych niespodzianek finansowych. Czyż to nie miła wiadomość?
Wysyłanie instrukcji do tłumaczenia bez rysunków, bez warstwy ilustracyjnej, wygląda jak sprytny skrót. W praktyce bardzo często jest to skrót przez środek pola minowego. Bez kontekstu wizualnego tłumaczenie opiera się na domysłach i intuicji, które nie zawsze trafiają w punkt. Tłumaczenie może też po prostu być niezgodne ze stanem rzeczywistym, pomimo iż jest poprawne. Późniejsze zdjęcia i rysunki wymuszają korektę, a koszty całego projektu zamiast maleć, zaczynają się niepokojąco rozrastać.
Usuwanie rysunków z instrukcji to jeden z przykładów decyzji, które w projektach eksportowych mogą generować realne ryzyko. Więcej na ten temat w tekście Tłumaczenie instrukcji obsługi na eksport.
