Kurs tlumaczenia modow do Baldur's Gate II, I

by Aristo & morgan

I. Zagadnienia związane z kwestiami technicznymi

Spis treści

Słowo wstępu

Wprowadzenie

Techniczny zarys dziejów modowania

Zarys dziejów tłumaczeń

Porada wstępna

Pliki tekstowe

Wprowadzenie

Umiejscowienie

Podział

Budowa

Inne pliki

Wprowadzenie

Plik techniczny (*.tp2)

Pliki skryptowe (*.baf )

Pliki dialogowe (*.d)

Czytanie plików dialogowych *.d

Standardowy blok (v1):

Standardowy blok (v2):

Blok łańcuchowy (v1):

Blok łańcuchowy (v2):

Budowa modyfikacji

Wprowadzenie

Budowa modyfikacji WeiDu

Konstrukcja plików *.d modyfikacji typu NPC

Rodzaje wypowiedzi

Edytory

Informacje ogólne

Używanie edytorów

Obsługa gotowego tłumaczenia

Zakończenie prac

Dalsze losy przetłumaczonego pliku

Pakowanie

Słowo wstępu

Wprowadzenie

Witaj, Tłumaczko/Tłumaczu modyfikacji!

Pozwolimy sobie się tak do Ciebie zwrócić, bowiem to zapewne chęć przybliżenia modów użytkownikom języka polskiego skłania Cię do lektury niniejszego opracowania. Chcieliśmy podzielić się z Tobą latami naszego doświadczenia, bez pretensji do wyczerpania zagadnienia, każde bowiem poddawane procesowi tłumaczenia zdanie wymagałoby komentarza. Postaramy się jednak sprawić, by szeroko rozumiane kwestie techniczne nie miały już więcej przed Tobą tajemnic. Zagadnienie jest jednak na tyle obszerne, że zmusiło nas do tematycznego usystematyzowania, a następnie podzielenia na części:

I (niniejsza) – dotyczy zagadnień stricte technicznych.

II – dotyczy zagadnień językowych.

III – dotyczy tokenów.

Techniczny zarys dziejów modowania

Modowanie (czyli modyfikowanie gry – poprzez dokładanie nowej i zmienianie istniejącej zawartości) sięga czasów publikacji samej gry. Z uwagi na to, iż Baldur's Gate nie jest grą przyjazną modderom (nie zawiera żadnego Construction Seta czy Game Editora) początki – ze względu na niedoskonałość narzędzi (które dopiero sukcesywnie się pojawiały) – wiązały się z pracą metodą prób i błędów. Również dokładanie do gry nowej warstwy tekstowej stanowiło spory problem, z uwagi na problem z implementowaniem tego do gry. W przypadku większych modów (choć nie tylko ich) w grę wchodziła tylko podmiana pliku dialog.tlk (zawiera wszystkie teksty występujące w grze), w przypadku mniejszych modów opisy przedmiotów i zaklęć kodowano na ogół bezpośrednio w ich plikach (najczęściej w formacie *.tbg), podobnie w przypadku NPCów (z tym że tu zapisywano to w plikach *.iap), w ostateczności (np. przy podklasach, gdzie nie dało się tego łatwo obejść) koniecznym było ręczne dodanie tekstu przez gracza do gry.

Rewolucję przyniosło stworzenie przez W. Weimera programu WeiDu, który sprawiał, że praca nad i z modyfikacjami stała się dużo łatwiejsza, a pośród swoich rozlicznych funkcji zawierał także te dotyczące obsługi warstwy tekstowej. Od tego momentu pliki tekstowe na ogół zawarte są w plikach o rozszerzeniu *.tra.

Zarys dziejów tłumaczeń

Równie kręta i wyboista była droga, jaką przebyć musieli tłumacze modyfikacji. Pisaliśmy o problemach modotwórców, analogiczny mieli tłumaczący (a przecież są to na ogół osoby mniej obeznane technicznie, bo i do takiej wiedzy nie pretendują). Teksty nie były bowiem składowane w osobnych plikach i albo (w przypadku większych modów, jak np. tłumaczenia na CoBie modyfikacji TDD) trzeba było wyciągać je z podmienianego przez modyfikację pliku dialog.tlk, albo tłumaczyć w programie obsługującym dane pliki (np. w uznawanym obecnie za przestarzały IEEP).

Także i w tym przypadku rewolucję przyniosło WeiDu. Dziś wystarczy otworzyć plik *.tra (w skrajnym przypadku *.d) i tłumaczyć nie przejmując się niczym więcej.

Tłumaczenia na język polski pojawiały się niemal od zarania modowania, z początku wyłącznie jako indywidualne inicjatywy. Z czasem pojawiły się idee wspólnych tłumaczeń (Bezpieczna Przystań czy Tawerna Bibliotekarzy), czy wręcz grup (Children of Bhaal, Wieża Ramazitha, Evendurowe Forum tłumaczy modów czy Stars of Mystra). Dziś działa tylko ta ostatnia, jako Gwiazdy Mystry (SoM), na Forum Klanu Children of Bhaal (CoB), a prace koordynuje, określa nowe wyzwania i pomaga tłumaczącym Awatar Mystry. Obecnie stanowisko to piastuje Mistrz memory.

Porada wstępna

Nim zaczniesz tłumaczyć, upewnij się, że modyfikacja nie jest już przetłumaczona bądź tłumaczona – możesz o to zapytać tutaj. Najlepiej także, jeśli poinformujesz, że będziesz daną modyfikację tłumaczyć. Możesz to uczynić w tym dziale na Forum CoB.

Pliki tekstowe

Wprowadzenie

Wspomniane przed momentem pliki *.tra powstają w wyniku traifikacji – mianem tym nazywamy wydzielenie czystego tekstu (wraz z odsyłaczami) ze skryptów umożliwiających ich prawidłowe działanie do osobnego pliku tekstowego *.tra.

Pliki te można otwierać za pomocą programów do obsługi plików tekstowych – np. systemowego notatnika Windows, doskonalszych notatników (Notepad++ albo Notepad2), a nawet programów typu Word Pad, Microsoft Word czy Libre Office Writer. Można do tego użyć również programu o nazwie TREP.

Umiejscowienie

Czas na kilka słów odnośnie do standardowej lokalizacji plików *.tra w instalce modyfikacji (problem ten nie dotyczy tłumaczeń w ramach SoM, gdzie projekty są opracowywane przez Koordynatora, którym zazwyczaj jest Awatar Mystry) – na ogół można je znaleźć:

1) w katalogu languages, znajdują się tam foldery wszystkich języków, do których dana modyfikacja została przetłumaczona;

2) w katalogu translation(s), jw.

3) w katalogu tra, jw.

4) niektórzy modderzy umieszczają poszczególne wersje językowe bezpośrednio w katalogu głównym modyfikacji.

W przypadku problemów ze znalezieniem wystarczy otworzyć plik *.tp2 (szerzej o nim w następnej sekcji, dot. plików technicznych) i znaleźć tekst AUTO_TRA, pomiędzy tyldami podana jest ścieżka (od folderu znajdującego się w głównym katalogu modyfikacji).

Podział

Pliki *.tra zasadniczo dzielimy na dwie grupy. Zastosowana poniżej terminologia podziału ma na celu zróżnicować je ze względu na najważniejsze kryterium – pochodzenia, a co za tym idzie przeznaczenia, a to najłatwiej określić w pliku *.tp2:

W powyższym zdefiniowane zostały pliki: setup.tra, scripts.tra oraz journal.tra.

Wspomniane dwie grupy to:

1) Niezdefiniowane pliki *.tra – pochodzące z przekształcenia plików *.d – na ogół różnią się tylko rozszerzeniem (np. RYNN.D i RYNN.TRA). Są niemal zawsze numerowane od @0 (domyślny standard WeiDu, o ile nie wybierze się początkowego numeru) choć zdarzają się inne, np. w Secret of Bone Hill numeracja plików zmienionych w wersji 275 prowadzona jest od @1; z kolei w modach Vecna oraz Planar Sphere od wyższych numerów – stało się tak dlatego, że pliki zostały wydzielone z jednego, który był pierwotnym efektem traifikacji. WeiDu pozwala bowiem również na traifikację kilku (np. Quest Pack Dinga0 czy BGQE) lub nawet wszystkich (vide: mody Kulyok, np.: Assassinations, Sellswords, Reunion czy Back to Brynnlaw) plików *.d do jednego pliku *.tra.

2) Zdefiniowane pliki *.tra – na ogół jeden plik, o nazwie setup.tra albo Nazwa_moda-setup.tra (np. Reunion-setup.tra), stanowiący pochodną traifikacji pliku *.tp2 modyfikacji. Odstępstwa w tym aspekcie wykazują przede wszystkim megamodyfikacje, w których plik główny posiada czasem odmienną nazwę (np.: TDD – tp2.tra, CtB – wsetup.tra).

W jego skład często wchodzą także inne stringi o charakterze technicznym:

a) skrypty, rozumiane w tym przypadku jako pochodzące z plików skryptowych (o nich nieco później) wyświetlane nad głowami bohaterów bądź nad urządzeniami itp. teksty, a nawet dialogi, o ile pochodzą z tzw. cutscenek (czyli scen odgrywanych w grze, bez naszego aktywnego udziału jako gracza). Niektóre megamodyfikacje wydzielają go do osobnego pliku jako (RoT i NeJ – scripts.tra, CtB – script.tra, z kolei traifikator TDD nazwał plik je zawierający: setup.tra).

b) wpisy do dziennika, czyli pozbawione charakteru dialogowego zawarte w plikach *.d stringi uaktualniające lub kończące zadania (inicjowane komendami THEN UNSOLVED_JOURNAL, THEN SOLVED_JOURNAL lub THEN JOURNAL). W przypadku megamodyfikacji zdarza się wydzielanie osobnego pliku (RoT i NeJ – journal.tra, z kolei traifikator TDD nazwał plik je zawierający: setup.tra).

c) w niezwykle rzadko występujących przypadkach inne stringi – np. z plików zapewniających kompatybilność z BGT itp.

d) prawdziwi "kowboje" zza monitora nie zaprzątają sobie głowy wygodą pracy tłumacza i wrzucają wszystkie pliki do jednego, często dając przy tym inną nazwę (np. CoM_Encounters – dialog.tra czy Fishing for Trouble – english.tra).

Numeracja w nich zaczyna się na ogół od wyższych liczb (np. @20000), a przynajmniej zaczynać się powinna (w przypadku braku stringu o określonym numerze w którymś z plików *.tra, instalator bierze go z pliku setup.tra bądź innych zdefiniowanych plików *.tra – w kolejności wystąpienia w pliku *.tp2).

O zdefiniowanych plikach *.tra trochę informacji pojawi się jeszcze w dwu kolejnych częściach niniejszego podręcznika (II – językowej i III – tokenowej).

Budowa

Po otwarciu wnętrze pliku standardowo prezentuje się następująco:

Poszczególne linijki (np. @0 = ~Wh-what do you want?~ [THIEF01]) nazywamy stringami (lub liniami tekstu).

Część początkowa (przed inicjującą tyldą, czyli tutaj: @0 = ) to odsyłacz do pliku skryptowego. Tej części (z wyj. ilości spacji) pod żadnym pozorem nie modyfikujemy, w przeciwnym razie string nie będzie prawidłowo działał.

Część końcowa (za kończącą tyldą, czyli tu: [THIEF01]) to odnośnik do pliku dźwiękowego. Sprawia, że przy wystąpieniu w grze danej kwestii, odegrana zostanie także przypisana jej ścieżka dźwiękowa; jego usunięcie spowoduje natomiast, że wspomniana ścieżka w grze nie wybrzmi. Oczywiście odtwarzanym plikiem jest ten istniejący w zasobach, czyli na ogół oryginalny. Skorelowanie tego elementu z tłumaczeniem wymaga dogrania ścieżki dźwiękowej, co wykracza poza problematykę związaną z przekładem i tym samym poza zakres niniejszego poradnika, dlatego na tym zakończymy omawianie tego zagadnienia.

W celu przetłumaczenia zastępujemy oryginalną treść przekładem. Tłumaczymy tylko tekst zawarty pomiędzy tyldami (~tekst do przekładu~), pozostałej części, jak już informowaliśmy, nie tylko nie zmieniamy, ale i w ogóle nie ruszamy.

W przypadku programu TREP, plik źródłowy otwieramy bezpośrednio w nim, a tłumaczenie tekstu wpisujemy w okienku (bądź w dwóch, jeśli występuje też wersja żeńska wypowiedzi – szerzej o rodzaju w II części tego poradnika). W rezultacie przetłumaczone linijki zapisywane są w docelowym pliku .tra.

Prawidła scharakteryzowane sekcji dotyczącej plików *.tra posiadają wyjątki:

1) Nie we wszystkich modyfikacjach WeiDu wydzielono pliki tekstowe *.tra (o takim przypadku w poniższej sekcji, dot. plików skryptowych).

2) Czasem (bardzo rzadko) z jakichś względów (przede wszystkim wystąpienia tyld w tekście) niemożliwe jest użycie tyld jako obramowania stringów, wówczas stosuje się inne znaki:

1) procenty: @50 = %旅行者的收藏%

2) cudzysłowy proste: @0 = "Hey, you there!"

3) pięć tyld w rzędzie: @1 = ~~~~~Hi, mate! Welcome to "The~Wave~of~40%~Inn", my friend! Feel free to ask about everything!~~~~~

Więcej na ten temat w punkcie 2.1 tutorialu L'fa Tworzenie skryptu dialogowego.

Inne pliki

Wprowadzenie

Niemal każda modyfikacja WeiDu posiada trzy rodzaje plików skryptowych (do pewnego stopnia przekłada się to na rodzaje plików *.tra, o ile modyfikacja została straifikowana) – plik techniczny oraz pliki skryptowe i dialogowe.

Plik techniczny (*.tp2)

Plik techniczny *.tp2 znajdujący się razem z instalatorem WeiDu na poziomie nadrzędnego katalogu modyfikacji (po wypakowaniu do gry – bezpośrednio w katalogu głównym gry) albo w nadrzędnym katalogu modyfikacji (nowsze modyfikacje). Domyślnie zawiera wszelkie technikalia – dodawane albo zmieniane przedmioty, zaklęcia, istoty (także bohaterów przyłączalnych z ich zestawami dźwiękowymi), zasady itp.

Jeśli modyfikacja została poddana procesowi traifikacji, wyniki z tego pliku zapisywane są prawie zawsze pod nazwą setup.tra (szerzej o tym powyżej).

Pliki skryptowe (*.baf )

Pliki skryptowe *.baf – są to pliki, które definiują działanie urządzeń, zachowanie istot w cutscenkach, sposób walki postaci itp., dodatkowo, jak już stwierdziliśmy wcześniej, zawierają czasem teksty wyświetlane w grze.

Jeśli modyfikacja została straifikowana, dodawane są na ogół do pliku setup.tra.

Pliki dialogowe (*.d)

Pliki dialogowe *.d zawierają oskryptowane teksty aktywnych rozmów, niektórych zadań (np. głos ogłaszający zasady gry na szachownicy w Wieży Durlaga) itp.

Jeśli nie dokonano traifikacji – tutaj będą znajdować się niemal wszystkie teksty dodawane przez modyfikację.

Pochodzące z przekształcenia plików *.d pliki *.tra na ogół różnią się tylko rozszerzeniem.

Czytanie plików dialogowych *.d

Nie zawsze tekst wypowiedzi w pliku tekstowym *.tra pozwala określić, kto wypowiada daną kwestię (o znaczeniu tego w II części naszego poradnika, dot. kwestii związanych z gramatyką języka polskiego). W takim przypadku rozwiązaniem jest zajrzenie do odpowiadającemu temu plikowi pliku skryptowego *.d.

Pliki takie buduje się według ściśle określonych zasad – składają się one z bloków wprowadzających tekst ewentualnie akcję. W uproszczeniu przyjmuje się, że każdy blok zaczyna się komendą BEGIN (a raczej tym, co daną komendę BEGIN poprzedza, na ogół warunek IF (…) THEN), a kończy komendą END.

1) Standardowy blok:

Krótsza wersja:

2) Blok łańcuchowy:

Krótsza wersja:

Wymieniliśmy oczywiście tylko najbardziej typowe konstrukcje (więcej na ten temat w punktach 2-4 znakomitego tutorialu L'fa Tworzenie skryptu dialogowego).

Budowa modyfikacji

Wprowadzenie

Zagadnienie to jest rozbudowane, dość powiedzieć, że – mimo iż można wyróżnić pewne prawidła – tyle jest różnych modeli, ile modów, a liczba tych w przypadku Sagi BG dawno już przekroczyła 1000. My skupimy się na zagadnieniach pozwalających ułatwić bądź usprawnić ewentualny proces tłumaczenia.

Budowa modyfikacji WeiDu

Po wypakowaniu modyfikacji uwidacznia się, że zbudowane są one według następującego schematu:

1) – plik instalatora WeiDu, o nazwie: setup-nazwa_modu.exe,

– plik skryptowy o nazwie: setup-nazwa_modu.tp2 lub po prostu: nazwa_modu.tp2,

– katalog główny o nazwie: nazwa_modu (choć nie jest to konieczne) – zawiera niemal wszystkie pliki modyfikacji, prócz instalatora WeiDu oraz pliku *.tp2, ew. pliku *.command.

2) istnieje jeszcze schemat zmodyfikowany, nowszy – jak wyżej, z tym że plik skryptowy znajduje się w katalogu głównym, który w tym przypadku musi mieć nazwę identyczną z tą w instalatorze.

Konstrukcja plików *.d modyfikacji typu NPC

Każdy bohater przyłączalny (BP) ma (a przynajmniej mieć powinien) pewne określone pliki dialogowe, stanowiące jego "szkielet" – rozmowy i pozostałe wypowiedzi. Konstytuowane są one dwoma plikami *.2da (z których każdy określa z kolei odpowiednie pliki *.d) – nazewnictwo teoretyczne podeprzemy praktyką, nazwami plików z modyfikacji Yasraena (liczba 25 w nazwach połowy plików oznacza, iż ten przeznaczony jest do Tronu Bhaala):

1) pdialog.2da – dialogi przyłączenia, odejścia, reakcji itp.:

a) Plik dialogu przyłączenia (join dialog file; YASRAENJ.d i YASRA25J.d) – nazwa myląca, bowiem znajdują się tu prócz wspomnianego dialogu wszelkie wtrącenia, dialogi związane z zadaniami i zdarzeniami, rozmowy inicjowane przez gracza (należy pamiętać, że w oryginalnym BG II takowe nie występują) i innych BP, a nawet fragmenty flirtów i romansów (te inicjowane przez wspomniane postaci), choć dużo też zależy od danego twórcy, często bowiem niektóre z tych rozmów trafiają do innych plików.

b) Plik dialogu odłączenia (post dialog file; YASRAENP.d i YASRA25P.d) – co tu więcej wyjaśniać?

c) Plik skryptu snu (dream script file; YASRAEND.d i YASRA25D.d) – plik tekstów postaci towarzyszących snom protagonisty (rzadko dodawane, dość powiedzieć, że żaden oryginalny BN z BG II takowego nie posiada).

d) Plik skryptu katalogu override (25 override script file; YASRAE25.d) – dla Tronu Bhaala.

2) interdia.2da – tylko jeden rodzaj pliku:

a) Plik rozmów wewnątrz drużynowych (inter-party dialog file; BYASRAEN.d i BYASRA25.d) – "ballady i romanse", czyli pogawędki z protagonistą i resztą drużyny, romans(e) itp., choć dużo zależy od danego twórcy, często bowiem niektóre z tych rozmów trafiają do plików dialogu przyłączenia (granice między oboma są dość płynne).

Dodatkowo modyfikacje często posiadają plik dialogu inicjalnego (w przypadku Yasraeny: YASRAENA.d).

Rodzaje wypowiedzi

Jak widać, można się w powyższej klasyfikacji pogubić, dlatego pozwolimy sobie wyszczególnić rodzaje wypowiedzi bohaterów przyłączalnych (BP) – ogólnie rzecz ujmując, możemy wydzielić trzy kategorie:

1) Rozmowy (w tym tzw. bantery – wszelkiego rodzaju pogawędki z protagonist(k)ą i innymi BN-ami, wliczamy w to także ewentualny romans).

2) Wtrącenia – wszelkiego rodzaju reakcje na sytuację (czyli np. komentarze w kluczowych momentach gry).

3) Dialogi inicjowane przez gracza (czyli tzw. PID-y) – choć w oryginalnym BG II nie występują, wielu modotwórców dokłada je swoim bohaterom.

Edytory

Informacje ogólne

Są to ujmując rzecz w największym skrócie programy ułatwiające obsługę (czyli przeglądanie, zmienianie i tworzenie plików używanych w grze). Jest ich dość znaczna ilość (listę najbardziej przydatnych znajdziesz tutaj, tutaj z kolei znajduje się krótka charakterystyka najważniejszych.), choć w większości są przydatne wyłącznie modotwórcom. Dla tłumaczących najbardziej przydatne są Near Infinity (NI) oraz Infinity Explorer (InfExpl), ewentualnie jeszcze DLTCEP – ten ostatni stanowi jednak zaawansowany edytor, przeznaczony przede wszystkim dla modujących (tutaj znajdziesz opis funkcji), pozwolimy sobie więc pominąć jego charakterystykę. Nazwa Infinity pochodzi od nazwy silnika gier, na którym osadzono Sagi Baldur's Gate i Icewind Dale oraz Planescape: Torment.

1) NI – prawdziwy "kombajn", ciągle rozwijany, w większości funkcji bije na głowę inne. Najlepsza (choć niestety nie doskonała) wyszukiwarka stringów, wbudowany odtwarzacz plików *.wav, lepsza (choć domyślnie działająca jedynie w 64-bitowej wersji) mapa świata, masowy eksport i wiele innych przydatnych narzędzi sprawia, iż powoli staje się najpopularniejszym edytorem.

2) InfExpl – najlepszy program do przeglądania i czytania lokacji. Ma również znacznie bardziej czytelny interfejs. Występuje w dwu wersjach:

a) 0.75 (oraz wcześniejsze) – obsługuje wyłącznie zasoby gier Infinity bez modów,

b) 0.85 – obsługuje także zdecydowaną większość modów.

Mankamentem obu jest stosowanie w menu wyłącznie nazw kodowych plików. Pod tym względem optymalnym jest DLTCEP, gdzie obok kodu podawana jest pełna nazwa.

Używanie edytorów

Edytory dla tłumacza mogą być pomocne przede wszystkim w czytaniu drzewa dialogowego, by nie musieć się przebijać przez gąszcz plików *.d, odsyłaczy wewnętrznych i zewnętrznych, komend itp.

1) InfExpl – program nie wymaga instalacji, wypakowujemy i uruchamiamy, jak każdą inną aplikację.

Podczas uruchamiania edytor prosi nas o wybranie gry, możemy albo wybrać którąś z listy (ścieżki dostępu są zapisywane w rejestrze), albo kliknąć znajdujący się po prawej strony wiersza ścieżki schematyczny ideogram folderu (otworzy się eksplorator, w którym wyszukamy plik Chitin.key interesującej nas gry – znajduje się w katalogu głównym danej gry), niezależnie od opcji program sam ją uruchomi (bez konieczności restartu).

Po wyborze gry po lewej stronie pojawia się menu, wybieramy Dialogs. Po kliknięciu na + pozycja się rozwija, ukazując naszym oczom wszystkie pliki *.dlg (czyli *.tra + *.d – pierwotny zestaw).

Po kliknięciu na wybrany, pojawi się on w formie drzewa dialogowego w oknie po prawej stronie. Rozwijamy dany dialog przez kliknięcie na +. Po kliknięciu na tekst danej linii dialogowej, pojawi się on poniżej okna, razem z ewentualnymi warunkami, wpisami do dziennika, odpalanymi scenkami itd. Pojawia się także nr stringu w grze oraz jego umiejscowienie w pliku (nr kwestii i weight – waga, czyli pozycja dialogu pośród rozmów).

Jeśli będziemy chcieli zmienić grę w trakcie korzystania, należy kliknąć znajdujący się poniżej menu ideogram folderu. Uwaga! Po zmianie gry w folderze modyfikacji tworzony jest plik kopii dialog.tlk, o nazwie dialogcpy.tlk. Samej grze nie szkodzi, jednak powoduje m.in. niemożność otwarcia w ciągu jednej sesji po raz drugi tej samej gry.

2) NI – ten program również nie wymaga instalacji, do działania wymaga natomiast zainstalowanej Javy.

Przy uruchomieniu po raz pierwszy wyskoczy okno eksploratora w celu wskazania ścieżki, przy następnych będzie operować na ostatnio wybranej grze. By ją zmienić, klikamy Game w pasku menu, wybieramy opcję Open Game... i znajdujemy plik Chitin.key interesującej nas gry.

Po lewej stronie pojawi się menu, wybieramy DLG. Po kliknięciu nań pozycja się rozwija, ukazując naszym oczom wszystkie pliki *.dlg (czyli *.tlk + *.d – pierwotny zestaw).

Po kliknięciu na wybrany, po prawej stronie pojawi się kilka okien, a nad nimi trzy zakładki, zmieniamy z aktualnej (View) na Tree – ukażą się nam wszystkie dialogi inicjowane przez dany plik. Rozwijamy dany dialog przez kliknięcie na strzałkę. Po kliknięciu na tekst danej linii dialogowej, pojawi się on poniżej okna, razem z ewentualnymi warunkami, wpisami do dziennika, odpalanymi scenkami itd. Pojawia się także nr stringu w grze oraz jego umiejscowienie w pliku (nr kwestii i weight – waga, czyli pozycja dialogu pośród rozmów).

Zdarza się nieraz, że znaleźliśmy plik, przeglądamy drzewo, a poszukiwanej kwestii nie ma. Jeśli rzecz dotyczy pliku dialogowego jakiejś postaci i faktycznie odnaleźliśmy go w edytorze, oznacza to, że dana wypowiedź stanowi kontynuację (odpowiedź) rozmowy zapoczątkowanej przez inną postać. Niestety InfExpl w tej kwestii całkowicie zawodzi, najlepszym w tym aspekcie jest DLTCEP, który pokazuje wszystkie teksty danej postaci ("właściciela" pliku) z odsyłaczami do wcześniejszych kwestii interlokutorów. W "środku stawki" plasuje się NI, w którym nie znajdziemy tego tekstu w drzewie dialogowym (zakładka: Tree), aczkolwiek samo znalezienie tekstu jest możliwe w menu edycji (zakładka: Edit) – choć do idealnych to nie należy, wszystkie elementy (tekst, warunki, akcja, odsyłacz itd.) występują bowiem osobno, w dodatku numeracja jest ciągła, a nie przypisana do danej kwestii. Najlepszym rozwiązaniem jest wyszukanie danej kwestii w części Response (zaczynają się po State), gdzie znajduje się najwięcej danych. Niestety w NI nie ma możliwości sprawdzenia poprzedniego bloku.

Obsługa gotowego tłumaczenia

Zakończenie prac

Nim podejmiesz kroki w celu ogłoszenia światu o dokonanej właśnie pracy, dobrze jest jeszcze raz przeczytać całość tłumaczenia oraz sprawdzić je programem sprawdzającym poprawność ortograficzną (wszelkie programy typu Office z zainstalowanym modułem sprawdzania pisowni języka polskiego bądź programy online typu LanguageTool).

Pamiętaj również, że nigdy nie zmienia się nazw plików! Uniemożliwiłoby to prawidłowe działanie.

Dalsze losy

Kiedy już masz ten etap za sobą, możesz zdecydować co dalej – jest parę opcji:

1) Wysłanie bezpośrednio do autora/autorki – opcja najłatwiejsza, choć pozostawiające tłumaczenie poza Twoją gestią (każda zmiana czy poprawka wymaga pisania do autora/autorki, a większość z nich, w przypadku dodania nowej zawartości, zamiast kontaktować się z tłumaczem wcześniejszej wersji, ogłasza konieczność dotłumaczenia nowej treści na którymś z międzynarodowych forów). "Skazuje" też przyszłego grającego w dokonane przez Ciebie tłumaczenie, na przyjęcie go ze wszystkimi tego zaletami i wadami, w tym również z wszelkimi błędami (errare humanum est). Mail podawany jest w instalce WeiDu lub pliku Readme. Niestety zawsze istnieje szansa, że twórca przestał już zajmować się modowaniem, w takim przypadku tłumaczenie może nie ujrzeć światła dziennego.

2) Wstawienie na Forum Klanu CoB, w tym dziale. Prócz możliwości pochwały, oceny i sugestii dotyczących ewentualnych błędów czy niedociągnięć masz także możliwość załączania na bieżąco poprawionej wersji oraz obrony swojego dzieła. Dodatkowo w przyszłości planujemy uczynić wszystkie tłumaczenia w pełni zgodnymi z nomenklaturą Sagi BG (czyli nadać im jakość tłumaczeń SoM – najwyższej, jeśli chodzi o tłumaczenia modów do BG), więc i Twoje tłumaczenie któregoś dnia trafi na nasz warsztat, by stać się (o ile to możliwe) jeszcze lepszym – ku chwale Twojej, naszej i całego BG!

3) Wstawienie na innych forach – choć z uwagi na fakt, iż są anglojęzyczne, mija się to trochę z celem.

Pakowanie

W zależności od decyzji w stosunku do dalszych losów tłumaczenia, różnić się będzie finalny wygląd paczki z tłumaczeniem. Standardowo w grę wchodzi parę opcji:

1) Wysłanie do autora/autorki. Należy spakować przetłumaczone pliki i po prostu wysłać do autora/autorki modyfikacji z informacją, kto i na jaki język dokonał tłumaczenia. Zdecydowana większość modotwórców posługuje się językiem angielskim w przynajmniej komunikatywnym stopniu, więc wskazane jest (o ile nie zna się ich narodowości i ich wernakularnego języka) kontaktowanie się w tym języku.

2) Podmiana plików. Pliki pozostawiamy w folderze, w jakim wyekstrahowane zostały z instalki modyfikacji i po skończeniu pracy w nim pakujemy. Na ogół jest to folder english, względnie american. W informacji na temat instalacji dobrze jest wówczas podać, co i gdzie podmieniamy.

3) Dodanie ścieżki w pliku *.tp2 – jest to opcja dla bardziej zaawansowanych tłumaczy, sposób przyjęty dla modyfikacji tłumaczonych przez SoM. Wspomniany plik otwieramy, wyszukujemy słowo LANGUAGE. Powinniśmy znaleźć coś w tym kształcie:

Duplikujemy ścieżkę i zmieniamy te skopiowaną zastępując istniejącą ścieżką języka polskiego:

Na koniec gotowe tłumaczenie umieszczamy w katalogu Polish, które umieszczamy w katalogu Language, a ten z kolei w SOS. Na tym poziomie załączamy zmodyfikowany plik *.tp2 i pakujemy.

4) Stworzenie pełnej instalki – sposób odradzany, choć niegdyś (głównie przez Wieżę Ramazitha) praktykowany. Wprowadza zamęt co do wersji, choć oczywiście stanowi ukłon w stronę Gracza, który w jednym miejscu ma nie tylko wszystkie tłumaczenia PL, ale i gotowe instalki.

Możliwe jest oczywiście konsultowanie tego z Awatarem Mystry (via PW na Forum), który doradzi i rozwieje ewentualne wątpliwości.

---

Pozostałe części poradnika:
II - kwestie językowe | III - tokeny