Chyba przedostatnia wersja Androidowego ROMu Laszlo opublikowana na forum XDA miała dość ciekawy błąd mianowicie nie widziała aplikacji zainstalowanych na partycji Ext.

Dorabiając z Fireratem natywną obsługę SdExt prawie w ogóle nie zwracaliśmy uwagi na to czy stosowna partycja karty w ogóle istnieje (o podmontowaniu jej we właściwym miejscu nawet nie wspomnę). Ubocznym efektem (i, do pewnego stopnia, powodem moich programistycznych wypocin) był fakt, że telefon potrafił wpadać w bootloop (czyli w kółko się restartował).

Pierwszym krokiem było zmodyfikowanie Volda (VOLume Daemon – usługa systemowa zarządzająca ‘dyskami’), tak by montował odpowiednią partycję pod /sd-ext i sprzedał informację o sukcesie (lub porażce) reszcie systemu. Jak już umiał przekazać informację to trzeba było sprawić by framework wiedział co z tą informacją zrobić i tak powstała funkcja o nazwie getSdExtState(). Tak prosta, że nie sposób popełnić w niej błędu. Od razu też wykorzystałem ją do sprawdzania dostępności /sd-ext przed próbą skanowania zainstalowanych tam aplikacji przy starcie systemu. Kawałek kodu tak trywialny, że nawet nie przyszło mi do głowy jakieś większe testowanie.

if (Environment.getSdExtState().equals(Environment.MEDIA_MOUNTED)) {
   scanDirLI(mSdExtInstallDir, PackageParser.PARSE_ON_SDEXT, scanMode);
}

Jak podmontowane to skanuj, jak nie – to nie. Prawda, że proste? W samym frameworku jest parę newralgicznych miejsc (związanych z instalacją aplikacji) w których użyłem identycznego testu. Świat stał się lepszym miejscem a ja mogłem się zająć dorabianiem informacji o SdExt w Ustawieniach czy czymś takim. Mniej więcej w tym momencie Laszlo zapewne zsynchronizował swoje źródła z moimi i wypuścił na świat kolejną wersję swojego ROMu. Chyba w sobotę Firerat dał mi znać na Twitterze, że ludzie mają kłopoty z Apps2SdExt na najnowszym FbL. Zerknąłem na forum i, na podstawie zamieszczonych tam postów, doszedłem do wniosku, że dochodzi do tzw race condition. Vold działa asynchronicznie względem reszty systemu i w czasie gdy jeszcze zajmuje się sprawdzaniem systemów plikowych uruchamiane są pozostałe komponenty systemu takie jak usługa PackageManagera. To ona właśnie przeprowadza początkowy skan katalogów z aplikacjami. Skoro nie widać aplikacji zainstalowanych na SdExt to (patrząc na powyższy kawałek kodu) getSdExtState zwraca coś innego niż MEDIA_MOUNTED i system nawet nie próbuje zajrzeć do /sd-ext/app. Wniosek z tego jest taki, że Vold jeszcze nie zdążył pozałatwiać swoich spraw z /sd-ext. Problem znany zatem teraz wystarczy znaleźć rozwiązanie. Na szybko Firerat przekompilował framework.jar z wywalonym sprawdzaniem getSdExtState(), wrzucił na XDA i ‘rozwiązał’ problem (to był akurat weekend i, zdaje się, byłem po jakimś większym maratonie Singstara w towarzystwie sąsiadów i paru butelek Dark Whisky ).

To, co zrobił Firerat było jednak tylko obejściem problemu a nie jego rozwiązaniem. Poczytałem jeszcze raz posty na forum, popsioczyłem, że nikt z pomstujących nie zdobył się na złapanie logów ze startu systemu i doszedłem do identycznego wniosku jak wcześniej: Race condition. Na swoim telefonie nie miałem problemu z brakiem aplikacji z SdExt ale też miałem wtedy zainstalowaną wersję bardzo rozwojową (czyt: powiązaną sznureczkiem i podpartą patyczkiem z każdej strony). Złapałem logi z restartu swojego telefonu i patrzyłem w nie jak sroka w gnat. No nijak nie było szans na race condition. Zgodnie z tym co widziałem w logach /sd-ext było już dawno podmontowane. Przecież nie da się zrobić błędu w 6 linijkach kodu z jakich składa się getSdExt():

    /**
     * Gets the current state of SD-Ext
     * Note: this call should be deprecated as it doesn't support
     * multiple volumes.
     */
   public static String getSdExtState() {
       try {
           if (mMntSvc == null) {
               mMntSvc = IMountService.Stub.asInterface(ServiceManager.getService("mount"));
           }
           return mMntSvc.getVolumeState(getSdExtDirectory().toString());
       } catch (Exception rex) {
           return Environment.MEDIA_REMOVED;
       }
   }

Poza tym w innych miejscach kodu funkcja ta działa perfekcyjnie. Tak się zafiksowałem na tym race condition, że dobre dwa dni nad tym spędziłem. Albo raczej zmarnowałem. Zmarnowałem bo z całego logu (około 150+ KB tekstu) skoncentrowałem się wyłącznie na części związanej ze PackageManagerem i skanowaniem /sd-ext/app. W końcu mój umysł zaczął rejestrować inne linijki logu i wyłapał coś takiego:

I/sysproc (  147): System server: starting Android runtime.
I/sysproc (  147): System server: starting Android services.
I/SystemServer(  147): Entered the Android system server!
I/sysproc (  147): System server: entering thread pool.
I/SystemServer(  147): Entropy Service
I/SystemServer(  147): Power Manager
I/SystemServer(  147): Activity Manager
I/ActivityManager(  147): Memory class: 16
D/dalvikvm(  147): GC_FOR_MALLOC freed 641 objects / 80848 bytes in 138ms
D/dalvikvm(  147): GC_FOR_MALLOC freed 2131 objects / 317920 bytes in 159ms
I/SystemServer(  147): Telephony Registry
I/SystemServer(  147): Package Manager
D/dalvikvm(  147): GC_FOR_MALLOC freed 5971 objects / 222640 bytes in 181ms
I/dalvikvm(  147): DexOpt: source file mod time mismatch (3e4c9ef4 vs 3e618cf4)
D/installd(  101): DexInv: --- BEGIN '/system/framework/android.test.runner.jar' ---
D/dalvikvm(  163): DexOpt: load 111ms, verify 722ms, opt 13ms

Kilkanaście linijek niżej pojawia się:

I/PackageManager(  147): Pruning dalvik file: sd-ext@app@com.twitter.android-2.apk@classes.dex
I/PackageManager(  147): Pruning dalvik file: sd-ext@app@com.keramidas.TitaniumBackup-1.apk@classes.dex
D/PackageManager(  147): Scanning app dir /system/framework
D/PackageManager(  147): Scanning app dir /system/app
D/dalvikvm(  147): GC_FOR_MALLOC freed 4987 objects / 280408 bytes in 193ms
W/PackageParser(  147): No actions in intent filter at /system/app/Bluetooth.apk Binary XML file line #124
I/PackageManager(  147): /system/app/CMParts.apk changed; collecting certs

I jeszcze kilkadziesiąt linijek niżej:

D/dalvikvm(  147): GC_EXPLICIT freed 7597 objects / 563168 bytes in 221ms
I/SystemServer(  147): Account Manager
I/SystemServer(  147): Content Manager
I/SystemServer(  147): System Content Providers
I/SystemServer(  147): Battery Service
I/SystemServer(  147): Lights Service
I/SystemServer(  147): Vibrator Service
I/SystemServer(  147): Alarm Manager
D/AlarmManagerService(  147): Kernel timezone updated to -60 minutes west of GMT
I/SystemServer(  147): Init Watchdog
I/SystemServer(  147): Sensor Service
I/SystemServer(  147): Window Manager
I/SystemServer(  147): Bluetooth Service
I/SystemServer(  147): Device Policy
I/bluedroid(  147): Starting hciattach daemon
I/SystemServer(  147): Status Bar
I/SystemServer(  147): Clipboard Service
I/SystemServer(  147): Input Method Service
I/SystemServer(  147): NetStat Service
I/SystemServer(  147): NetworkManagement Service
I/SystemServer(  147): Connectivity Service
V/ConnectivityService(  147): ConnectivityService starting up
D/ConnectivityService(  147): getMobileDataEnabled returning true
V/ConnectivityService(  147): Starting Wifi Service.
I/WifiService(  147): WifiService starting up with Wi-Fi disabled
D/Tethering(  147): Tethering starting
D/NetworkManagmentService(  147): Registering observer
I/bluedroid(  147): Starting bluetoothd deamon
I/SystemServer(  147): Throttle Service
I/SystemServer(  147): Accessibility Manager
I/SystemServer(  147): Mount Service
I/SystemServer(  147): Notification Manager

Widać?
Nie widać?? Hmmm… A teraz?

I/SystemServer(  147): Entropy Service
I/SystemServer(  147): Power Manager
I/SystemServer(  147): Activity Manager
I/SystemServer(  147): Telephony Registry
I/SystemServer(  147): Package Manager
I/SystemServer(  147): Account Manager
I/SystemServer(  147): Content Manager
I/SystemServer(  147): System Content Providers
I/SystemServer(  147): Battery Service
I/SystemServer(  147): Lights Service
I/SystemServer(  147): Vibrator Service
I/SystemServer(  147): Alarm Manager
I/SystemServer(  147): Init Watchdog
I/SystemServer(  147): Sensor Service
I/SystemServer(  147): Window Manager
I/SystemServer(  147): Bluetooth Service
I/SystemServer(  147): Device Policy
I/SystemServer(  147): Status Bar
I/SystemServer(  147): Clipboard Service
I/SystemServer(  147): Input Method Service
I/SystemServer(  147): NetStat Service
I/SystemServer(  147): NetworkManagement Service
I/SystemServer(  147): Connectivity Service
I/SystemServer(  147): Throttle Service
I/SystemServer(  147): Accessibility Manager
I/SystemServer(  147): Mount Service

Jeszcze nie widać? No, dobra. Widzisz kiedy jest startowany Mount Service? A teraz zobacz gdzie jest Package Manager. Między jednym a drugim wpisem mija dobrych kilkanaście – kilkadziesiąt sekund.  W tym czasie skanowane są aplikacje systemowe (/system/app) i użytkownika (/data/app i ewentualnie /sd-ext/app). Poprawność działania getSdExtState() jest uzależniona od działania Mount Service a w chwili próby skanowania /sd-ext/app ta usługa jeszcze nie działa. I to właśnie było źródło problemu

W systemie Android część usług została zaliczona do usług krytycznych (w powyższym wyciągu z logów od Entropy Service do Bluetooth Service). Na moje nieszczęście Mount Service nie trafił do tej kategorii. Z punktu widzenia twórców Androida nie było takiej potrzeby. Usługa ta jest potrzebna tylko do dostępu do kart pamięci. Zmiana kategorii tej usługi nie jest za bardzo możliwa bez potężnej ingerencji w nią samą i szereg innych komponentów a to oznacza więcej potencjalnych bugów. Najprostszym rozwiązaniem było porozmawianie (prawie) bezpośrednio z Voldem. Ubocznym skutkiem jest potencjalne wydłużenie startu systemu o maksymalnie 20 sekund. W skrajnej sytuacji może się okazać, że i tak aplikacje zainstalowane na SdExt się nie pokażą (w przypadku kłopotów z filesystemem). Wygląda to mniej więcej tak. Zdaję sobie sprawę z braków tego rozwiązania. Właściwie jest to tylko nieco hakerskie obejście. Prawidłowym rozwiązaniem jest skanowanie aplikacji z SdExt już po starcie systemu, tak jak to jest robione z aplikacjami zainstalowanymi na partycji FAT karty. Mam już nawet mgliste pojęcie jak to zrobić Jako bonus dostaniecie wtedy możliwość odmontowania i wyjęcia karty pamięci bez wyłączania telefonu Cieszycie się?

Zdaje się, że z niezmodyfikowanym systemem wytrzymałem jakieś 2-3 miesiące. Proces rootowania/odblokowania Dreama był wówczas nieco skomplikowany i wymagał przygotowania specjalnej karty. Bodaj w sierpniu pokazała się malutka aplikacja, dzięki której można było jednym kliknięciem odblokować Dream. No i się zaczęło.

Zainstalowałem wtedy jakiegoś CyanogenMod-a 4-coś. Przez jakiś czas wystarczało mi instalowanie kolejnych aktualizacji CM4, potem  CM5 i wreszcie CM6. Jakoś w wakacje zwróciłem uwagę na inne ROMy pojawiające się na forum XDA-Developers. Początkowo traktowałem je identycznie jak CMy czyli wipe i flash.  Zainwestowałem nawet w Titanium Backup, żeby nie tracić danych. Raz mnie jednak podkusiło, że zajrzeć do środka zipa. Wydaje mi się, że to był jakiś SpeedTeam Froyo. Numerka nie pamiętam, za to głównym hmmm… „developerem” był (sympatyczny skąd inąd) Jacob Chu-Hing bardziej znany jako XxKOLOHExX.

Developement w wykonaniu SpeedTeam polegał na podmianie paru grafik i xml-i (tzw theming) i dorzuceniu (nieco na oślep) paru cudownych skryptów do /system/etc/init.d. Dodatki typu „apps2sdext-out-of-the-box!” robione były poprzez wywoływanie (przy każdym starcie telefonu) bardzo popularnego (i przy okazji bardzo dobrze napisanego) skryptu Firerata o nazwie All in One Patch. Ten właśnie fakt sprawił, że zacząłem się bawić w modyfikowanie ROMów. Pierwsze kroki robiłem w znanym sobie terenie skryptów shellowych i ogólnie w tej części Androida, która leży na samiusieńkim spodzie i jest po prostu, przyciętym na miarę, Linuxem.

Parę tygodni później miałem na dysku komplet źródeł CyanogenModa a na telefonie samodzielnie skompilowany ROM. Znowu parę tygodni minęło i delikatnie zacząłem gmerać w kodzie. Pierwszym zupełnie samodzielnym dziełkiem było dołożenie możliwości kontrolowania swapu do CyanogenMod Settings. Trywialna modyfikacja javowego kodu i jeden czy dwa skrypty w shellu. Nic skomplikowanego. Dołożenie obsługi CPUFreq było trochę bardziej pracochłonne (i nie obyło się bez pomocy Joëla Bourquarda – autora Titanium Backup) ale się udało

W międzyczasie SpeedTeam zawiesił działalność a XxKOLOHExX przeszedł do Biff Squad. Wersja 2.0 BiffModa była w całości oparta o moją kompilację i pewnie byłaby sukcesem ale RoyalKnight zdecydował się na inny kernel i trochę niefortunnie wkleił go w przygotowaną przeze mnie paczkę. Zdarza się a ja się czegoś nowego nauczyłem Potem był BiffMod 2.1 przygotowany przez Ezterry’ego, z jego kernelem i moimi dodatkami. Mogłem spocząć na laurach i grzecznie czekać na Gingerbreada.

I pewnie bym spoczął gdyby nie twitterowa rozmowa najpierw z Cyanogenem a potem Fireratem. Jakoś tak wyszło, że razem z Fireratem zajęliśmy się tzw natywnym apps2sdext. Do tej pory możliwość instalacji aplikacji na partycji Ext2/3/4 karty była realizowana przy pomocy skryptów shellowych i polegała na oszukiwaniu systemu co do faktycznej lokalizacji plików apk. Gdybym miał chociaż blade pojęcie jak skomplikowany to projekt pewnie bym sie nigdy nie odważył za to zabrać. Prace nad wbudowanym w system apps2sdext trwały dobrze ponad 2 miesiące. Choć rozwiązań kolejnych problemów poszukiwaliśmy wspólnie, to jednak gross rozwiązań znajdował Firerat. Wiele razy zdarzało się, że dłubaliśmy nad jakimś kawałkiem kodu i już miałem rozwiązanie problemu na końcu języka gdy Firerat zaćwierkał „Ok, I made it”. Nigdy go nie spytałem czy kiedyś przydarzyła mu się podobna sytuacja ale ze mną w roli głównej. Mam nadzieję, że tak jest w tym wszystkim ładnych parę linijek mojego autorstwa.

No dobra ale co to ma wspólnego z tytułem wpisu? Ermm… zdradzę pewną tajemnicę… Nie znam Javy. Serio! Nie znam Javy. Nigdy wcześniej nie używałem tego języka (jestem przecież adminem a nie programistą!). Tymczasem całe to apps2sdext wymagało grzebania w jednym z kluczowych komponentów (framework.jar) napisanym w całości w Javie. Dziesiątki razy oglądałem kawałek kodu, dopisywałem kawałek kodu i bez przerwy odpytywałem Google na okoliczność składni tego czy innego polecenia Javy. Sprawdzałem dostępne funkcje, metody i temu podobne sprawy. O, właśnie! Metody! Dodatkowym smaczkiem jest to, że nigdy wcześniej nie pisałem niczego w jakimkolwiek obiektowo zorientowanym języku programowania Największym zaskoczeniem dla mnie jest to, że #LearningJavaUsingGoogle działa! Nie wierzysz? To zerknij na

• Zupełnie prywatne repo NLJota
• Coś jak oficjalne repo NLJota

Miłego haczenia Androida!!

NameLess
the Jedi

Mimo, że cenię sobie Twoje pisanie uważam mam do Ciebie pewien żal. Uważam, że powinno się uszanować żałobę narodową, żal rodzin, samych zmarłych i powagę ich urzędów. Na prawdę mogłeś się powstrzymać od pisania choć przez tych parę dni.
Nie potrzeba nam dodatkowego jątrzenia. Nie potrzeba dorzucania drewna do polskiego piekiełka. Nawet przez chwilę nie miałem wątpliwości, że polskie życie polityczne zmieni się o jotę po 10 kwietnia. Miałem nadzieję, że przynajmniej czas żałoby spędzimy wszyscy razem, ponad politycznymi podziałami. Bałem się zgrzytów w postaci mniej lub bardziej raptownych ruchów stricte politycznych pełniącego obowiązki Prezydenta RP.
W zamian ktoś zafundował nam aferę z Wawelem. Nie jestem z niej jakoś specjalnie dumny, wydaje mi się, że lepiej by było śp Prezydentowi Lechowi Kaczyńskiemu w Warszawie. Szanuję jednak wolę rodziny i nie biegam z transparentami. Szanuję tą decyzję nawet jeśli zarodek tej myśli pojawił się w głowach polityków. Ostatecznie zdecydowała jednak rodzina (mam taką nadzieję w każdym bądź razie). Mniej lub bardziej ostentacyjne demonstracje, tak przeciw pochówkowi na Wawelu jak i za, są wybitnie nie na miejscu. Choć na parę dni powstrzymajmy się od politykowania i politykierstwa. MY. Ja. Ty. Nawet jeśli ONI chcą się teraz bawić w politykę, to nie znaczy, że MY też musimy. Że odpowiedź musi być tu i teraz. Na wskazywanie palcami, tych co chcą zbić kapitał na tej katastrofie lotniczej będzie jeszcze mnóstwo czasu. Cała kampania prezydencka a i później pewnie też.

Nie kłóćmy się nad trumną. Żadną z tych 96.

Popatrzmy przez chwilę na Jarosława Kaczyńskiego. Jak to jest stracić bliźniaka? Jak to jest stracić swoje drugie ja, żywe odbicie.

Jak to jest stracić męża, żonę, ojca, matkę, córkę i syna. Choć do pogrzebu zobaczmy ludzi, w tych co umarli i tych co zostali przez nich osieroceni.

Przyznam się, że jak już postawiłem mój flagowy serwerek na nogi (z nowym dyskiem!!) poważnie rozważałem nie reaktywowanie tego bloga. Nie chciało mi się zaczynać od zera. Znowu. Życie jednak trochę zdecydowało za mnie. Blog, oprócz rzadkich okazji do wywnętrzania, stanowił również mój serwer autoryzacyjny OpenID. Przypomniał mi o tym Filmaster. Ciasteczko autoryzacyjne zakończyło żywot i nie mogłem się już zalogować. Odtworzyłem co mogłem (czyli stan z czerwca 2009) i dalej nie mogłem się zalogować… Ech.. Dobrze, że Michuk pomógł. Blog jednak już powstał z martwych więc pewnie sobie zostanie.

No to do poczytania! =o)

Od razu podkreślę jedną rzecz. Bezpieczeństwo komputera może na tym ucierpieć. W domyślnej konfiguracji blueproximity nie tylko blokuje ekran, gdy się oddalisz, ale również odblokowuje sesję bez pytania o hasło, gdy się pojawisz w pobliżu.  Podobnie jak przy innych technikach sieciowych, tak i tu, można się, w miarę łatwo, podszyć pod telefon. Dobrze jest więc wyłączyć widoczność urządzenia w menu telefonu.

Sam programik jest banalny tak w obsłudze jak i w konfiguracji. Nie podam swoich ustawień, bo dla każdego zestawu nadajnik – odbiornik będą inne. Dojście do nich zajęło mi nie więcej jak 20 minut i trochę kręcenia się po pokoju =o)  Domyślnie blueproximity kontroluje gnome-screensaver, nic nie stoi na przeszkodzie by uruchomić dowolny inny programik czy skrypt. Parę przykładów można znaleźć pod koniec tego postu.

Nie twierdzę, że to łatwe.

Nie chcę się tłumaczyć.

Po prostu nadszedł taki dzień.

Dzień pożegnania ze starą przyjaciółką.

Toyota Carina II (wyżej) była ze mną przez ostatnie 10 lat. W zeszłym roku stała sie pełnoletnia, w tym roku licznik pokazał 300 tys km. Niby autko swoje już przeszło ale było całkiem dziarskie. Z rozrzewnieniem patrzę na powyższe zdjęcie. Lubię tą Toyotę. To nie pierwsze moje auto ale pierwsze, które darzę taką sympatią. Taka przytulanka dla dorosłego faceta Najgorsze w tym, że z przytulanek się wyrasta a ja z Toyoty nie wyrosłem tylko musiałem się z nią rozstać. Zastąpić ją. Miała być następna Toyota. Myślałem też o FreeLanderze. Koniec końców zwyciężyła pewność źródła pochodzenia samochodu a nie marka czy model (oczywisty współczynnik ceny pomijam). Srebrne auto ma teraz dokładnie tyle samo lat co Toyota, gdy ją kupowałem. Czy znajomość z Passatem też potrwa 10 lat? Czas pokaże… Na razie cieszę się klimą, przestrzenią i lekkością działania z domieszką niemieckiej toporności. Do zobaczenia na drodze (i do poczytania za czas jakiś

PS.

Tytuł wpisu to okrzyk kończący wygraną rozgrywkę w mojej (nadal) ulubionej strzelance sieciowej BattleField: Bad Company. Yes! The Gold is mine! Margeritas and Malibus boys!

Jeszcze tylko wyjaśnienie tytułu. Ostanimi czasy namiętnie (co nie znaczy, że często ;o) ) grywam w Battlefield: Bad Company na Xbox Live. Sieciowa strzelanka w realiach współczesnego pola walki. Super rzecz. Gorąco polecam. Jednym z trybów rozgrywki jest „Gold Crates”. Dwie drużyny walczą ze sobą o skrzynie ze złotem. Jedna z nich atakuje i próbuje zdobyć skrzynie, druga – broni tychże skrzyń. Każda mapka składa się z 3 -4 etapów, a każdy etap to zdobycie dwóch skrzyń. Po zdobyciu jednej z takich skrzyń, w „radiu” słychać zadowolony głos obwieszczający „Gold Crate One taken!”. Połowa etapu. Ani łatwiejsza, ani trudniejsza. Po prostu: połowa.

Zaczęło się od 13 odcinka Fringe. Odcinek nawet całkiem – całkiem. Ale napisy…. Zaczęło się w pierwszej minucie. Co innego słyszę – co innego widzę. I nie chodzi mi tu o drobne różnice, mieszczące się w ramach licentia poetica, tylko o coś diametralnie różnego. Przełknąłem i poszedłem dalej. Dalej niestety było gorzej.  Hitem była niespójność i nielogiczność w tłumaczeniu dwóch następujących po sobie kwestiach. Nie przełknąłem. Zacząłem poprawiać. Poprawki (w liczbie około 40) wysłałem autorowi. Przyjął je nawet ciepło. Wytłumaczył się pośpiechem i zbytnim zawierzeniem angielskim napisom. To drugie jeszcze jakoś mogę zrozumieć – czasem ciężko uwierzyć, że i angielskie napisy nie muszą mieć nic wspólnego z filmem. Gorzej z tym pierwszym. Pośpiech jest wskazany w dwóch przypadkach: łapaniu pcheł i jedzeniu z jednej miski (prawda, Kaszi?). Przy tłumaczeniach, pośpiech prowadzi do błędów. Im bardziej początkujący tłumacz, tym ich więcej. Zaczyna się od bezmyślnego tłumaczenia oryginalnego tekstu, bez zrozumienia i zastanowienia. Potem wyłazi kiepskie rozumienie idiomów (nawet tych popularnych) czy nieznajomość rzadziej używanych zwrotów. A w efekcie otrzymujemy czasem tylko kiepskie a czasem po prostu złe tłumaczenie.

Nie ilość, panowie tłumacze, nie czas a jakość niech świadczy o waszym kunszcie (bądź jego braku). Przyłóżcie się choć trochę do tego co robicie. Nie twórzcie jakichś lotniczych bakterii (airborn bacteria) czy win pleśniowych (botritized wine). Tylko zerknijcie w jakiś słownik albo chociaż w Gógle i sprawdźcie co to za bestia. Nie ma czegoś takiego jak lotnicze bakterie ani wina pleśniowe. Och, nie oczekuję, że tłumacz będzie znał się na bakteriologii czy winach. Nie musi! Wystarczy chwilę pomyśleć, pokombinować by wiedzieć, że wina z nadpleśniałych  winogron to botrytyzowane wina a nie pleśniowe.

Brzmi jak wymądrzanie się? Być może.Nie jestem aktywnym tłumaczem. W ciągu ostatniego roku przetłumaczyłem raptem dwa odcinki Sanctuary. Pierwszy z nich dlatego, że to co miało być angielskimi napisami było jakimś dziwacznym tekstem anglojęzycznym z wplecionymi włoskimi słowami. Drugi – bo nikt tego nie zrobił przede mna, a ludzie pozytywnie zareagowali na wcześniejsze tłumaczenie. Każde z tych tłumaczeń zajęło mi minimum 6 godzin pracy. Tłumaczenie odcinka 12 robiłem 3 dni, a odcinka 13 – dobrze ponad tydzień. Z obu jestem dumny. Wiem, że nie byłbym w stanie przetłumaczyć tego lepiej a pod tym co stworzyłem, bez wstydu mogę się podpisać (co prawda pseudonimem, ale moim pseudonimem).

Winnymi całej sytuacji są jednak nie tylko tłumacze. Wcale nie tak dużo mniejszą winę ponoszą odbiorcy. Bezkrytycznie wystawiają najwyższe oceny nie za jakość tłumaczenia a za szybkość pojawienia się w serwisie. I tu muszę się walnąć w piersi. Zahuczało? Nie? A powinno. Nie, nie wystawiam ocen w ciemno. Ja ich w ogóle nie wystawiałem. Pozostawałem bierny. Zaniechałem. Ale z tym już koniec. Zacząłem wytykać błędy, wystawiać oceny, chwalić gdy dobrze i ganić gdy źle. Do tego samego namawiam i Ciebie. Jasne, nie wszyscy muszą znać język obcy na tyle, by móc ocenić je merytorycznie. Niektóre błędy można wyłapać i bez tej znajomości. Czasami nawet podstawy wystarczą by odróżnić słyszane four weeks od przeczytanych czterech miesięcy (napisy pewnego duetu, do jednego z odcinków Eleventh Hour – to zresztą wyczyny tego duetu, w dużej mierze, sprowokowały ten wpis). Drobiazg? Taki mały błąd w tłumaczeniu? OK. Tylko skąd pewność, że nie ma tam większych baboli? Dlatego proszę o więcej krytycyzmu. Wszystkim nam to wyjdzie tylko na dobre.

I na koniec jeszcze jedna uwaga. W powyższym tekście wyżywam się na tłumaczeniach sieciowych. Robionych przez zapaleńców, poświęcających swój wolny czas. Nie czarujmy się jednak. To, co się dzieje w TV czy na płytach DVD nie odbiega aż tak bardzo.  Czasem odnoszę wrażenie, że dobre tłumaczenia występują tylko w przypadku filmów dla dzieci (na przykład genialny Shrek) albo filmach tłumaczonych ponad 10 lat temu. Rzuca mną jak słyszę na AXN „profesjonalne” tłumaczenie Stargate SG-1. Autora powinno się włóczyć koniem a potem resztki odesłać do jakiegoś studium językowego. Z tłumaczeniem przypiętym do piersi. Na postrach. Czy można coś na to zaradzić? Nie wiem. Może… a może nie…

Ale…

może…

warto próbować (?)