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:
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:
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:
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:
— Piotr Sokół 2012/12/25 14:32