Metafora dialogu

Tłumaczenie interfejsów różnych aplikacji często boleśnie rani wrodzone poczucie języka ojczystego lub pod pozorem językowej staranności równie starannie ukrywa tajemnicę praktycznego znaczenia poszczególnych fraz interfejsu. Jak zapanować nad tą trudną i niesforną materią?

Według słownika języka polskiego PWN interfejs użytkownika to «program umożliwiający współpracę użytkownika z oprogramowaniem komputera». Współpraca ta polega na obustronnej wymianie informacji. Interfejs informuje użytkownika o tym co może on uzyskać od oprogramowania, a użytkownik, za pomocą interfejsu informuje oprogramowanie o tym co chce uzyskać. Jeżeli oferta trafia w zapotrzebowanie dochodzi do konsumpcji usługi i obie strony są zadowolone. Zaraz, jakie „obie strony”?

Spojrzenie na interfejs właśnie poprzez metaforę dialogu daje tłumaczowi z jednej strony potrzebny dystans, a z drugiej mocne oparcie na znanym z codziennego życia scenariuszu. W przypadku Drupala nie powinno być trudno wyobrazić sobie siebie siedzącego wspólnie z Drupalem przy stoliku i popijającego ulubioną yerba-mate.

Drupal przyniósł na spotkanie teczkę wypełnioną arkuszami. Arkusze zapisane są dwoma rodzajami komunikatów. Komunikaty aktywne (odsyłacze) to lista Twoich kwestii, komunikaty pasywne (objaśnienia) to kwestie Drupala, przy czym podstawową formą jego wypowiedzi jest prezentacja żądanych informacji. Drupal to sympatyczny gość, ale to siedmiolatek, więc zbyt wiele nie można od niego wymagać. Mówisz — Pokaż moje konto — w odpowiedzi Drupal sięga do przyniesionej teczki i wyciąga odpowiedni arkusz. Słowo „pokaż” możesz pominąć bo prezentacja informacji to domyślne zadanie Drupala. Samo — Moje konto — w zupełności wystarczy. Natomiast próba zwrócenia się do Drupala z propozycją — Zarządzaj — wywoła wyłącznie wzruszenie jego ramion. Drupal nie wie co to znaczy. To Ty możesz zarządzać, nie on. Natomiast, jeżeli powiesz — Centrum zarządzania — Drupal z typowym dla siebie uśmiechem nieomylnie sięgnie po odpowiedni arkusz. Propozycja — czytaj dalej — nie wywoła jego żadnej reakcji, natomiast — [pokaż dalej] więcej… — będzie dla Drupala zrozumiałym sygnałem do rozłożenia arkusza w celu pokazania dalszego ciągu treści. Generalnie Ty werbalizujesz prośbę, a Drupal w odpowiedzi realizuje ją. Czasem, jeżeli to konieczne, informuje Cię lub ostrzega odpowiednim komunikatem. Oczywiście w tak prowadzonym dialogu mogą pojawić się wątpliwości. Przykładem niech będzie — Dodaj treść — czy Drupal umie dodać treść? Założyłem, że tak. Ja mu ja tylko podaję.

Po kilku wieczorach takich rozmów z Drupalem, z zanotowanych list dialogowych wyłoni się naturalne w brzmieniu i przyjemne w obcowaniu tłumaczenie interfejsu Drupala. To forma. A treść? W kolejnym wpisie o tym jak zadbać o adekwatność fraz.

Drupalowe mity

Jest taka właściwość ludzkiego umysłu, która nieustająco nakazuje werbalizację wszelkich wrażeń. Można co prawda tę właściwość podporządkować woli, ale nie jest to takie proste. Z właściwości tej wynika jednak prosta i istotna implikacja. Wszystko to, czego nie potrafimy nazwać, spychane jest poza świadomość, czyli w praktyce przestaje istnieć. Natomiast to, co jest nazwane w sposób sprzeczny z dotychczasowym doświadczeniem budzi (zrozumiały) opór umysłu. Opór ten zostaje zwerbalizowany słowami: trudny, skomplikowany, niezrozumiały, zagmatwany, wymagający lub bardziej emocjonalnie bez sensu lub wręcz do d.... I taki właśnie w opinii wielu osób jest system zarządzania treścią Drupal.

Nie dałem wiary takim opiniom i postanowiłem osobiście doświadczyć Drupala. Właśnie: doświadczyć działania mechanizmów, a nie zrozumieć je poprzez warstwę słowną w jaką zostały opakowane. Pierwsze opakowanie zostało dokonane przez twórców. Ze zrozumiałych przyczyn językiem opakowania stał się język angielski, chociaż nie jest on językiem ojczystym kierującego projektem Driesa Buytaerta. Drugie opakowanie to wszystko to, co zostało dodane lub odebrane oryginałowi w procesie tłumaczenia interfejsu. Próba doświadczenia działania mechanizmów mogła nastąpić dopiero po dość czasochłonnym i wcale nie prostym „przegryzieniu się” przez opakowanie. Okazało się, że wnętrze kryje lśniące i znakomicie przemyślane mechanizmy, sprawnie przetwarzające przeróżne typy treści w sposób w pełni kontrolowany.

Jak w takim razie ułatwić pierwszy kontakt z Drupalem? Kluczem wydaje się niestandardowe podejście do tłumaczenia interfejsu. Obok rozważań nad pięknem i wiernością przekładu — na dodatek w kontrpozycji — dochodzi jeszcze problem wyrażony przez poetę troską „aby język giętki powiedział wszystko, co pomyśli głowa”. W moim mniemaniu tłumaczenie interfejsu użytkownika jakiejkolwiek aplikacji powinno przede wszystkim spełniać postulat Słowackiego, następnie być piękne, a jeżeli dwa pierwsze warunki zostaną spełnione, również wierne.

Realizacja tak postawionego zadania wydaje się trudna. Wymaga umiejętności zrozumienia znaczenia frazy w kontekście jej wystąpienia i zwerbalizowania tego zrozumienia słowami języka przekładu. Całą operację krępuje dodatkowo próba zachowania zgodności w tył i przód. W tak niesprzyjających warunkach nie trudno ulec pokusie przekładu „słowo w słowo”. Takie tłumaczenie nie urzeka językowym pięknem, a prawdziwy sens frazy często ujawnia się dopiero w działaniu.

W takim razie jak tłumaczyć interfejsy? O tym w kolejnym wpisie.

Lubię Drupala

Pierwszy serwis internetowy zamieściłem w sieci w 1999 roku. Nota bene funkcjonuje on do dziś dnia bez większych zmian. Owszem, wygląda dosyć archaicznie, ale całkiem nieźle sobie radzi. Pierwsza jego wersja została „wystrugana” w czystym HTML-u za pomocą nieocenionego edytora ezHTML autorstwa Pawła „Pafcia” Przewłockiego. W jakiś czas później dorobiłem silnik oparty na technologii LAMP, czyli tandemie PHP i MySQL pracującym w środowisku linuksowym pod kontrolą serwera Apache. Z zewnątrz prawie nic się nie zmieniło, natomiast z mojego punktu widzenia zmieniło się wszystko. Zabierające wiele czasu ręczne aktualizacje dokonywane przeze mnie na podstawie informacji otrzymywanych za pośrednictwem e-maili zostały zastąpione pracą skryptów PHP. Stało się jasne, że przyszłością publikacji internetowych będą serwisy tworzone dynamicznie za pośrednictwem aplikacji skryptowych.

Kolejny okres to tworzenie aplikacji internetowych na konkretne zamówienie. Co prawda dorobiłem się w tym czasie kilku własnych bibliotek z procedurami, ale i tak była to praca dość żmudna. Równocześnie zaczęły pojawiać się w sieci, tworzone przez zespoły programistów, skryptowe systemy przeznaczone do obsługi portali. Mój wybór padł na phpWebThings. W oparciu o to rozwią­zanie (dziś raczej zapomniane) stworzyłem kilka serwisów, z których co najmniej jeden funkcjonuje do dziś.

I przyszedł Ajax. Jak to w pewnej reklamie śpiewano: praca z Ajaxem czystym relaksem. Korzystając z tej technologii stworzyłem niewielki CMS na jednostkowe zamówienie. Założeniem generalnym była możliwość edycji tekstu bezpośrednio w miejscu jego występowania w ramach sztywnego, z góry narzuconego szablonu, co zostało w pełni zrealizowane. Ajax znakomicie sprawdził się również w skrypcie obsługującym galerię zdjęć w innym, generalnie statycznym serwisie internetowym.

Równocześnie, od czasu do czasu, dokonywałem testowych instalacji różnych systemów CMS. Trochę z ciekawości, a trochę w poszukiwaniu elastycznego i dobrze napisanego systemu na którym można by było oprzeć duże i wymagające serwisy internetowe. Z reguły testowane rozwiązania jakoś mnie nie zachwycały, a jak już prawie zachwycały, to okazywało się, że czegoś za ich pomocą nie da się (w rozsądny sposób) zrealizować.

Teraz już wiem. Lubię Drupala.