W Polish Route jak w garncu… Czasami ciśnienie rośnie i jest niestabilnie, a czasami się grzecznie dusimy na małym ogniu.
Zewsząd jesteśmy ostrzeliwani jednym pytaniem. Niewinne, proste pytanie, które niesie ze sobą moc sprawczą, moc twórczą, ale również niszczycielską. Pytanie, które ciągle pada z ust zainteresowanych losem polskiego przekładu Katawy Shoujo: kiedy wydacie to tłumaczenie?!
Tłumaczenie oficjalnie ruszyło 9 marca 2013. Rozdzieliliśmy wtedy skrypt aktu I według dni tygodnia tak, że jeden dzień przypadał na jednego tłumacza – oczywiście z czasem pojawiły się nowe twarze, więc na niektóre dni tygodnia było kilkoro tłumaczy.
Z początku do zarządzania tłumaczeniem korzystaliśmy z Dropboxa. Wydawało się to bardzo dobrym rozwiązaniem (okaże się, że jednak nie). Każdy tłumacz miał wtedy swój własny folder i nie miał dostępu do folderów reszty.
Rys. 1. Folder Dropboxowy reddockasw.
Dostęp do wszystkich folderów miały dwie osoby – Sedinus, jako szef nad szefami, oraz Funcik, który tym wszystkim zarządzał.
Rys. 2. Drobna sugestia od Funcika – protoplasta korekty.
Samo tłumaczenie szło całkiem sprawnie. Swój wtorek oddałem „gotowy” już po sześciu dniach, pozostali tłumacze oddawali w podobnym terminie.
Poradziwszy sobie z tłumaczeniem, musieliśmy zająć się korektą. Bo – musicie wiedzieć – przetłumaczyć da się wszystko, kwestią tylko pozostaje, jak to zostało przełożone.
Na Dropboxie wyglądało to tak, że każdy robił sobie, co chciał, tzn. tworzył plik z uwagami, wrzucał go utworzonego specjalnie w tym celu folderu Korekta i… czekał. Czekał, aż osoba, która tłumaczyła plik, cokolwiek odpowie na te uwagi, bo w gruncie rzeczy nie musiała.
Rys.3. Korekta poniedziałku Sedinusa. Warto zwrócić uwagę na niekompletny raport Xerbera – już na zawsze pozostanie taki…
Forma korekty była naprawdę luźna i nie do końca sprecyzowana. Mogły to być na przykład screenshoty z gry:
Rys. 4. Zabawny błąd wychwycony prawdopodobnie przez Xerbera.
Albo też plik tekstowy. Początkowo były to wielkie pliki zbiorcze dla danego dnia w skrypcie, do których każdy mógł się dopisywać:
Rys. 5. Korekta czwartku Funcika.
Chyba każdy może z łatwością dostrzec, jakie wady niesie taki system – przede wszystkim bałagan, a po drugie sam fakt nadpisywania sobie pliku oraz łatwość przeoczenia nowo wprowadzonej uwagi.
Z tego powodu przedsięwzięliśmy, że każdy dzień tygodnia dostanie osobny folder, a uwagi każdej z osób lądują w oddzielnym pliku. Oczywiście sama zawartość pliku nie była ściśle określona. Poniższe screenshoty pokazują również, że jakakolwiek zmiana w nieswoim pliku była kompletnie zakazana – w uwagach należało zamieszczać przecinki czy literówki. W późniejszym czasie takie rzeczy zaczęły być poprawiane na miejscu.
Rys. 6. Moja korekta środy.
Rys. 7. Funcikowa korekta środy.
Rys. 8. Korekta poniedziałku Galla Anonima.
Ostatni przykład pokazuje również, że zdarzało się, że ktoś sobie skorektował plik i się nie podpisał – z kim wtedy konsultować taką korektę?
Stan taki utrzymywał się dosyć długo, bo do wakacji 2013. Wtedy to na testera zgłosił się Mader Levap. Początkowo miał być tylko testerem – odpalał grę dwa razy i porównywał angielskie tłumaczenie z polskim. Problem był taki, że gdy zaczynało się grę od z góry wybranej sceny, to wybór był dokonywany automatycznie, przez co często w polskiej wersji dokonywany był inny wybór niż w angielskiej wersji. Mader poprosił więc o skrypt nieskompilowany, żeby mógł przeglądać sobie w edytorze tekstowym. A gdy dowiedział się, że korzystamy z Dropboxa, załamał ręce…
Mader wprowadził SVN. Za jego słowami jest to system kontroli wersji, który ułatwia pracę nad plikami w projekcie i zapewnia, że wszyscy będą mieć tę samą wersję plików w projekcie. Zbiór plików i katalogów kontrolowanych przez SVN nazywa się repozytorium.
Przewaga SVN nad Dropboxem jest taka, że w danej chwili wszyscy mają tę samą wersję plików, ale starsze wersje cały czas istnieją. Widać też wszystkie wprowadzane zmiany oraz kto ich dokonał.
Rys. 9. Logi SVN.
Pod wodzą Madera sposób korekty zaczął się zmieniać. Przede wszystkim jej sposób stawał się usystematyzowany: do korekty pliku zostawały przydzielane osoby i tylko one miały prawo je korektować. W początkowym etapie korekta przebiegała w czasie rzeczywistym podczas tzw. sesji.
Sesja polegała na tym, że na kanale IRC obecny był tłumacz pliku, korektor, a także osoby postronne, które były bardzo pomocne w kwestiach spornych.
[21:42] <@Mader_Levap> „That was a very melodramatic setup, though, just to tell me that.”
[21:42] <@Mader_Levap> „Był to bardzo dramatyczny sposób na powiedzenie mi o tym.”
[21:42] <@Mader_Levap> „tylko po to, by mi o tym powiedzieć” czy coś takiego
[21:42] <@Mader_Levap> oczywiscie wczesniej porpawić… bo z zmianą nie pasuje
[21:42] <@Mader_Levap> hmmm
[21:42] <@Funcik|Gintama> ze zmianą Mader
[21:43] <@Mader_Levap> hmmmm
[21:43] <@Mader_Levap> no nie no trzeba przerobić całe zdanie
[21:43] <@Mader_Levap> moment
[21:44] <@Mader_Levap> dosłownie byłoby to coś w stylu „Zrobiły to w bardzo dramatyczny sposób, tylko po to, by mi o tym powiedzieć.” – da się ładniej?
[21:45] <@mnb> Tym niemniej wyjątkowo dramatyczny wstęp, tylko po to, by mi o tym powiedzieć.
[21:45] <@mnb> tak naprawdę to głównie leżałem w łóżku
[21:46] <@mnb> głowa mnie boli ;_;
[21:46] <@Mader_Levap> eee…
[21:46] <@Mader_Levap> czyli nie za bardzo nadajesz się do rpacy
[21:46] <@Mader_Levap> usprawiedliwiony
[21:46] <+reddocksw> och jak mnie głowa boli
[21:46] <@Mader_Levap> zatem co z tym zdaniem?
[21:46] <+reddocksw> chyba spać pójdę…
[21:46] <!Sedinus> apap i do roboty pedale
Cytat 1. Typowa sesja korektorska na kanale IRC.
Takie rozwiązanie – nie ma co ukrywać – również nie było najlepsze. Ba, było całkiem beznadziejne. Sesje korektorskie trwały godzinami, szybko męczyły uczestników, a podczas nich często dochodziło do sporów i ostrej wymiany zdań. Zwłaszcza sesje z Sedinusem jako korektorem były owiane istną grozą – potrafił zajść za skórę praktycznie wszystkim.
Z czasem przyszło usprawnienie – korektor przygotowywał zawczasu plik z uwagami, z którymi zapoznawał się tłumacz. Jeżeli z czymś się nie zgadzał, to dyskutował o tym później z korektorem podczas standardowej sesji:
Rys. 10. Usprawnienie sesji – uwagi były przygotowywane wcześniej i rozpatrywane przez tłumacza, co nie wymagało już jednoczesnej obecności obydwóch. Ewentualne „odrzuty”, czyli nieprzyjęte uwagi, były rozpatrywane podczas sesji.
I w taki sposób doczłapaliśmy się do końca korekty aktu I. Do tego czasu serwer SVN był trzymany u Madera w domu. Włączał go po powrocie z pracy, czyli w tygodniu po 17. Często było wyczekiwanie, aż wróci, żeby móc scommitować korektę.
Wydanie aktu I przyniosło nam nową stronę oraz całodobowy serwer SVN. Resztę skryptu, czyli akty II, III oraz IV, dzieliliśmy już według dziewczyn na tych tłumaczy, którzy się ostali. Nowością tutaj jest z pewnością organizer, w którym szczegółowo jest opisany cały stan tłumaczenia.
Rys. 11. Fragment Emi z organizera.
Gdy omawiamy tłumaczenie, ktoś może sobie pomyśleć: a nie mieliście nigdy takiego problemu, że za Chiny nie wiedzieliście, jak coś przetłumaczyć? Co wtedy robiliście? Pytanie takie wydaje się całkiem zasadne! Na forum Katawy Shoujo istnieje devowy dział dotyczący tłumaczenia, a w nim jest „Didn’t get this line” topic (Temat „nie załapałem tej linii”).
Rys. 12. Fragment tematu z forum Katawy.
Warto się tutaj zatrzymać, bowiem często dochodzą nas pytania typu skoro ostatnio była Hanako, a to już ostatnia z dziewczyn, to znaczy, że już wszystko przetłumaczyliście? Cały skrypt przetłumaczyliśmy już jakoś na początku 2017. Co zatem – możecie zapytać – stoi na przeszkodzie, aby wypuścić tłumaczenie?
Odpowiedź to: korekta. Można uznać, że korekta u nas źle zorganizowana albo że jest wręcz patologiczna. Ktoś inny powie, że jest bardzo dobrze przemyślana. I wszyscy będą mieli trochę racji.
Rys. 13. Obecny wygląd korekty.
Korekta pozostała w identycznej postaci jak w akcie I, ale przecież objętość tekstu wzrosła kilkukrotnie. Można również zauważyć na screenshocie z organizera, że wymienione są aż (!) cztery korekty. Tak właściwie to są trzy – czwarta jest potencjalna. Warto to omówić.
Gdy tłumacz skończył przekładać plik, musiał dokonać jego draftu, czyli odłożyć plik na jakiś czas i potem do niego zajrzeć. Potem oddawał go do korekty wewnętrznej – zazwyczaj robił to inny tłumacz z tej samej ścieżki, a jeżeli takowego nie było, to robił to jakiś inny tłumacz. Korekta ta była powierzchowna i miała na celu wyłapanie największych baboli.
Następnie plik przechodził do korekty właściwej. Na każdy plik czyhają trzy takie korekty i każdą korektę wykonuje inny korektor. Jest ona szczegółowa – polega na bezpośrednim porównywaniu tłumaczenia z oryginałem.
Rys. 14. Narzędzie diff z programu TortoiseSVN, które wykorzystujemy przy korekcie.
Słowo-klucz stanowi tutaj szczegółowa. Naprawdę korektorzy czepiają się najmniejszych szczegółów, które dla potencjalnego odbiory nie mają najmniejszego znaczenia podczas czytania tekstu:
Rys. 15. Kłótnia o tłumaczenie „flan”.
Czasami na taki szczególik jak powyżej potrafi zejść nawet (!) godzina. I to nazwałbym główną patologią naszego systemu korekty.
Dochodzi oczywiście jeszcze kwestia finalizacji, czyli uzgodnienia rzeczy wspólnych dla wszystkich ścieżek, jak np. treść niektórych listów czy też nazw kół. Dodajcie jeszcze do tego fakt, że nie zawsze ma się czas na korektę albo że trudno o zgranie czasowe korektora i tłumacza – no i macie jak na tacy przyczynę, czemu jeszcze nie ma tłumaczenia.
W komentarzach zawsze odpowiadałem całkiem wymijająco na pytanie dotyczące daty wydania. Ostatnio nawet rzuciłem jakimś terminem, że na jesień (za co koledzy z grupy chcieli smażyć mnie na grillu!). Czy jest on realny? Muszę przyznać, że tak średnio, ale realny za to wydaje się termin końca roku lub na samym początku następnego.
Jeżeli dotrwaliście tutaj, to mam nadzieję, że przybliżyłem Wam powody, dlaczego to się tak wszystko ciągnie. Nie mamy nic na usprawiedliwienie poza tym, że, no cóż, tak wyszło. Dzięki za uwagę i dzięki, że z nami przez ten cały czas jesteście!
