Microsoft wydając system Windows nie przewidział dla niego obsługi wielu języków. Kiedy stało się jasne, że ich produkt odniesie sukces nie tylko na rynku anglojęzycznym, pospiesznie przygotowano również inne wersje językowe. Zdaje się, że najważniejszym (a może nawet jedynym) kreterium doboru słownictwa w wersji polskiej, była szerokość widżetów, takich jak pola tekstowe, pola wyboru i innych.

Trzeba bowiem wiedzieć, że w nowoczesnych środowiskach takich jak GNOME, Xfce czy KDE, wymiary widżetów automatycznie dopasowywane są do ich zawartości. Przypomina to trochę formatowanie hipertekstu podczas zmiany rozmiaru okna przeglądarki. W rezultacie Linux doskonale sprawdza się jako system wielojęzyczny. Nie narzuca się tu żadnych ograniczeń co do długości tłumaczonych komunikatów, umożliwia poprawną odmianę liczebników, itp. Zupełnie inaczej rzecz wygląda w przypadku produktu firmy Microsoft.

Niestety słownictwo, które zawitało pod strzechy wraz z systemem Windows, przetrwało do dzisiaj, ma się dobrze i co najgorsze - nie widać możliwości jego zmiany na lepsze. Potworki takie jak „ładowanie” (w odniesieniu do wczytywania) czy „aplikacja” stały sie na tyle popularne, że nie ma szans, aby je wyeliminować z potocznej mowy.

Przygotowując tłumaczenie środowiska Xfce życzyłbym sobie, aby stanowiło ono inną jakość. Chcę by było ono bezkompromisowe i stało w tej kwestii w opozycji do innych podobnych projektów - nawet otwartoźródłowych.

Środowisko Xfce do procesu tłumaczenia używa systemu GNU gettext.

Komunikaty programów zawarte w kodzie źródłowym przechowywane są w specjalnych plikach:

• .pot (Portable Object Template) - przechowującym komunikaty wydobyte z kodu źródłowego,
• .po (Portable Object) - przechowującym tłumaczenia tychże komunikatów.

W praktyce plik .pot jest szablonem dla nowych plików tłumaczeń. Aby utworzyć plik z tłumaczeniami komunikatów w języku, którego dany program jeszcze nie obsługuje, wystarczy skopiować plik .pot zmieniając jego rozszerzenie na .po.

W większości plików tłumaczeń można wyróżnić 4 części:

• stopkę z danymi edytorów i innymi informacjami umieszczonymi za znakami komentarza,
• nagłówek zawierający szczegóły techniczne tłumaczenia, m.in. deklarację form liczby mnogiej,
• blok tłumaczeń oraz
• tłumaczenia które uległy przedawnieniu po aktualizacji komunikatów z kodów źródłowych.

Pliki .po można modyfikować jak zwykłe pliki tekstowe, używając do tego celu edytora tekstu. Taki sposób edycji jest jednak niewygodny i niewskazany ze względu na łatwość popełaniania błędów. W praktyce do tego celu najlepiej nadają się dedykowane edytory tłumaczeń. Udostępniają one udogodnienia, takie jak modyfikowanie nagłówka i komentarza pliku, automatyczne wypełnianie nagłówka i komentarza danymi, korzystanie z bazy tłumaczeń czy sprawdzanie błędów ortograficznych. Najbardzie popularne edytory tłumaczeń to poedit oraz gtranslator (który osobiście polecam ze względu na ciągły rozwój programu). Możliwe jest również edytowanie plików za pomocą edytora umieszczonego na stronie systemu tłumaczeń Transifex. W praktyce nadaje się on najlepiej do szybkiego wprowadzania zmian.

Komunikaty bardzo często zawierają parametry oznaczane w plikach źródłowych np. jako ciąg znaków „%s”. Podczas wyświetlania komunikatu parametr zastępowany jest niezmiennym i niezależnym od używanego języka ciągiem. Pominięcie oznaczenia parametru w tłumaczonym komunikacie może powodować błędy na różnych etapach tłumaczenia. Jeśli w pierwotnym komunikacie znajduje się wiecej niż jeden parametr oznaczony w ten sam sposób, np.

\“%s\” (%s) %s,

można zmienić ich kolejność dodając do oznaczenia liczbę porządkową i znak „$”:

%3$s „%1$s” (%2$s).

GNU gettext umożliwia zadeklarowanie dowolnej ilości form komunikatów w liczbie mnogiej. Takie komunikaty zazwyczaj występują z parametrem reprezentującym liczebnik (zazwyczaj %d). Deklarację tę należy zamieścić w nagłówku pliku, używając specjalnej składni. Pozwoli to przetłumaczonemu programowi na wyświetlanie poprawnie brzmiących komunikatów, niezależnie od zawartych w nich liczebników. Dla języka polskiego deklaracja form liczby mnogiej wygląda następująco:

nplurals=3; plural=((n==1) ? 0 : ((n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20)) ? 1 : 2));

Aby stworzyć wartościowe tłumaczenie, które będzie można dołączyć do repozytoriów Xfce, należy podczas procesu tłumaczenia przestrzegać ustalonych wytycznych.

Nadrzędną zasadą jest tu zachowanie spójności tłumaczeń w całym środowisku graficznym. Zarówno programy zewnętrzne jak i programy wchodzące w skład środowiska, muszą korzystać z ujednoliconego nazewnictwa i pisowni. Zachowanie tej zasady będzie możliwe dzięki zastosowaniu kilku prostych reguł. Najważniejsze z nich to:

• używanie poprawnej pisowni z uwzględnieniem pisowni znaków interpunkcyjnych,
• używanie obowiązującego słownictwa,
• nie zwracanie się w komunikatach bezpośrednio do użytkownika,
• stosowanie odpowiednich form w zależności od elementu interfejsu,
• dokumentowanie zmian w plikach źródłowych (przede wszystkim w nagłówkach oraz komunikatach przeznaczonych dla tłumaczy),
• sprawdzanie tłumaczeń podczas działania programów.

Większość reguł tłumaczenia pokrywa się z tymi stosowanymi przez GNOME, dlatego nie ma sensu ich tu wszystkich szczegółowo opisywać.

W praktyce proces tłumaczenia interfejsu sprowadza się do tłumaczenia krótkich i zwięzłych komunikatów, nie pozostawiając wielu możliwości interpretacji tekstu. Dzięki temu osoba nie posiadająca wielkich umiejętności językowych, może stworzyć dobre jakościowo tłumaczenie.

Inna niepisana zasada, którą należałoby przyjąć, to ta, która mówi, że to, co znajduje się w repozytorium, nie znalazło się tam bez przyczyny.

System Transifex zarządzający tłumaczeniami umożliwia swobodne modyfikowania i przesyłanie tłumaczeń do repozytoriów programów. Jest to bardzo dobre rozwiązanie wzorowane na tym z internetowej encyklopedii Wikipedia. Zrzuca ona na edytora odpowiedzialność za opublikowanie własnej pracy i za szkody jakie może w ten sposób wyrządzić. Jednocześnie zmiany są łatwe do cofnięcia przez koordynatora projektu. Mimo wszystko modyfikowanie treści już zamieszczonych, bez konkretnego powodu, nie jest dobrym pomysłem.

Oto część obowiązującego słownictwa:

• hinting - przyciąganie do siatki
• debug - diagnozowanie błędów
• subtitles - lista dialogowa
• web application - program sieciowy, usługa sieciowa
• contributor - współtwórca
• snapshot - zrzut danych
• count - ilość, nie liczba
• database statement - zapytanie bazy danych
• backend - moduł obsługi
• hardlink - dowiązanie trwałe
• developer - twórca
• PPID - identyfikator nadrzędnego procesu
• tab - tabulator
• execute - uruchomić program, wykonać polecenie
• dockapp - aplet doku
• verify - potwierdzać
• decoration - obramowanie w odniesieniu do okna
• focus - uaktywniać
• bits per sample - rozdzielczość bitowa (dźwięku)
• support - obsługa, nie wsparcie
• acceleration - wspomaganie sprzętowe
• refresh - wczytywać ponownie, nie ładować
• operation - działanie
• tweak - usprawnienie
• desktop file - plik aktywatora, w odniesieniu do plików z rozszerzeniem .desktop
• overview - podsumowanie
• eject - odłączać napęd, urządzenie lub wysuwać w kontekście nośnika
• framework - platforma programistyczna
• permalink - odnośnik bezpośredni
• compose key - klawisz składania znaków
• race condition - zjawisko hazardu
• set - ustalać, nie ustawiać
• bug - błąd, usterka
• hook - skrypt zaczepu, w odniesieniu do systemów kontroli wersji
• fix - poprawka, naprawa błędu
• development release - wydanie testowe
• switcher - przełącznik okien (działanie klawiszy Alt+Tab)
• mainanance release - wydanie utrzymujące
• double-check - ostateczne sprawdzenie
• dock (to) - utwierdzać
• localization - regionalizacja

• Słownik Referencyjny Wolnego Oprogramowania (obowiązujące słownictwo)
• Reguły tłumaczeń GNOME
• Wytyczne tłumaczenia GNOME
• Poprawna interpunkcja w Internecie
• Poradnik dla tłumaczy wolnego oprogramowania
• Słowniki informatyczne IDG.pl
• Baza wyrażeń projektów Open Source
• Wolnodostępny słownik synonimów

— Piotr Sokół 2012/12/25 14:32