Tłumaczenie stron WWW – fakty i mity

2020-03-30
Tłumaczenie stron WWW – fakty i mity

Tłumaczenie stron WWW – fakty i mity

Autor: Agenor Hofmann-Delbor

Strona internetowa jest dziś oczywistym elementem każdej działalności. Nic więc dziwnego, że liczba zleceń związanych z lokalizacją stron internetowych i materiałów na nich zawartych stale rośnie. Nic nie wskazuje na to, by ten trend miał się zmienić, warto więc spojrzeć na kilka kluczowych tematów związanych z tłumaczeniami stron.

Niestety, często okazuje się, że tłumacze, którzy rozpoczynają swoją przygodę z lokalizacją stron WWW (w rozumieniu tłumaczenia z adaptacją do lokalnych norm kulturowo-technicznych) napotykają na szereg porad i wskazówek, które mogą narazić ich na spore kłopoty. Nazwijmy rzeczy po imieniu – porad szkodliwych i wynikających z niewiedzy. Ten artykuł ma być wskazówką, jak poradzić sobie z tłumaczeniem stron internetowych.

Założenia dzisiejszych stron internetowych powstały prawie 30 lat temu. Proces wygląda podobnie do dziś: przeglądarka internetowa łączy się z określonym adresem URL i wyświetla wynik. Zobaczmy, co to właściwie oznacza:

Przeglądarka internetowa… - aplikacja, program komputerowy, który umie obsługiwać protokół http(s) i odpowiednio przetwarzać przesyłane dane.

łączy się z – czyli przesyła zapytania zgodne z protokołem http, umożliwiając komunikację miedzy naszym komputerem, a maszyną, na której znajduje się strona (ta „nasłuchuje” na żądania, odpowiada w ustandaryzowany sposób, który rozumie nasza przeglądarka)

określonym - wpisujemy najczęściej adres internetowy w formie słownej zamiast konkretnego adresu IP komputera, a więc po drodze serwery DNS „tłumaczą” nasz zapis słowny z nazwą domeny na bardziej techniczny adres wskazujący konkretną maszynę w sieci
adresem URL – czyli coś, co wynika wprost z poprzedniego punktu i określa wprost, z jaką stroną się łączymy, z przedrostkiem (prefiksem), hostem, domeną (a właściwie poziomem domeny)
wyświetla wynik. – nasza przeglądarka internetowa otrzymuje strumień informacji z serwera i układa go, korzystając z reguł języka (x)HTML, czyniąc go w założeniu czytelnym dla nas.

Choć cały proces jest właściwie taki sam, diabeł tkwi w szczegółach. Jeśli cofniemy się w czasie o 20 lat (a można to zrobić np. na portalu takim jak www.archive.org), zobaczymy, że dawniej strony internetowe na serwerach docelowych były wprost umieszczonymi plikami z rozszerzeniem html i pewną zapisaną w nich strukturą wg składni tego języka znacznikowego. Zatem „zapytany” serwer wprost odczytywał zawartość pliku i przesyłał ją do naszej przeglądarki. Adres przeglądanej witryny pokazywał nam bezpośrednio przeglądany plik, np. www.straszniedawnedzieje.pl/toczytasz.html. Znając strukturę strony, mogliśmy bez większych przeszkód zapisać sobie plik na swoim komputerze.

Mogliśmy też zrobić kompletną kopię całego serwisu z podstronami, czyli tzw. mirror strony. Do dziś funkcjonuje wiele programów, które mają „zrzucić” całą stronę docelową na nasz dysk. Przeróżne warianty „website downloadera”, „html grabbera” i pokrewnych cały czas mają się dobrze i są popularne w Google. Jedną z kluczowych wieloplatformowych aplikacji tego typu jest program wget, który prostym poleceniem wget –mirror stronadocelowa umożliwia pobranie strony i wszystkich jej zasobów.

Tyle że to już nie działa, bo już od co najmniej kilkunastu lat strony w zdecydowanej większości serwisów przestały być stronami statycznymi (zaraz wyjaśnię, co mam na myśli). Skoro tak, dlaczego wspominam o tych historycznych już dziś podejściach? Dlatego, że w grupach branżowych nadal pokuje mit, że strona na ekranie to plik, który wystarczy sobie skopiować, by przetłumaczyć zawartość serwisu dla zleceniodawcy. Otóż nie, nie wystarczy.

To, co widzi nasza przeglądarka, to tylko odpowiedź serwera docelowego przesłana do naszej przeglądarki internetowej i wyświetlona na ekranie. Jeśli strona, którą odwiedzasz, nie kieruje wprost do danego pliku html (co widać w pasku adresu), masz 99% szans, że łączysz się z tzw. dynamiczną stroną internetową.

No dobrze, ale skąd biorą się strony dynamiczne? Taka strona, jak sama nazwa wskazuje, powstaje w momencie otrzymania zapytania. Jest na bieżąco składana w całość tylko i wyłącznie dla końcowego odbiorcy. Można więc powiedzieć, że obecnie Internet sprawił, że wszyscy oglądamy strony przygotowane specjalnie dla nas. Nie ma żadnych przeszkód, aby każdy użytkownik tej samej strony widział w swojej przeglądarce coś zupełnie innego. Jak to możliwe? Steruje tym CMS, czyli system zarządzania treścią. Z perspektywy naszej przeglądarki internetowej jest to zupełnie niewidoczny mechanizm, schowany gdzieś na docelowym serwerze. My widzimy odpowiedź, którą przesyła nam zainstalowany na serwerze program służący do przechowywania stron internetowych i zarządzania nimi, tzw. webserwer. I to właśnie ten program jest pośrednikiem między nami, a zainstalowanym na serwerze systemem zarządzania treścią, czyli oprogramowaniu, które pozwala budować na bieżąco strukturę i treść danego serwisu. CMS-y są popularne, bo pozwalają składać stronę z klocków w kilka minut. Przechowują też wszystkie informacje w bazach danych, dzięki czemu w ogóle możliwe jest dynamiczne budowanie strony dla danego użytkownika. Jest wiele CMS-ów, ale te najbardziej znane, które najprawdopodobniej widzisz (często nieświadomie, bo nie jest to zawsze widoczne od razu), to Wordpress, Joomla, Drupal.

No to wróćmy do „webserwer otrzymuje zapytanie”. Aplikacja, która czuwa na serwerze i nasłuchuje na określonym porcie, otrzymała zapytanie do konkretnej witryny internetowej. Sprawdza, czy ma ją w swoich zasobach (ma w swojej konfiguracji pewien rodzaj katalogu zainstalowanych stron) i gdy ją znajdzie, przekazuje zapytanie. Jeśli byłby to zwykły plik html, zapytanie wróciłoby do naszej przeglądarki wraz z jego zawartością. W przypadku CMS-ów zamiast pliku html zostanie odczytany plik php (lub w innym języku skryptowym), który sprawi, że system CMS zacznie działać i składać dla nas dynamicznie odpowiedź. Zobaczymy na przykład to:

localize.pl

Źródło: www.localize.pl

CMS sprawdził więc całą masę informacji, którą przeglądarka internetowa przekazała w swoim żądaniu wysłanym do serwera docelowego. Serwer wie, z jakiego adresu IP łączymy się z serwisem, wie, jakiego języka używa nasza przeglądarka, jakie ciasteczka nasza przeglądarka (są to pliki pamiętające np. co mieliśmy w koszyku przy ostatniej wizycie), jaki token sesji dostaliśmy (czyli czy jesteśmy zalogowani). I teraz najważniejsze – każdy z tych elementów, a to tylko niewielki ich wycinek, może sprawić, że CMS złoży zupełnie inną stronę. Zerknijmy na inny przykład:

localization.pl

Źródło: www.localization.pl

Oto prosta strona zbudowana na Wordpressie. Widzimy menu, bloki tekstowe, artykuły. Wygląd każdego z tych elementów może być zależny od tego, czy stronę przegląda użytkownik korzystający z danego języka przeglądarki, w szczególności zaś – czy jest to zalogowany użytkownik. A jeśli zalogowany – czy jest akurat w grupie, która powinna mieć dostęp do danego elementu.

panel WP

Źródło: www.localization.pl

Tu kolejny przykład z Wordpressa – element strony może być w ten sposób zabezpieczony przed anonimowym, publicznym dostępem. Przeglądarka niezalogowanego użytkownika (lub użytkownika, który nie zna hasła) nie wyświetli określonej treści. Blok zostanie zastąpiony innym lub pominięty. Nie zobaczymy go na stronie. Nie zobaczy go też nasza przeglądarka. Możemy kliknąć taką stronę myszą, zaznaczyć całą jej zawartość, skopiować gdzie tylko chcemy, ale takiej treści tam nie będzie. To samo, jeśli użyjemy wgeta, czy dowolnego innego programu do robienia „zrzutu” strony internetowej. Wersja TL;DR tego artykułu:

To nie zadziała. Nie kopiuj strony z przeglądarki do Worda.


No to jak wyceniać i tłumaczyć strony internetowe?

  1. Nie kopiuj jej zawartości z przeglądarki. Zgubisz po drodze sporo rzeczy, a niektórych nie zobaczysz wcale.
  2. Uzyskaj pliki źródłowe, jeśli jakimś cudem jest to strona statyczna. Gdy masz htmla, to nie ma nic prostszego. Włącz SDL Trados Studio i tłumacz. Nie ma chyba bezpieczniejszego i przyjemniejszego formatu do tłumaczenia niż html. Gdy masz już pliki, użyj funkcji analizy, by błyskawicznie ocenić ile pracy będzie realnie do wykonania nad danym dokumentem.
  3. Jeśli dostajesz od klienta wyłącznie adres strony, upewnij się, że klient dostarczy również dane dostępowe do CMS-a i wyraźnie określi, które części serwisu mają być tłumaczone, a które nie. Po zalogowaniu do systemu będzie można wprost wybrać poszczególne gałęzie (np. artykuły, menu, zostawiając w oryginale panel administracyjny, jeśli nie jest potrzebny). Tu może okazać się, że klient będzie mieć w CMS-ie wbudowany moduł do tłumaczenia. Jest to najczęściej horror tłumacza, który zobaczy w praktyce okienko do wprowadzania tekstu i nie będzie mógł skorzystać z żadnych plusów, które na co dzień zna w CAT-ach. Jest to jeden sposób: użycie narzędzia SDL T-Window for Clipboard.

Źródło: SDL App Store

    Narzędzie to po uruchomieniu czeka aż cokolwiek skopiujemy do systemowego schowka. W ten sposób możemy pracować w dowolnym programie, który jest w stanie skopiować tekst do schowka systemowego, mając jednocześnie możliwość korzystania z podpowiedzi z pamięci tłumaczeń w sposób zbliżony do tego, co znamy np. z SDL Trados Studio. T-Window daleko do wygody (musimy kopiować i wklejać każdy tekst), ale zapewnia nieocenioną możliwość zapamiętywania tłumaczeń z praktycznie dowolnego systemu online, a jednocześnie podpowiedzi można wykorzystywać w sposób znany z CAT-ów). Jest to pewna proteza, która jest niezwykle pomocna, gdy musimy pracować w jakimś online’owym edytorze rodem z horrorów.
  1. Jeśli klient upiera się, żeby nie dać dostępu do serwisu, poproś o eksport z CMS-a treści, które mają być lokalizowane. Taki eksport dziś jest możliwy wprost do otwieranego w dowolnym narzędziu CAT formacie xliff. Jeśli nie, CMS z całą pewnością jest w stanie wygenerować plik XML z treścią (można np. skorzystać z wtyczki PolyLang). Taki plik zaś można bez problemu otworzyć w SDL Trados Studio, wskazując sposób obsługi poszczególnych znaczników, czyli mówiąc programowi co ma tłumaczyć, a co nie. Zachowanie struktury dokumentu w trakcie tłumaczenia umożliwi potem bezproblemowy import z powrotem do CMS-a. Zmiany zobaczymy wówczas bezpośrednio na stronach.
  2. Jeśli klient nie chce dać ani eksportu, ani dostępu do CMS-a, argumentując, że sobie potem poprzekleja tłumaczenie z Worda od nas, powinniśmy poinformować go o ryzyku związanym z taką pracą, a potem zastrzec wyraźnie, że wycena będzie dotyczyła treści skopiowanej z przeglądarki, a nie realnej zawartości strony na serwerze. W ten sposób zabezpieczamy się przed sytuacją, w której klient zorientuje się, że część tekstów była widoczna tylko dla użytkowników z określonymi uprawnieniami i będzie oczekiwać uwzględnienia ich w dostarczonym materiale (czyli de facto – pracy za darmo).

Treść, a może coś więcej?

Warto też zadać sobie pytanie co dziś tłumaczymy w ramach typowej strony internetowej? Oczywiście zawsze będzie to zawartość strony – teksty, podpisy pod obrazkami, nagłówki, tytuły, elementy grafiki (które edytujemy oczywiście w zewnętrznej aplikacji). To jednak tylko fragment pracy. Strona internetowa, aby miała sens, musi być łatwa do odnalezienia w wyszukiwarkach, powinna też być możliwie najlepiej oznaczona, przypisana do określonej kategorii i opisana. Szczególnie istotne jest też dziś, aby spełniała wymogi urządzeń mobilnych, dawała się poprawnie zaindeksować (czyli zostać odczytana przez automatyczne programy katalogujące witryny na potrzeby wyszukiwarek internetowych). To też dziś w dużej mierze informacje ułatwiające pozycjonowanie, czyli wyświetlanie wyników wyszukiwania z uwzględnieniem zawartości danej strony. Algorytmy wyszukiwarek internetowych są coraz bardziej złożone, a my musimy pamiętać, że tłumaczenie serwisu to już nie tylko to, co widać na ekranie, ale też metadane, które często zawierają frazy kluczowe, opisy pisane pod kątem indeksowania, wszelkie pola tekstowe (tooltipy, czyli tzw. dymki) i całą masę tekstów i komunikatów, które są częścią strony, ale nie widać ich gołym okiem. To też należy dziś do zadań kogoś, kto lokalizuje stronę internetową. Ba! Musimy już myśleć o tym, jak ktoś będzie szukać naszej strony. Może akurat powie do swojej Siri (lub Alexy) „hej, znajdź mi stronę, na której mowa jest o pieczeniu ciasteczek cynamonowych”. I to musi pojawić się w treści. SEO i tłumaczenie zaczynają się coraz bardziej ze sobą zazębiać.

Temat tłumaczenia stron WWW jest tu oczywiście podany bardzo skrótowo. Głównym celem było rozprawienie się ze szkodliwymi poradami, w ramach których tłumacze czytają, że wycenę strony należy rozpoczynać od skopiowania strony z przeglądarki do Worda. Jeśli zainteresował Cię temat, polecam kilka szkoleń, które prowadzimy na życzenie w wariantach indywidualnych i grupowych:

Zainteresowanych prosimy o kontakt pod adresem info@localize.pl.

Localize.pl korzysta z plików cookie, dzięki którym strona może utrzymywać stan zalogowania, zawartość koszyka sklepowego oraz informacje pomocnicze. Prosimy o zapoznanie się z naszą Polityką Prywatności, a w szczególności z rozdziałem o plikach cookie. W każdym momencie możesz zmienić ustawienia zapisywania plików cookie.
Zamknij
pixel