METODY I NARZĘDZIA WSPOMAGAJĄCE TWORZENIE WIELOJĘZYCZNYCH INTERFEJSÓW W APLIKACJACH INTERNETOWYCH Anna Kempa, Tomasz Staś Wprowadzenie Wraz z rozszerzaniem się zasięgu Internetu oraz globalnej współpracy rośnie znaczenie opracowywania wersji narodowych w aplikacjach internetowych. Aspekt wielonarodowy w aplikacjach internetowych rozpatrywany jest na dwóch płaszczyznach internacjonalizacji oraz lokalizacji. Lokalizacja (przyjęty skrót l10n) jest związana z adaptacją aplikacji do specyfiki językowej, funkcjonalnej oraz kulturowej [Filip05]. Często utożsamia się ją z tłumaczeniem interfejsu użytkownika i dokumentacji, ale lokalizacja jest bardziej złożonym problemem, zawierającym takie elementy jak format daty, czasu, waluty, liczb, itp. Internacjonalizacja (i18n) jest podejściem do projektowania i rozwijania aplikacji, które umożliwia łatwą lokalizację dla odbiorców, różniących się co do języka i kultury [W3C07]. Internacjonalizacja obejmuje projektowanie aplikacji w sposób usuwający bariery lokalizacji, min. poprzez [W3C06]: zastosowanie zestawu znaków i standardów kodowania znaków, wspieranie właściwości, które mogą być zastosowane przed lokalizacją (np. dodanie znaczników do identyfikacji języka), zapewnienie kodu, który wspiera lokalne, językowe lub kulturowe preferencje,
separowanie elementów możliwych do zlokalizowania od pozostałego kodu źródłowego. Internacjonalizacja stanowi fundamentalny krok w procesie projektowania aplikacji, umożliwiający łatwiejsze przeprowadzenie lokalizacji. W artykule przedstawiono metody i narzędzia, wspierające internacjonalizację oraz lokalizację aplikacji internetowych ze szczególnym uwzględnieniem zbioru narzędzi Gettext, wykorzystanego przez autorów podczas realizacji aspektu językowego w międzynarodowym projekcie obejmującym tworzenie gry biznesowej e-musicbusinessgame. Głównym motywem wyboru narzędzi w tworzonej aplikacji było dostarczenie mechanizmów lokalizacji, które nie są kłopotliwe dla programistów ani dla osób realizujących tłumaczenia. Metody i narzędzia wspierające internacjonalizację i lokalizację Prace nad przygotowaniem aplikacji do lokalizacji należy zacząć przed jej powstaniem. Tworzenie aplikacji wiąże się z pisaniem komunikatów, nazw opcji i innych informacji przeznaczonych dla użytkownika. Pisanie jednej wersji językowej z odkładaniem na później zatroskania się o pozostałe może bardzo utrudnić i przedłużyć proces tłumaczenia. Z drugiej strony nie można osób tworzących aplikację nadmiernie obciążać zadaniami związanymi z internacjonalizacją, należy szukać rozwiązań, które nie będą zbyt uciążliwe dla twórców oprogramowania, a jednocześnie będą wygodne dla osób zajmujących się lokalizacją. Popularnym rozwiązaniem jest tworzenie plików zasobów, które zawierają wszystkie teksty i dane (lub/i pliki graficzne) przeznaczone do lokalizacji. Przykładowo w ASP. ET pliki zasobów to pliki XML, w
których rekordy składają się z klucza, wyrażenia i opisu. Klucz wykorzystywany jest do odwoływania się do zlokalizowanego wyrażenia. Pakiet Visual Studio jest wyposażony w narzędzie ułatwiające edycję takich plików. Tworzenie wielojęzycznej aplikacji internetowej w ASP.NET przebiega w kilku etapach [MSDN07]: tworzona jest wersja, w której wszystkie komunikaty pisane są w języku domyślnym, teksty mające podlegać tłumaczeniu umieszcza się wewnątrz kontrolek, generuje się (w opcji Generate Local Resource) podstawowy plik zasobów, dla każdej wersji językowej należy utworzyć kopię pliku zasobów, przetłumaczyć wartości na odpowiedni język i zmienić nazwę pliku. Jednym z pierwszych języków, który projektowano z myślą o umożliwieniu internacjonalizacji - jest język Java. Od samego początku dysponował podstawową własnością w tym względzie wykorzystywał do reprezentacji znaków Unicode. W Javie poprzez obiekty klasy Locale tworzy się lokalizatory opisujące język, lokalizację i opcjonalne warianty [HoCo03]. Java także korzysta z zasobów do obsługi aspektów językowych, jednak zasoby w Javie różnią się od zasobów wykorzystywanych przez programy systemu Windows. Program wykonywalny systemu Windows przechowuje zasoby w sekcji oddzielonej od kodu programu. Platforma Java nie dysponuje mechanizmem przechowywania zasobów w osobnych plikach tekstowych [HoCo03]. Wszystkie zasoby muszą zostać umieszczone w klasie jako składowe, niemniej zastosowanie specjalnych plików własności (ang. properties) pozwala niejako na oddzielenie tłumaczonych tekstów od reszty kodu źródłowego. Zastosowany w Javie pakiet zasobów przechowuje zbiór zlokalizowanych zasobów odpowiednich dla danej lokalizacji. Wszystkie pakiety zasobów to rozszerzenia
java.util.resourcebundle. Pracę z obiektem ResourceBundle należy zacząć od utworzenia obiektu przy użyciu metody statycznej getbundle z nazwą pliku properties jako parametrem. Plik własności powinien zawierać znaki US-ASCII w formie [HuCr02]: identyfikator1=wartość1. Programista musi zaprojektować identyfikatory dla wszystkich komunikatów, tłumacz natomiast musi pracować jednocześnie z plikiem properties zawierającym oryginalne komunikaty jak i nowym plikiem zawierającym tłumaczenia. Istnieją narzędzia wspomagające edycję plików własności (m.in. program propedit). W środowisku UNIX najbardziej powszechnym rozwiązaniem jest wykorzystanie opracowanego w 1995 roku projektu Gettext. Gettext to zbiór narzędzi GNU opracowanych w celu tłumaczenia tekstów. Działanie Gettext polega na wyodrębnieniu tekstów z plików źródłowych i zapisaniu ich do katalogów komunikatów. Pliki komunikatów zapisywane są w standardowej strukturze katalogów. W czasie działania aplikacja poszukuje w plikach przetłumaczonych tekstów, jeśli ich nie znajduje używany jest ciąg oryginalny. Przykładowy schemat lokalizacji przy użyciu Gettext-a [HaMG07]: 1. Pobranie tekstów z kodu źródłowego do pliku z komunikatami (pliki te mają rozszerzenie.po), 2. Edycja pliku.po z komunikatami w celu przetłumaczenia komunikatów na dany język (każdy język ma osobny plik.po), 3. Przetłumaczony plik.po zostaje konwertowany do postaci binarnej (plik.mo). Większość języków programowania posiada obsługę tekstów pozwalającą na wykorzystanie projektu Gettext [GNU06]. Na przykładzie języka
PHP zostaną pokazane sposoby opisu komunikatów kodzie źródłowym, umożliwiające pobranie tekstów (realizację punktu 1) i jednocześnie podmianę komunikatów. Poniżej przedstawiono przykładowy kod skryptu PHP wywołujący stosowne funkcje umożliwiające lokalizację: // kod skryptu, plik kod.php <?php $language_code = pl_pl ; putenv( LANG=$language_code ); setlocale(lc_all, $language_code); $domain = komunikaty ; bindtextdomain($domain,./locale ); textdomain($domain);?> echo gettext( First message to translate ); echo gettext ( Second message to translate ); Prawidłowo ustawiona domena oraz obecność plików z tłumaczeniami w odpowiednich katalogach umożliwia funkcji gettext() odnalezienie tekstu w oczekiwanym języku i podmianę wartości. W technologii Gettext kluczem komunikatu jest jego treść w domyślnym języku (dla porównania w Javie są to specjalne identyfikatory). W ocenie autorów rozwiązanie z treścią komunikatów ma istotną zaletę programista ma komfort pisania przypominający tworzenie wersji jednojęzykowej. Komunikaty stanowią jednocześnie rodzaj komentowania kodu (wydzielenie ich wszystkich na zewnątrz i zastąpienie identyfikatorami czyni kod źródłowy trudniejszym do analizy i konserwacji). Jak wskazano wyżej, pierwszym krokiem w procesie lokalizacji jest pobranie komunikatów z plików źródłowych, dokonuje tego program xgettext. Program ten pobiera m.in. jako parametr nazwę pliku.po oraz miejsce, gdzie znajdują się skrypty PHP, jakie należy przeszukać. Po wy-
konaniu programu powstaje plik.po, który należy uzupełnić tłumaczeniami, przykładowy fragment: #: kod.php:10 msgid First message to translate msgstr Pierwszy komunikat do tłumaczenia. Następnym krokiem jest wygenerowanie pliku w formacie binarnym (plik.mo) dokonuje tego program msgfmt. Utworzony plik.mo należy umiejscowić w strukturze katalogów locale. Przykładowa struktura ścieżki dla polskiego języka: /locale/pl_pl/lc_messages/smarty.mo. Początkowo, rozszerzenie Gettext nie rozwiązywało problemu wielości form gramatycznych. Przykładowo komunikat Deleted %d files na język polski można przetłumaczyć w zależności od wartości parametru na Skasowano (1) plik, Skasowano (2) pliki lub Skasowano (5) plików. Obecnie istnieje funkcja, przy pomocy której można rozwiązać ten problem, np.: printf(ngettext("%d file deleted.\n","%d files deleted.\n", delnum),delnum). Użycie funkcji ngettext() pozwala uwzględnić wielość form gramatycznych. Plik.po będzie posiadał wówczas dla każdego języka tyle form, ile może w nim wystąpić, np.: msgid "%d file deleted" msgstr0 "Skasowano %d plik" msgstr1 "Skasowano %d pliki" msgstr2 "Skasowano %d plików" #Algorytm przyznawania identyfikatorów dla form liczby mnogiej i pojedynczej jest określany dla każdego języka. Dla języka polskiego wygląda on następująco: #Plural-Forms: nplurals=3; plural=n==1? 0 : n%10>=2 && n%10<=4 && (n%100<10 n%100>=20)? 1 : 2;
Obecnie tworzy się aplikacje internetowe oparte o architekturę oddzielającą warstwę prezentacji od logiki aplikacji. Wykorzystuje się w tym celu szablony, w PHP popularne są szablony Smarty zawierające znaczniki HTML a także elementy logiki (związanej z prezentacją danych). Szablony także zawierają teksty, które należy ująć w procesie tłumaczenia. W szablonach nie można użyć funkcji gettext(), wykorzystuje się tzw. funkcję blokową o nazwie t. Fragmenty tekstów przeznaczone do tłumaczenia oznacza się funkcją blokową, np.: {t}third message to translate{/}. Użycie funkcji blokowej t wymaga zainstalowania dodatkowej wtyczki Smarty (block.t.php). Przy użyciu narzędzia tsmarty2c.php generuje się na podstawie szablonów kod języka C, w którym występuje funkcja gettext z komunikatem do przetłumaczenia. Dalsze działanie przebiega tak samo, jak w przypadku tekstów w kodzie PHP tworzy się plik.po, tłumaczy się teksty oraz ostatecznie generuje się plik.mo. Dla usprawnienia etapu tłumaczenia (edycji plików.po) wykorzystuje się dodatkowe narzędzia, m.in. program KBabel, który nie tylko jest edytorem, ale służy także do zarządzania plikami *.po i *.mo (scalanie, porównywanie, ułatwia aktualizację itp.). do pobrania ze strony http://kbabel.kde.org. Inny program to poedit - obsługuje UTF-8, ma sprawdzanie pisowni. Program jest dostępny na systemy Linux, ale także Mac OS i Windows. Do pobrania na stronie: http://www.poedit.net. Realizacja procesu tłumaczenia aplikacji na przykładzie gry internetowej W Katedrze Inżynierii Wiedzy Akademii Ekonomicznej realizowany jest międzynarodowy projekt badawczy, którego głównym celem jest
powstanie internetowej gry symulującej rynek muzyczny (emusicbusinessgame). Fakt, iż projekt powstaje przy współpracy kilku ośrodków akademickich zlokalizowanych w różnych częściach Europy wymusił konieczność tłumaczenia interfejsu aplikacji na języki grecki, francuski oraz polski. Przyjęto, że program powstanie w języku angielskim i przy użyciu odpowiednich narzędzi zostanie później przetłumaczony na pozostałe języki. Na początku prac związanych z internacjonalizacją wybrano sposób kodowania tekstu (UTF-8), który umożliwia zapisywanie tekstów w czterech wykorzystywanych językach. Tworzona aplikacja internetowa powstała w języku PHP, dlatego też na potrzeby lokalizacji interfejsu zdecydowano się wykorzystać pakiet Gettext, uzupełniony o dodatkowe mechanizmy..mo polski Tabela tłumaczeń.mo grecki Kod źródłowy aplikacji Plik.po bez tłumaczeń Pliki.po z tłumaczeniami.mo francuski Tł. j. polskiego Tł. j. greckiego Formularz internetowy do tłumaczeń Tł. j. francuskiego Rys1. Przebieg procesu tłumaczenia aplikacji e-musicbusinessgame Źródło: Opracowanie własne Wszystkie kroki niezbędne do lokalizacji interfejsu użytkownika zostały przedstawione na Rys1. Przy pomocy programu xgettext wyodrębniono automatycznie z plików kodu źródłowego aplikacji wszystkie teksty będące argumentami funkcji gettext(). Program xgettext tworzy plik.po, który jest plikiem tekstowym, na potrzeby gry internetowej został stwo-
rzony program zasilający na podstawie tego pliku tabelę tekstów do tłumaczeń. Ponieważ proces tłumaczenia przebiega równolegle z rozwijaniem aplikacji, dlatego uzupełnianie bazy tłumaczeń realizowane jest cyklicznie. Obecnie utworzona tabela zawiera kilkaset rekordów-tekstów w języku angielskim, obejmujących wykorzystywane w aplikacji etykiety (opisy, komunikaty, informacje o błędach, itp.). Dla potrzeb trzech grup tłumaczy utworzona została aplikacja internetowa umożliwiająca wpisywanie tłumaczeń w języku francuskim, greckim lub polskim. Umożliwiono tym samym niezależne tłumaczenie realizowane w sposób intuicyjny, nie wymagający znajomości zagadnień informatycznych. Na podstawie danych zawartych w tabeli tłumaczeń generowane są ponownie pliki.po (po jednym pliku dla każdego języka), o identycznej strukturze jak tworzone przez program xgettext. Pliki te zawierają translacje tekstów uzupełnione przez tłumaczy. Ostatnim etapem procesu tłumaczenia aplikacji internetowej jest zautomatyzowane tworzenie plików.mo (za pomocą programu msgfmt) oraz umieszczanie tych plików w odpowiedniej strukturze katalogów zgodnie z wymogami mechanizmu Gettext. W efekcie podjętych działań powstał wydzielony z aplikacji internetowej moduł tłumaczenia na języki grecki, francuski i polski, który na bieżąco pozwala uwzględniać pojawiające się w aplikacji zmiany i nowe teksty. Obsługa modułu ogranicza się jedynie do wypełniania na stronie internetowej formularza, który umożliwia tłumaczenie tekstu oryginalnego, zapisanego w języku angielskim.
Przyjęte rozwiązanie ma wiele zalet. Przede wszystkim jest uniwersalne i nie zależy ani od języków, na które miałaby być tłumaczona aplikacja internetowa, ani od ich liczby. Uzupełnienie tłumaczenia aplikacji o nowy język wymaga jedynie wprowadzenia drobnych zmian (np. rozszerzenia tabeli tłumaczeń o dodatkową kolumnę i umożliwienie jej edycji na stronie internetowej, uzupełnienia skryptów generujących pliki.po oraz.mo). Rys2. Fragment interfejsu aplikacji w języku oryginalnym i po przetłumaczeniu na język polski. Źródło: Opracowanie własne Istnieją jednak pewne zagrożenia i problemy związane z mechanizmem tłumaczenia aplikacji internetowej. Jednym z problemów, jaki napotkali autorzy wynikał z różnej długości tekstów odpowiadających temu samem komunikatowi. Widoczne jest to na Rys2. W pewnym stopniu problem rozwiązuje sam język HTML i przeglądarka internetowa, która próbuje dostosowywać się do długości wyświetlanych łańcuchów znakowych. W wielu przypadkach to wspomaganie ze strony przeglądarki internetowej wystarczało, jednak ze względu na
sztywno ograniczone wymiary okna zawierającego interfejs gry pojawiły się tłumaczenia, których wykorzystanie burzyło interfejs całej aplikacji. W takich, rzadkich, sytuacjach konieczna jest współpraca z tłumaczami w kierunku zmiany zaproponowanych przez nich tekstów. Inną niedogodnością, która pojawiła się w procesie tłumaczenia aplikacji był czas pomiędzy wprowadzeniem tłumaczenia nowego tekstu, a wyświetlaniem (wykorzystaniem) tego tekstu w interfejsie aplikacji. Ze względu na sposób powstawania i rozwoju aplikacji, autorzy przyjęli, że program pobierający nowe teksty z kodu źródłowego wstawiając je do tabeli tłumaczeń, będzie jednocześnie tworzył pliki.mo na podstawie zapisanych już translacji. Program ten wykonywany był automatycznie o godzinie 2 w nocy. Tak więc osoby wprowadzające nowe tłumaczenia, mogły widzieć efekt swojej pracy maksymalnie po 24 godzinach. Autorzy dostrzegają następujące możliwości wyeliminowania tej niedogodności: możliwe jest zwiększenie częstotliwości uruchamiania programu tłumaczącego, to jednak zwiększy obciążenie serwera, można również udostępnić tłumaczom na stronie internetowej przycisk uruchamiający generowanie plików.mo, tak aby po wprowadzeniu zmian, mogli oni zainicjować proces przygotowywania plików tłumaczeń i od razu widzieć efekty swojej pracy. Kolejnym problemem w procesie tłumaczenia było pojawienie się w oryginalnych tekstach znaków interpunkcyjnych. Ponieważ aplikacja rozwijana była przez kilka osób istniała możliwość, że będą one odmiennie tworzyć komunikaty. I tak dla przykładu jeden z programistów zdefiniował etykietę LOGIN, zaś inny uzupełnił ją o znak dwukropka LO- GIN:. Dla programu pobierającego teksty do tłumaczeń te ciągi znaków
są różne, dlatego oba pojawiłyby się w tabeli tłumaczeń i wymagałyby uzupełnienia o odpowiedniki w innych językach. Okazało się jednak, że zjawisko to występowało w bardzo niewielu przypadkach i mogło być błyskawicznie identyfikowane oraz poprawiane. Program xgettext w generowanym pliku.po wskazuje dokładną lokalizację tłumaczonego ciągu znaków (podaje nazwę pliku i numer wiersza kodu źródłowego). Wystarczyło zatem dodatkowe znaki (takie jak dwukropki, wykrzykniki, itp.) wyodrębnić z tłumaczonego tekstu oraz połączyć z nim wykorzystując operację konkatenacji. W omawianym przykładnie gry internetowej pojawienie się dodatkowych znaków dotyczyło zaledwie ok. 3% wszystkich tłumaczeń. Jeszcze inny problem, z którym spotkali się autorzy modułu tłumaczenia aplikacji było pojawianie się błędów tłumaczeń wynikających z istnienia homonimów w języku oryginalnym. Przykładem może być słowo LOGIN które raz oznacza nazwę zalogowanego użytkownika, innym razem, np. umieszczone na przycisku formularza, zachęca do zalogowania się do gry. Jednokrotne tłumaczenie będzie w tej sytuacji niepoprawne, gdyż wymaga uwzględnienia kontekstu, w jakim pojawia się sformułowanie. Tego typu problemy identyfikowane były na etapie testowania gry, a ich rozwiązanie wymagało współpracy programistów i tłumaczy. Zakończenie Internacjonalizacja i lokalizacja to złożone zagadnienia, w artykule skupiono się na aspektach tłumaczeń tekstu. Zaproponowany mechanizm tworzenia aplikacji wielojęzykowej wydaje się dobrze sprawdzać w tworzonej grze internetowej. Uzupełniony o dodatkowe programy automaty-
zujące pewne działania i ułatwiające wprowadzanie tłumaczeń umożliwił współpracę nad aplikacją kilku, różnojęzykowym zespołom, które w tym samym czasie mogły lokalizować interfejs aplikacji internetowej. Działanie to nie wymagało od tłumaczy żadnych dodatkowych umiejętności informatycznych. Przyjęte narzędzia pozwoliły także na niekłopotliwe kodowanie aplikacji przez programistów. Cel, który postawili przed sobą autorzy został więc zrealizowany. Wykorzystane podejście nie jest wolne od problemów, jednak ich rozwiązanie w większości wypadków polegać będzie na uzupełnieniu procesu tłumaczenia o dodatkowe programy, które będą eliminować w sposób zautomatyzowany zauważone problemy. Należy jednak podkreślić, że niezbędna jest także współpraca pomiędzy grupami tłumaczącymi aplikację, a osobami ją tworzącymi. Literatura [Filip05] Filipczyk B., Filipczyk G.: Aspekty językowe w tworzeniu serwisów internetowych, w: (red.) Porębska-Miąc T., Sroka H.: SWO 2005, AE Katowice 2005 [GNU06] GNU Gettext oficjalna strona projektu Gettext, 2006, http://www.gnu.org/software/gettext// [HaMG07] Hayder H., Maia J.P., Gheorghe L.: Smarty. Szablony w aplikacjach PHP, Wydawnictwo Helion, Gliwice 2007 [HoCo03] Horstmann C.S., Cornell G.: Java 2. Techniki zaawansowane, Wydawnictwo Helion, Gliwice 2003
[HuCr02] Hunter J., Crawford W.: Java Servlet. Programowanie, Wydawnictwo Helion, Gliwice 2002 [MSDN07] Globalizing and Localizing ASP.NET Web Pages (Visual Studio), 2007, http://msdn2.microsoft.com/enus/library/dfs80h33(vs.80).aspx [W3C06] W3C Internationalization (l18n) Activity, Localization vs. Internationalization 2006, http://www.w3.org/international/questions/qa-i18n.en.php [W3C07] W3C Internationalization (l18n) Activity, 2007, http://www.w3.org/international/ Mgr Anna Kempa Mgr Tomasz Staś Katedra Inżynierii Wiedzy Akademia Ekonomiczna 40-226 Katowice, ul. Bogucicka 3 Numer telefonu (fax) +48/32/2577295 e-mail: kempa@ae.katowice.pl stas@ae.katowice.pl