Symbole zastępcze w tłumaczeniach i jak sobie z nimi radzić

Pamiętam, kiedy po raz pierwszy zaangażowałem się w projekt lokalizacji oprogramowania. Zostałem przydzielony do tłumaczenia interfejsu użytkownika pewnego przemysłowego systemu komputerowego przy użyciu skomplikowanego narzędzia do lokalizacji oprogramowania. Nie miałem problemów z kwestiami technicznymi, ale tłumaczenie interfejsu użytkownika było dla mnie nowością i zadanie to okazało się prawdziwym wyzwaniem.

W rzeczywistości styl tych tekstów nie był dla mnie aż tak obcy. Będąc osobą nieco obeznaną z technologią informacyjną, dobrze znałem język „komputerowy” używany zazwyczaj w oprogramowaniu (pod wpływem chatbotów i interfejsów głosowych moje zdanie uległo jednak radykalnej zmianie). Naprawdę zagadkową częścią były te dziwnie wyglądające fragmenty: {0}, %d, %setup% i $stop$. Nie miałem pojęcia, co one oznaczają i czy słowa uwięzione między symbolami powinny być tłumaczone, czy nie, więc w krótkim czasie popełniłem wiele błędów. Znaki nowej linii, reprezentowane jako \n, były ostatecznym ciosem dla mojej pewności siebie. Nigdy wcześniej ich nie widziałem, a najgorsze było to, że często łączyły się z innymi słowami. Jakby sytuacja nie była wystarczająco absurdalna, tekst był w języku niemieckim, co sprawiało, że naprawdę trudno było stwierdzić, czy \nein miało oznaczać „nein”, czy „\n” + „ein”. Kierownik projektu musiał żałować swojej decyzji o przydzieleniu tego zadania takiemu głupkowi jak ja, po tym jak zasypano go pytaniami. Być może nawet wyładował się na Twitterze.

Odkrycie, że symbole zastępcze w przetłumaczonych plikach dla pilnego projektu w magiczny sposób zniknęły. #PMproblems #StartPanicking

— Lau Velázquez (@geekylau) 9 października 2013 r.

Tłumacze, którzy tłumaczą symbol zastępczy $DepartureTime$ jako $HeureDépart$, są po prostu konsekwentni.

— Olivier Oswald (@ooswald) 27 lipca 2011 r.

Tłumacze, którzy tłumaczą symbol zastępczy $Departure Time$ jako $HeureDépart$, są po prostu konsekwentni.

Ten moment, kiedy tłumacz postanawia zmienić formę cudzysłowów i połowa zmiennych w grze znika.

— Vojtěch Schubert (@falagor)12 stycznia 2016 r.

Po latach wspomnienia mojego pierwszego doświadczenia wywołują uśmiech na mojej twarzy. Nie trzeba dodawać, że zawsze poświęcam czas tłumaczom, aby wyjaśnić im, jak działają zmienne. Najlepszym sposobem na uniknięcie błędów i zaoszczędzenie czasu dla siebie i swojego zespołu jest stosowanie wyrażeń regularnych. Można je wykorzystać do przekształcenia zmiennych w obiekty, których nie można edytować i które można łatwo śledzić. W różnych programach obiekty te mają różne nazwy. W Smartcat nazywamy je symbolami zastępczymi. Jeśli zastanawiasz się, czym są wyrażenia regularne, to nie mają one nic wspólnego z pogawędkami. Są to wzorce używane do dopasowywania i manipulowania kombinacjami znaków. Nauka wyrażeń regularnych nie wymaga umiejętności programowania. Kliknij na tę prostą prezentację przygotowaną przez Thomasa Vackiera, eksperta ds. lokalizacji w Yamagata Europe, aby zrozumieć, czym są wyrażenia regularne (w skrócie „regex”).

Tajemnicze symbole

Jako szybki przykład weźmy kilka wersów piosenki I’m Gonna Be (500 miles) zespołu The Proclaimers:

Ale przeszedłbym 500 mil I przeszedłbym kolejne 500 Tylko po to, by być człowiekiem, który przeszedł tysiąc mil Aby upaść u twoich drzwi

Powiedzmy, że chcemy, aby ten tekst zmieniał się za każdym razem, gdy słuchacz przenosi się w inne miejsce. Będziemy potrzebować do tego zmiennych:

Ale przeszedłbym %$1s mil I przeszedłbym jeszcze %$2s Tylko po to, by być człowiekiem, który przeszedł {spelled-number} mil Aby upaść u twoich {location}

Jakie niebezpieczeństwa się tu kryją? Ważne znaki mogą zostać usunięte i/lub niewłaściwie użyte. Cyfry w %$1s muszą być ułożone w sekwencyjnym porządku, a „spelled-number” i „location” nie mogą być tłumaczone. Niestety, nie wszyscy o tym wiedzą.

„Ale dlaczego po prostu nie zatrudnić profesjonalnego tłumacza, zamiast zajmować się tym całym bałaganem dla nowicjuszy?”, można zapytać. Niezależnie od rzeczywistych powodów, warto pamiętać: nikt nie rodzi się profesjonalistą w dziedzinie lokalizacji, ale każdy, kto zmagał się z pierwszymi krokami i zdobył w tym procesie bezcenne doświadczenie, może nim zostać.

Odporny na nowicjuszy, czyli jak ocalić świat

Co więc możemy zrobić, aby zapobiec katastrofom i zaoszczędzić czas potrzebny na edycję? Opiszmy zmienne za pomocą wyrażeń regularnych:

• W przypadku zmiennych z kolejnymi numerami: %\$\ds

• Dla zmiennych ujętych w nawiasy klamrowe: \{.+?\}

Osobiście uważam ten arkusz ściągawki za bardzo przydatny do tworzenia wyrażeń regularnych, a regex101.com to świetne narzędzie online, które polecam do testowania. Teraz prześlijmy plik zawierający zmienne do Smartcat. Oto, co zobaczymy:

Zmienne są wyświetlane jako fioletowe jednostki, które oczywiście nie podlegają tłumaczeniu i można je bezpiecznie przenieść z tekstu źródłowego do języka docelowego za pomocą skrótu klawiaturowego. Elementy te pozostaną nienaruszone w przetłumaczonym dokumencie po ich pobraniu. Wykorzystanie symboli zastępczych nie ogranicza się do projektów lokalizacyjnych. Wyobraź sobie, że masz dużą specyfikację techniczną pompy powietrza zawierającą tysiące pozycji. Każda pozycja ma przypisany kod zamówienia, a wszystkie kody wyglądają bardzo podobnie, więc łatwo je pomylić.

Jeden błąd w tym miejscu może mieć bardzo niekorzystne konsekwencje. Mogą wystąpić błędy podczas wysyłania zamówień z magazynu, a prawidłowa instalacja również może być problematyczna. Klient poniesie straty lub, co gorsza, nieprawidłowe dane mogą spowodować problemy techniczne, które z kolei mogą doprowadzić do katastrofy ekologicznej. Symbole zastępcze nie są tłumaczone, powinny być po prostu bezpiecznie przeniesione do języka docelowego, więc po co tracić na nie czas? Znajdźmy wszystkie kody zamówień za pomocą tego eleganckiego wyrażenia regularnego [A-Z]{2}\d{4}\-\d{4} i w magiczny sposób zamieńmy je w elementy, których nie można edytować:

To świetny sposób na ułatwienie i przyspieszenie procesu tłumaczenia (a także jego części związanej z edycją)!

W tej chwili symbole zastępcze są domyślnie obsługiwane tylko w popularnych formatach plików lokalizacyjnych. Jeśli chcesz używać ich w innych typach dokumentów, daj nam znać.

Skontaktowałem się z moimi współpracownikami, pytając ich o doświadczenia związane z symbolami zastępczymi.

Fiodor Bezrukow, dyrektor wykonawczy w Logrus IT (biuro w Kijowie)

„Korzystanie z symboli zastępczych i tagów w formatach dokumentów jest dla nas powszechną praktyką. Są one nieocenioną pomocą, gdy klienci przesyłają pliki Excel zawierające znaczniki HTML lub XML. Dzięki obsłudze symboli zastępczych i wyrażeń regularnych w Smartcat obsługa takich zasobów stała się znacznie łatwiejsza i wygodniejsza”.

Marina Ilyinykh, kierownik ds. lokalizacji w Bookmate

„W interfejsach użytkownika naszych aplikacji często używamy zmiennych i formatowania. Zastąpienie tagów i zmiennych symbolami zastępczymi pozwala nam przeprowadzać automatyczne kontrole spójności i zabezpieczać ważne dane, takie jak ceny, daty subskrypcji i linki”.

Yannis Evangelou, dyrektor generalny lexiQA, podzielił się swoimi mieszanymi uczuciami:

Yannis Evangelou, dyrektor generalny lexiQA

„Częstym problemem jest tłumaczenie tekstu zawartego w symbolach zastępczych, tokenach i tagach. Często ignorowane są również znaki escape. Większość z nich nie zdaje sobie sprawy, że nie są to jednostki leksykalne, które można przetłumaczyć. Kierownicy projektów również nie mają tej wiedzy. Jednak tego typu zaniedbania mogą powodować poważne błędy. Pewien tłumacz powiedział mi kiedyś, że musiał zająć się tekstem zawierającym formatowanie HTML i przetłumaczył linię <p style="border: 1px solid red;"></p> na <π στυλ="περίγραμμα: 1 πίξελ συμπαγές κόκκινο;"></π>. Twierdził, że być może programista, który będzie go używał, nie zna języka angielskiego. Kierownik projektu nie poprawił tego, ponieważ uznała, że rozumowanie tłumacza było... rozsądne!

Następnie głos zabrał Rolf Klischewski, ekspert ds. lokalizacji gier:

„Tłumacze gier często mają do czynienia z takimi sytuacjami:

I oczywiście wiąże się to z różnego rodzaju problemami.

Problem polega na tym, że niektóre miejsca docelowe wymagają użycia przedimka. Na przykład „Bahamy”, ale „Barbados”. Albo w języku niemieckim „die Schweiz” dla „Szwajcarii”. W takich przypadkach często odrzucamy projekt. Zazwyczaj radzę klientom zmienić silnik tekstowy, ponieważ nie chcę dostarczać byle czego. Programiści zazwyczaj pytają: „Czy to naprawdę taki duży problem?”. Moim zdaniem nie, ponieważ gra działa. Jak więc radzić sobie z takimi problemami? Poinformuj klienta i wyjaśnij problem. Jeśli nie może lub nie chce naprawić silnika, a Ty potrzebujesz pieniędzy, wykonaj pracę, ale upewnij się, że nie zostaniesz wymieniony w napisach końcowych.