Marta Bartnicka, Ewa Dacko
Zajmujesz się tłumaczeniami od ładnych kilku lat, masz wykształcenie lingwistyczne i dziesiątki tysięcy przetłumaczonych słów na koncie, są dziedziny, w których jesteś ekspertką lub ekspertem — ale słysząc hasło „lokalizacja oprogramowania”, nie masz pewności, o czym mowa i jak się za to zabrać?
Nie tylko Ty!
Lokalizacja to tłumaczenie interfejsu — czyli widocznej części programu, apki, strony internetowej — na różne języki i dostosowanie tego programu (apki, strony) do obsługi przeróżnych ustawień narodowych (formatu daty, adresu pocztowego itd.).
W praktyce lokalizacja jest jak kanalizacja — nikt o niej nie mówi, dopóki działa. Jako konsumenci korzystamy ze sklepu internetowego czy kupujemy grę i oczekujemy, że wersja polska po prostu tam będzie. Niełatwo znaleźć lokalizację w programach studiów dla tłumaczy (zrobimy przegląd w najbliższej przyszłości). Na branżowych forach i grupach temat ten poruszany jest dość rzadko — a wtedy z kolei dyskusja często jest tak hermetyczna, że postronnym nie bardzo chce się w nią zagłębiać.
Bo jak najczęściej tłumacze dowiadują się o lokalizacji?
W wariancie optymistycznym pewnego dnia dostajesz projekt opisany jako „lokalizacja interfejsu aplikacji do czegoś tam”, opatrzony krótkim opisem tej aplikacji, przykładowymi zrzutami ekranu, a w wersji idealnej — poprzedzony szkoleniem z nowego typu tłumaczenia.
Projekt lokalizacyjny jest w takim przypadku dobrze przygotowany, więc choć znaczki w rodzaju {0} z początku trochę straszą, to CAT nie pozwala ich zepsuć, a Ty już wiesz, że nie można ich usunąć i co więcej — jak je umieścić w tekście docelowym.
Spokojnie zabierasz się więc za tłumaczenie, bo termin jest realistycznie odległy, a kiedy tylko masz jakieś wątpliwości, klient galopuje do Ciebie na tęczowym jednorożcu, aby je wyczerpująco wyjaśnić.
Hej, przecież nie ma tęczowych jednorożców!
Faktycznie, trochę się, nomen omen, zagalopowaliśmy.
W wariancie bardziej realistycznym o tym, że robisz projekt lokalizacyjny, dowiadujesz się w trakcie tłumaczenia. Pewnego dnia dostajesz plik w Excelu opisany enigmatycznie jako „tekst techniczny”, a w środku — krótkie frazy z dziwnymi znaczkami, posortowane alfabetycznie.
W trakcie pracy zaczynasz się domyślać, że to chyba program. Jakiś.
Niektóre segmenty są oczywiste, znaczenia innych możesz się ze sporym prawdopodobieństwem domyślić, ale w niektórych przypadkach bez szklanej kuli po prostu nie jesteś w stanie tego (dobrze) zrobić.
Ratunku, skąd mam wiedzieć, co znaczy „left”?
Z lewej? Do lewej? Lewy, lewa, lewe…? A może chodzi o to, że czegoś ileś tam zostało? Komunikacja z klientem zlecającym tłumaczenie jest tu niezbędna — nie wiedząc, gdzie w interfejsie programu pojawi się dane słowo czy wyrażenie, nie jesteś w stanie właściwie go przetłumaczyć.
Tak samo jak w tłumaczeniach literackich czy prawniczych: kontekst ma ogromne znaczenie. W projektach lokalizacyjnych kontekstem jest przeznaczenie programu, którego interfejs właśnie tłumaczysz, układ tego interfejsu i jego funkcje, czyli sposób działania.
I to się da zrobić!
Dobre przygotowanie projektu lokalizacyjnego wcale nie jest trudne, ponieważ:
- Większość współczesnych CAT-ów poradzi sobie z typowymi formatami programistycznymi — Excel nie jest niezbędny.
- Symbole zastępcze, tagi, znaczniki czy jak je zwać — te wszystkie
{0},#cośtami inne cuda — nie są takie straszne, trzeba tylko znaleźć im dobre miejsce w segmencie. - Programiści często zostawiają w tekstach do lokalizacji całkiem sporo przydatnych informacji, dzięki którym wiemy lepiej, o co chodzi, nawet nie widząc samego programu.
A: {0}, {1} to zmienne, których wartości będą wstawiane w trakcie działania programu; nie można ich usunąć w tłumaczeniu.
B: Nie należy tłumaczyć tekstów @release@ ani @version@.
C: Teksty Login, Configure i Cancel znajdą się na przyciskach, więc domyślnie należy je przetłumaczyć krótko i jako polecenia.
Podsumowując: co masz zrobić, jeśli zamiast „tekstu technicznego” w formacie DOC czy PDF trafił do Ciebie plik Excela z (jak podejrzewasz) fragmentami interfejsu jakiejś aplikacji, a słowo „lokalizacja” nadal nie brzmi przyjaźnie?
TL; DR: 6 zasad pracy przy projekcie lokalizacyjnym
1. Nie panikuj.
To uniwersalna rada, zawsze się sprawdza.
2. Nie ma głupich pytań.
Na linii między klientem, biurem a tłumaczem informacje lubią ginąć. Upewnij się, czy dodatkiem do pliku Excela nie były jakieś zrzuty ekranu, dokumentacja, komentarze albo inne przydatne dane. Poproś o nie i korzystaj z nich.
3. Myśl jak użytkownik.
Pamiętaj, że Twoje tłumaczenie znajdzie się gdzieś na ekranie i ktoś będzie chciał za jego pomocą skutecznie wykonać jakieś zadanie (kupić buty) albo osiągnąć cel (zniszczyć orków). Jeśli jest taka możliwość, pobaw się oryginalną wersją tłumaczonej aplikacji lub strony. Zapoznaj się z podstawowymi zasadami UX writingu.
4. Pilnuj spójności.
Jeśli „dotłumaczasz” nowy fragment już zlokalizowanego produktu, zadbaj o zgodność z wcześniejszymi tłumaczeniami, dokumentacją czy pomocą. Jeśli tłumaczysz od zera — pomocna będzie wiedza, czy interfejs jest np. dla Windows, czy Androida, albo czy ma współpracować z systemem SAP (każdy z tych systemów ma specyficzną terminologię po polsku — planujemy zrobić zestawienie ogólnodostępnych glosariuszy).
5. Uważaj na zmienne.
Te wszystkie {0} oznaczają liczby, daty, nazwy własne albo rzeczowniki w mianowniku (czasami da się to sprawdzić, np. w komentarzach, albo dopytać klienta). Trzeba je tak „opakować” w zdanie, żeby miało sens, co — zwłaszcza w polszczyźnie — wymaga często niezłej gimnastyki składniowej.
6. Rób QA
…czyli automatyczną kontrolę jakości (o której napiszemy więcej przy innej okazji). Narzędzia CAT mają funkcje, które pozwolą sprawdzić, czy znaczniki i symbole zastępcze są we właściwych segmentach, czy w tekście nie ma niepoprawnych znaków (które mogłyby spowodować, że kod w ogóle przestanie działać), czy liczby i wartości się zgadzają, czy kluczowe terminy są tłumaczone spójnie itd.
A jeśli chcesz wiedzieć więcej i bezpiecznie poćwiczyć lokalizację w praktyce, zapisz się na nasze szkolenie.
