tłumaczenia i lokalizacja gier Jak wygląda proces lokalizacji gier?


Teksty w grze dzielą się na:

  • lokalizacja oprogramowania a) zawartość interfejsu użytkownika – np. „Nowa Gra”, „Załaduj”, „Głośność BMG”, „Ustaw czułość myszki”, „Wciśnij START”, „Poznaj twórców gry”, „Czy na pewno chcesz wyjść z gry?”, etc.
  • b) content związany z gameplay’em, zarówno pisany, jak i mówiony – np. dialogi pomiędzy bohaterami, opisy poziomów, narracja, etc.
  • c) zawartość instrukcji użytkownika

Każda z tych grup wymaga osobnego podejścia.

Zawartość interfejsu użytkownika

A) wiąże się z użyciem technicznej terminologii i stosowaniem ogólnie przyjętych w danym kraju standardów, do których przyzwyczajeni są użytkownicy. Np. „Nowa gra” mogłaby przyjąć zależnie od fantazji projektanta czy tłumacza formy takie jak „Inicjacja rozgrywki”, czy też „Początek”, jednak wywołałoby to konfuzję u gracza i zaburzyło czytelność interfejsu. Bywają wyjątki od tej reguły, oczywiście. Z rozmaitych przyczyn artystycznych, tych związanych z burzeniem „czwartej ściany” i przekraczaniem „boundaries” (pola gry), game designer gry może uznać za stosowne użyć czegoś w stylu „Azaliż życzysz sobie, panie, wrócić do przerwanej uprzednio wyprawy?” i zadaniem tłumacza będzie takie przetłumaczenie frazy, by oddać styl i klimat, a zarazem dać jasno do zrozumienia graczowi, że chodzi o zwyczajne załadowanie stanu gry.

Content

B) Tłumaczenie contentu jest najbardziej interesującym i wymagającym ogromnej wiedzy i talentu elementem pracy lokalizatora, porównywalnym jedynie do tłumaczenia literatury, tylko że z szeregiem utrudnień, które są nieobecne w pracy tłumacza publikacji papierowych. Szerzej je omówimy poniżej.

Instrukcja użytkownika

C) Instrukcja jest tworzona przez dewelopera, który najlepiej ze wszystkich zna swój produkt. Tłumacz musi bardzo ściśle współpracować z producentami i działami DTP dewelopera i wydawcy, by prawidłowo przetłumaczyć manual. „Prawidłowo” oznacza tu nie tylko poprawność i jakość tłumaczenia. Bardzo ważna jest merytoryczna zgodność, nie ma tu pola dla dowolności i nadinterpretacji. Każdy element gry musi być opisany dokładnie tak, jak przewidział to deweloper, by uniknąć wprowadzania w błąd użytkowników – nikt nie lubi sytuacji, gdy próbując załadować grę, skasuje ją i to tylko dlatego, że w instrukcji był błąd w tłumaczeniu. Ponadto należy wziąć pod uwagę projekt graficzny manuala i okładek; jeżeli grafik DTP przeznaczył na opis gry na tylnej okładce przestrzeń mieszczącą od 100-120 znaków, tyle wynosi limit dla tłumaczenia. A że np. język hiszpański jest „dłuższy” od angielskiego o około 30%

Lockits

lokalizacja gier Wszystkie wymienione powyżej teksty są ekstraktowane przez dewelopera do osobnych dokumentów, zwanych lockits. Przyjmują one formę plików tekstowych, doc’ów lub najczęściej arkuszy kalkulacyjnych. Ta ostatnia metoda jest najwygodniejsza z punktu widzenia programisty, bo pozwala mu „parsować” (upraszczając: wstawiać) „stringi („ciągi”) znaków bezpośrednio do kodu źródłowego gry na zasadzie „wyświetl w tym miejscu zawartość komórki B816”. W ten sposób unika się konieczności tworzenia kilku wersji kodowanego na „sztywno” (od „hard coding”) kodu źródłowego na rzecz „dynamicznie” wyświetlanych tekstów. Brzmi to skomplikowanie, ale jest naprawdę proste i logiczne.

Posłużmy się przykładem:

Mamy zdanie: „I saw her yesterday”, ma się ono pojawić wyświetlone na ekranie w pewnym momencie gry:

cout << „\n\n\nI saw her yesterday\n” << endl;

Załóżmy, że gra ma być w pięciu europejskich jezykach. Przy kodowaniu „na sztywno” programista musi przygotować pięć wersji kodu:

  1. cout << „\n\n\nI saw her yesterday\n” << endl;
  2. cout << „\n\n\nLa vi ayer\n” << endl;
  3. cout << „\n\n\nJe l’ai vu hier\n” << endl;
  4. cout << „\n\n\nIch sah sie gestern\n” << endl;
  5. cout << „\n\n\nWidziałem ją wczoraj\n” << endl;
Mało czytelne, generujące błędy, marnujące cenny czas programisty podejście. W związku z tym programista wybiera bardziej ergonomiczną opcję: jako że zdanie „I saw her yesterday” znajduje się w komórce B816 w lockit’cie, wystarczy użyć jednej linijki, by kazać programowi wyświetlać w danym miejscu gry żądaną frazę, bez względu na to, w jakim języku jest napisana:
cout << „\n\n\n$B816\n” << endl;
Takie użycie arkuszy kalkulacyjnych jest najwygodniejsze dla programisty, ale najgorsze z punktu widzenia tłumacza. Każda komórka musi być kliknięta i przetłumaczona…

Nie wydaje się to strasznym zadaniem, ale jeśli mówimy o lockitach składających się z kilkuset tysięcy stringów, to straty czasu i wysiłku poświęconego na przeklikiwanie się przez gąszcz komórek są już bardzo istotne i wpływają mocno na ergonomię pracy i czas jej trwania. Luksusem jest otrzymanie lockit’a w formacie akceptowanym przez edytory tekstu, wówczas można się skupić wyłącznie na tłumaczeniu – ale jeśli istnieje gdzieś deweloper, który ma na sercu wygodę lokalizatorów i poświęca nadgodziny na przetwarzanie „exceli” na „wordy”, to z pewnością nie ma on siedziby na tej planecie.

Stringi w lockit, a kontekst

Kluczową sprawą dla tłumaczenia jest zrozumienie danej frazy, a jest to często niemożliwe bez znajomości kontekstu, w jakim jest ona osadzona. Jako że pierwotne teksty gry są napisane niemal zawsze w mocno bazującym na kontekstowości języku angielskim, można sobie wyobrazić wagę tej kwestii dla lokalizatora gier.

Wyobraźmy sobie, że w komórce C1067 w lockit mamy następujący tekst do przetłumaczenia:

  • I GOT IT

Po chwili namysłu tłumacz decyduje, że zapewne oznacza to najpowszechniej używane „Mam to”. Skutkiem tego w finalnym produkcie znajduje się następujący dialog:

  • Bohater A: „Szeregowy Hopkins, zasady użycia broni, określone w spisie procedur Federacji 9 Sektora, wyraźnie nakazują otwierać ogień wyłącznie do potwierdzonych celów?! Rozumiecie?!
  • Bohater B: „Dobra, dobra, mam to”.
  • Bohater A: „Co to znaczy 'łapię’? Jeśli już, to 'rozumiem, sir’!!!”
  • Bohater B: „Mam to, sir!”
Mamy tu klasyczny przypadek dialogu zniszczonego tłumaczeniem. Translator nie znał kontekstu stringa umieszczonego w komórce C1067 i dokonał niewłaściwego założenia, rujnując sens wypowiedzi bohaterów gry. Takie przykłady można mnożyć w nieskończoność. Weźmy na przykład frazal „SET UP”. Możliwe znaczenia:

  • utworzyć
  • ustawiać
  • zainstalować
  • zakładać
  • ustanawiać
  • organizować
  • umieszczać
  • wystawiać
  • zmontować
  • wysunąć
  • rościć
  • powracać do zdrowia
  • dawać komuś start życiowy

Konia z rzędem temu tłumaczowi, który napotykając SET UP w lockit’cie bez podanego kontekstu, zdoła wybrać (czy raczej wylosować) właściwe znaczenie. Tu jest właśnie ta wspomniana różnica pomiędzy pracą tłumacza literatury, a contentu gry. Ten drugi nie ogarnia całości materiału, często nie zna wszystkich kontekstów, w jakich pojawiają się frazy do tłumaczenia, a musi być nie mniej precyzyjny.

Dobry lockit zawiera opisy kontekstu oraz „trigger’y”. „Trigger” to w informatycznym slangu warunek, którego spełnienie oznacza wywołanie określonej akcji, w tym wypadku – wyświetlenie danego ciągu znaków. Na przykład:

„SET UP // when you create a new multiplayer game” – czyli mamy string, który został osadzony w kontekście; wiemy już, że chodzi o „USTANAWIANIE”

„I GOT IT // every second time player finds a health pack” – tu mamy string z podanym triggerem; wiemy już, że chodzi o „MAM TO”

Oczywiście tak dobrze i wyczerpująco opisane lockit’y to luksus, na który często zapracowanych programistów i producentów dewelopera po prostu nie stać. Nie tyle z braku dobrej woli, co czasu. Wówczas zadaniem tłumacza jest dopytanie ich o kontekst lub sprawdzenie osobiście w „buildzie” (slangowo „robocza kopia gry”), o co „chodziło autorowi”. Tak jest, dobry tłumacz gier powinien być także testerem gier i graczem. Pomaga mu to nie tylko lepiej zrozumieć tłumaczony materiał i określić konteksty, ale i ułatwia kontakty z deweloperami gier. Twórcy gier to hermetyczna i elitarna grupa zawodowa nawet jak na informatyczne standardy. Grupa ta bardzo ceni i szanuje ludzi „who can speak the language” i bynajmniej nie mamy tu na myśli angielskiego. Jeśli tłumacz wie, co to znaczy „sfragować kolejnego nooba na striku ponad sto” lub „kiedy flaga trigeruje stejt purdż na module GUI, to mam kraszbloka, reproduktability 100%, już ci daję patha” – to będzie mu się współpracować z deweloperami gier lepiej, niż dobrze.

Stringi, a limity znaków

lokalizator gier W odróżnieniu od tłumacza literatury, lokalizator gier musi pracować ze świadomością ścisłych limitów znakowych. Bardzo często w programie przewidziano ograniczona liczbę znaków na wyświetlenie danego komunikatu, czy stringa. Wyobraźmy sobie na przykład szyld karczmy w grze RPG. Mamy obiekt 3D i teksturę drewna, oraz dynamiczny napis „INN”, ładnie skomponowany z szyldem, wypełniający go w 90%. Musimy go zlokalizować. Pół biedy, jeśli będzie to język duński („KRO”), czy irlandzki („OSTA”), ale jeśli mamy tłumaczyć na chorwacki („GOSTIONICA”), estonski („VOORASTEMAJA”), czy litewski („UžEIGOS NAMAI”) to jesteśmy w kłopocie. Jak z tego wybrnąć?
No dobrze, ten przykład jest tendencyjny, przyznajemy – zauważcie, że w większości gier napis INN na szyldach nie jest nigdy tłumaczony z angielskiego; wiecie już, dlaczego.

Mówiąc jednak bardziej serio, limity znaków są tak samo ważnym obostrzeniem, jak limity wielkości plików graficznych, czy dopuszczalne rozmiary asetów audio. Tłumacz gry bardzo często musi zmieścić się w określonej ramce, dymku, czy przestrzeni na grafice, jak wspomniany wyżej szyld. Język angielski jest „zwarty”, bardziej konotacyjny i kontekstowy, niż denotacyjny. Do wyrażenia tych samych idei w innych językach potrzeba niemal zawsze więcej miejsca. Sztuka dobrej lokalizacji polega na mistrzowskim dopasowaniu fraz, idiomów, struktur gramatycznych, form koniugacyjnych i deklinacyjnych, by wyrazić to samo za pomocą mniej więcej tej samej liczby znaków.

Często spotykane sytuacje to wystający gdzieś poza ramkę lub ekran jeden znak, który zmusza tłumacza do przefrazowania całego tłumaczenia danej frazy. Lub wybłaganie u producenta po stronie dewelopera powiększenia ramki, co przy dobrej argumentacji typu „jestem po filologii na Jagiellonce i specjalizacji na Oxfordzie, zajmuję się tłumaczeniami dłużej, niż istnieje branża gier i jestem w 100% pewien, że nie da rady tego ująć krócej bez zniszczenia sensu frazy” może się czasem powieść.

Voice-Overs

lokalizacja gry To element contentu, który wymaga odrębnego podejścia. W odróżnieniu od treści pisanych i wyświetlanych przez system gry obowiązują limity nie znaków, ale fonem i sylab. Przetłumaczone frazy muszą być najczęściej podobnej długości, jak teksty czytane przez oryginalnych aktorów. Skojarzenie z dubbingiem filmów jest jak najbardziej na miejscu, obowiązują tu identyczne reguły. Język dialogów jest naturalnie inny, niż literacki. Główne wyzwanie, stojące przed lokalizatorem, polega na jak najwierniejszym oddaniu oryginalnego stylu wypowiedzi, idiosynkrazji, kolokwializmów, idiomów, frazali, archaizmów, wulgaryzmów, błędów językowych, przejęzyczeń, et caetera.

Konieczność poznania kontekstu jest tutaj kluczowa. Zobaczmy na przykład tę frazę, którą wypowiada Deckard Cain w Diablo II: „I believe now that Tristram’s hero was that Dark Wanderer who passed this way before the Monastery fell.” Możliwe przykładowe tłumaczenia:

  • „Wierzę teraz, że to bohater Tristrama był tamtym Ciemnym Wędrującym, który minął to miejsce zanim spadł Klasztor”.
  • „Teraz uważam, że bohater z Tristram to Ubrany na Czarno Podróżnik, który przeszedł tę drogę zanim został zburzony Klasztor”.

Tristram to nie osoba, to osada. „Dark Wanderer” to demon, Pan Grozy, Diablo, główny antagonista gry, który zasługuje na znacznie bardziej „klimatyczną” nazwę. Klasztor zaś został sprofanowany przez demony, a nie zburzony, czy też zrzucony z urwiska, na którym został zbudowany.

I co najważniejsze, „Tristram’s hero” to nikt inny, jak sam bohater Diablo 1, który w epickiej podróży przez piekło dopadł Pana Grozy i zdołał pokonać jego samego i jego hordy, ratując przy okazji życie całej populacji osady Tristram. Na koniec gry wbił sobie Kamień Duszy Diablo głęboko w czaszkę, by uwięzić w sobie jestestwo demona i ujarzmić go mocą żelaznej woli i czystego serca. Teraz wraca w Diablo 2; niestety wszystko wskazuje na to, że legendarny bohater przegrywa walkę z ukrytym w sercu demonem i zaczyna mu pomagać wbrew woli… Wielki wojownik, którego gracz prowadził w Diablo 1 zmienia się w dokładnie tego samego potwora, z którym walczył. Zdesperowany i przerażony wyrusza na najdalsze krańce świata, by zyskać pomoc starożytnego Zakonu Horadrimów, zanim Trójca Piekieł połączy siły i sprowadzi na Ziemię Armaggeddon.  A jego krokom towarzyszy rosnąca w siłę każdego dnia Groza, Zniszczenie i Śmierć… (co widać w sekwencji filmowej, od której zaczyna się gra).

Przydługi i pretensjonalny opis, ale osadza wypowiedź Deckarda Caina we właściwym kontekście i możemy zaryzykować nieco lepsze tłumaczenie. Aktor będzie mógł lepiej przekazać powagę sytuacji, niedowierzanie, przerażenie, rozpacz, sugestię, że Zło właśnie wygrywa z Dobrem, ukryte w słowach mędrca z Tristram:

  • „Teraz sądzę, że nie kto inny, ale sam zbawca Tristram był owym Mrocznym Wędrowcem, który nawiedził te okolice, nim na Klasztor spadła zagłada.”

Bestiariusz Diablo

Na zakończenie niniejszego materiału nie mogę nie wspomnieć o najbardziej kultowym i legendarnym już przykładzie polonizacji gry, która poszła kompletnie „nie tak” – ale jest przy okazji tak zabawna i charakterystyczna, że została w pełni zaakceptowana przez fanów. Mowa oczywiście o bestiariuszu Diablo 2, znakomicie skądinąd przetłumaczonej przez CD Projekt gry. W owym „hack and slash’u” (gatunek RPG polegający niemal wyłącznie na walce) gracz mierzy się z legionami potworów, które musi pokonać w drodze do ostatniego bossa. Każdy typ demona i sub-bossa ma odrębną nazwę. Stawiając na losowość podczas tworzenia imion, twórcy gry zgrupowali osobno rzeczowniki i określające je przymiotniki w dopełniaczu. Nazwa potwora jest tworzona przez silnik gry na zasadzie losowego doboru rzeczowników i przymiotników. O ile po angielsku to jeszcze ujdzie, tak po przetłumaczeniu tychże słów doszło do przezabawnych lapsusów, a odkrywanie nazw potworów i parskanie śmiechem stało się nieodzownym elementem grania w spolonizowaną wersję Diablo2. Zobaczcie sami poniżej na garści przykładów. Osobno owe słowa nie są niczym niezwykłym, ale połączcie je losowo… Miłej zabawy.
Grupa 1:
  • Wrzód
  • Cierń
  • Podrzynacz
  • Spaczeniec
  • Upadły
  • Pomiot
  • Szaman
  • Wojowniczka
  • Rzygacz
  • Rycerz
  • Drzewiec
Grupa 2:
  • Rozpaczy
  • Grozy
  • Żółci
  • Smrodu
  • Ohydy
  • Ropy
  • Zgnilizny
  • Masakry
  • Wnętrzności
  • Nienawiści

Dodaj komentarz