Jako, że przyjęliśmy Europę w poczet krajów słowiańskich, coraz większą popularnością cieszą się witryny wielojęzyczne. Wiąże się z tym kilka problemów, które dobrze jest rozwiązać już na etapie planowania i projektowania, gdyż późniejsze radzenie sobie z nimi rodzi coraz więcej kłopotów.
Pierwsza sprawa to domyślna wersja językowa - wielu ludzi zastanawia się, czy stronę domyślnie wyświetlać po polsku, gdyż większość odbiorców operuje tym właśnie językiem, czy może po angielsku, by obcokrajowcy nie uciekli na widok krzaczków i szlaczków. Odpowiedź jest prosta - należy skorzystać z mechanizmów negocjacji zawartości dostarczanych przez sam protokół HTTP. Przeglądarka wraz z żądaniem wysłania dokumentu podaje również listę języków i stopień ich preferowania (parametr q
, podawany w skali od 0 do 1). Różne przeglądarki zachowują się różnie - niektóre nie podają listy preferencji wcale, inne nie definiują stopnia preferowania danego języka lub jego odmiany (bo en jest czym innym niż en-US, o czym za chwilę). Standard mówi, że jeśli nie jest używana skala preferencji, to obowiązująca jest kolejność, w jakiej języki zostały podane - od najważniejszego, do najmniej ważnego. Podobnie jest, jeśli kilka języków posiada taki sam współczynnik q
.
Przed wybraniem wersji językowej należy więc przesortować języki według ich zadeklarowanego stopnia preferowania (nie jest określona kolejność, w jakiej przeglądarki wysyłają listę języków, więc te o najniższym współczynniku preferencji mogą pojawić się równie dobrze na początku, w środku, jak i na końcu listy). Następnie iterując po elementach listy należy sprawdzić, czy nasz serwis oferuje daną wersję i - jeśli tak, wysłać ją do przeglądarki i przerwać dalsze testy. Specjalna uwaga dotyczy języków o q
równym 0 - zerowy współczynnik q
oznacza, że internauta pod żadnym pozorem nie życzy sobie oglądać stron w danym języku. Druga uwaga jest na temat odmian języka - jeśli agent wysłał sam identyfikator języka, bez podtypu, to jako pasującą uznaje się każdą odmianę danego języka (na przykład en pasuje tak do en-us, jak do en-gb, jeśli akurat te dwie odmiany oferujemy) - zasada ta nie ma zastosowania w drugą stronę, jeśli internauta domaga się konkretnej odmiany języka, to jako pasującą uznaje się tylko tę jedną konkretną.
Co jeśli żadna z oferowanych przez nas wersji nie pasuje do listy wysłanej w nagłówkach przez agenta? Powinniśmy wybrać ten język, którego będzie używać największa grupa naszych odwiedzających. Oczywiście, dla niektórych (na przykład tych z nieprawidłowo skonfigurowanymi przeglądarkami) będzie to błędny wybór, jednak tutaj znajduje zastosowanie inny mechanizm - przełączanie języków w locie.
Z przełączaniem w locie (za pomocą linków na stronie) wiąże się najwięcej problemów. Oczywiście metoda ta musi mieć pierwszeństwo przed negocjacją języka (wyobraźmy sobie Polaka, który ogląda nasz serwis za pośrednictwem komputera w niemieckiej kafejce i jego frustrację, kiedy okazuje się, że sklep, który ma pod domem, uparcie uszczęśliwia go stroną w języku obcym). Najpopularniejszą metodą jest zastosowanie ciasteczek i zapisywanie w nich tłumaczenia, jak jednak zmienić wersję językową? Część rynku zaskarbiły sobie szkaradne ikonki z flagami państw, choć same tworzą więcej problemów niż rozwiązują.
Ikona flagi z definicji przywiązana jest do konkretnego kraju (lub regionu, jak nadużywana powszechnie ikona Zjednoczonego Królestwa, mylnie nazywana flagą Anglii). Problem polega na tym, że języki do krajów przywiązane nie są, stąd frustracja sporej części mieszkańców Kanady, którzy nawykli już do klikania ikonki symbolizującej małe państwo żabojadów, o którym słyszeli kiedyś, że leży na drugim końcu świata. Nie wszystkie kraje darzą się sympatią, a konieczność klikania flagi sąsiada
kłóci się u niektórych z odczuciami patriotycznymi. Dlatego właśnie najlepszym rozwiązaniem jest użycie linków tekstowych. Co na nich napisać? Nazwę danego języka w danym języku (chyba, że cieszy cię wizja odwiedzenia strony międzynarodowej korporacji z siedzibą w RPA i poszukiwanie angielskiej wersji pośród dwudziestu linków na oko wyglądających jak jedno z afrykańskich narzeczy. Jedno jest pewne, każdy zna nazwę własnego języka, choć nie każdy musi znać jej wszystkie tłumaczenia.
Kolejna rzecz to sam mechanizm przełączania wersji - popularna metoda polega na zapisaniu ciasteczka i przerzuceniu agenta na tę samą stronę, która w zależności od zawartości ciasteczka wyświetli się w jednym bądź drugim języku. O ile metoda ta działa dla żywych odwiedzających, o tyle nie sprawdza się w przypadku robotów i wyszukiwarek. Nieraz już zdarzało nam się poprawiać serwisy, których klienci skarżyli się, że Google zaindeksował trzy czwarte podstron po arabsku
. Najlepiej, gdyby każdy dokument posiadał unikalny URI - to zapewni pełne indeksowanie zawartości dla każdego z języków i zaowocuje znacznie lepszą pozycją w wynikach wyszukiwania.
Oprócz problemów czysto technicznych, istnieje jeszcze cała masa problemów logicznych. Są to między innymi:
- format wyświetlania dat (zależy to od kraju i niezależnie od wybranego formatu, część ludzi będzie się zastanawiać, czy chodzi o pierwszego lutego, czy drugiego stycznia)
- sposób podawania godzin (konieczne jest wybranie i podanie strefy czasowej)
- dostosowanie formularzy (na zachodzie modne jest pytanie o tytuł, z jakim należy się do klienta zwracać - niestety, tytuły takie nie funkcjonują we wszystkich kręgach kultorowych, a tam gdzie działają, ich liczba jest różna; amerykanie często popełniają błąd prosząc o
zipcode
w angielskiej wersji serwisów, podczas gdy reszta świata używa kodów pocztowych)
Problemy te jednak znacznie odbiegają od głównej treści notki, więc jeśli będę o nich pisał szerzej, to zdecydowanie przy innej okazji.
Na jakie konto przelewać równowartość piw, żeby takie wpisy się tu pojawiały częściej? ;)
Powinienem wprowadzić płatne wpisy na wyższych poziomach? :D
Format wyświetlania dat i podawania godzin określa norma ISO 8601, czyli będzie to wyświetlane np. tak:
2005-09-29 20:45+01:00
Adi:
A znajdziesz klienta, który się na to zgodzi?
A czemu miałby się nie zgodzić? Bo "egzotycznie" wygląda?
Adi:
Bo w życiu nie widział tak zapisanego czasu. Prawdopodobnie podobnie jak większość odwiedzających serwis.
A gdyby dać linki (w poszczególnych językach) do opisania sposobu zapisywania w ten sposób czasu? Zresztą poza tym plusem i tym co jest za nim idzie się łatwo domyśleć, o co chodzi…
Adi: instancja z którą musiałbyś to omówić byłaby albo durnym szefem firmy, albo durnym przedstawicielem firmy, z których żaden nie zrozumie po co to i nie będzie tego chciał. A żaden użytkownik nie wpadnie na tak debilny pomysł, jak szukanie na stronie opisu formatu daty…
No to faktycznie jest problem, ale uważam, że najlepiej jednak stosować ten sposób zapisu daty… Zresztą jakie macie alternatywy?
czemu nie
czw wrz 22 21:29:44 CEST 2005
albo
1127417384 :D
> czemu nie
> czw wrz 22 21:29:44 CEST 2005
A dla angielskojęzycznych:
Thu Sept 22 21:29:44 CEST 2005? ;)
> albo
> 1127417384 :D
Rzeczywiście, bardziej zrozumiałe :D
Patrys: Format podany przez Adiego jest bardzo naturalny i stosowany choćby w Polsce (z wyjątkiem, oczywiście, ostatniego członu +01:00; także zamiast znaku - częściej korzystamy z kropki). I sadze, ze prawie wszyscy zrozumieja "2005-10-15 07:48" ;) To raz.
Fajnie piszesz, ale dodalbym jeszcze przynajmniej wzmianke o dwoch waznych problemach w robieniu stron wielojezycznych:
- zazwyczaj serwis jest dostepny w calosci w co najmniej jednym jezyku, i w co najmniej jednym jezyku tylko jego czesc jest dostepna. Mozemy zalozyc, ze serwis jest drzewem, ktorego kazdy wezel ma jedna lub wiecej wersji jezykowych. Problem polega na tym, ze gdy robie odnosnik ze strony A do strony B w wersji polskiej, wiem, ze strona B istnieje (gdy polska wersja jest ta glowna), ale jednoczesnie ten sam odnosnik juz nie dziala np. dla wersji angielskiej, bo o ile mam A po angielsku, o tyle B po angielsku juz nie ma. Oczywiscie fajnie byloby miec mechanizm, w ktorym wstawiam "link_do('A')", i ktory w zaleznosci od aktualnej wersji jezykowej zrobi albo link do A w tej wersji jezykowej, albo - jesli takiej wersji A nie ma - zrobi link do wersji domyslnej. (Taki wlasnie mechanizm kiedys napisalem, i troche uproscil prace nad sama zawartoscia serwisu.) Oczywiscie trzeba wowczas jakos oznaczyc link prowadzacy do innej wersji jezykowej
- napisales mniej-wiecej, ze standardem przy przelaczaniu jezyka jest wyswietlenie tej samej strony w innej wersji jezykowej po kliknieciu w odnosnik np. "english". Jesli to miales na mysli, to nie moge sie zgodzic. To nie jest standard, choc byc nim powinien. Znakomita wiekszosc stron, z ktorymi mialem do czynienia dawno temu i ktore ogladam dzisiaj ma statyczny link do innej wersji jezykowej prowadzacy do strony glownej. I tyle. Jesli ktos ma URL-e zawierajace fragment okreslajacy jezyk, to jest szczesliwy i powinno mu sie udac zrobic latwo przelacznik jezykow zachowujacy strone, na ktorej user wlasnie jest. (Dodatkowo, znow, jesli nie ma wersji jezykowej danej strony, albo nazwe tej wersji trzeba rozszerzyc o informacje, ze prowadzi do strony glownej, albo ukryc - kolejna trudnosc, jesli chcemy robic to co najmniej polautomatycznie,a nie recznie na kazdej podstronie… zwlaszcza jesli serwis tlumaczony jest z opoznieniem)
Witam,
Chetnie poczytalbym jeszcze o kodowaniu roznych wersji jezykowych. Zaletach i wadach utf.
Pozdrawiam.
Wady UTF? Zwiększona (względem kodowań jednobajtowych) objętość pliku. Więcej grzechów nie pamiętam ;).
Tomash: jeszcze różna długość różnych znaków — utrudnia operacje na tekście. Ale to problem programistów, nie użytkownika.
Elsindel:
Kwestia, co przyjmie się za standardy - ja mówię, co uważam za standard z punktu widzenia usability, nie co 90% stron w sieci uznało za normę - inaczej używałbym FrontPage i HTML 3.0.
Słuszna uwaga odnośnie brakujących tłumaczeń lub nieco odmiennej konstrukcji wersji językowych, to często jest problemem, powinienem o tym wspomnieć, ale wyleciało mi to zupełnie z głowy.
Co do formatu daty, to w zależności od projektu stosuję "2005-09-23 12:00 CET" albo "23. września 2005, 12:00 (CET)".
Luki:
Używamy już tylko Unicode (z wyjątkiem spadku po poprzednich webmasterach, gdzie nadal króluje Latin2).
Jajcus:
W praktyce każdy język server-side ma dedykowane funkcje do obsługi Unicode, więc to raczej nie problem.
Problem jest za to z niektórymi serwerami MySQL, często po przeniesieniu serwisu okazuje się, że baza pracuje domyślnie w jakimś egzotycznym kodowaniu (tyczy się głównie starszych wersji MySQL i dziwnych firm hostingowych - od wersji 4.1 poprawnie działa zapytanie "SET NAMES 'utf8';").
Niestety, MySQL sux. Nawet po SET NAMES się czasem cuda dzieją, stuprocentowo pewny sposób to rekompilacja serwera ze wsparciem *tylko* dla UTF, ale to jak się ma własny…
Poza tym, z UTF8 problemów raczej nie ma. A w każdym razie, mniej niż z robieniem strony na wielu kodowaniach.
Nie "MySQL sux", tylko niektórzy admini robią cyrk z konfiguracją. Od wersji bodaj 4.1 "SET NAMES" działa niezależnie od tego, jakie cuda się wpisze w plikach .conf dla danego klastra i usługi.
Używam MySQL z pełnym wsparciem dla całej listy kodowań i nie mam (i nigdy nie miałem) problemów. Problemy pojawiają się na cudzych maszynach (np. klient zażyczy sobie hosting w innej firmie).
Do czego jest Wam potrzebne wsparcie kodowan w MySQL? (pytam serio, chcialbym sie dowiedziec) Jedyne, co mi przychodzi do glowy w tej chwili, to poprawny full text search.
Elsindel: no cóż… niektórzy lubią mieć różne dane przedstawione w kolejności alfabetycznej… ;-)
Dokładnie, chodzi o prolemy z sortowaniem (dane zapisane jako kodowanie o stałej długości znaku - jeden oktet - sortują się jak śmieci) i indeksy do zapytań fulltext (MATCH … AGAINST …).
Poza tym ciężko się diagnozuje usterki z kodowaniem na stronie, kiedy phpMyAdmin pokazuje chińskie diakrytyki.
To znaczy, ze przy ustawionym blednym kodowaniu ś, ą, ż, ź, ł itd. znajda sie po prostu nie tam, gdzie powinny? (istotnie, w roznych miejscach widzialem taki blad; no i w roznych jezykach moze on sie roznie objawic) Bo caly alfabet lacinski bedzie raczej poprawnie sortowany. :)
Ok, dzieki za wyjasnienie.
Jak usuniecie polskie znaki to nie bedziecie miec zadnych juz problemow z kodowaniem ;)
Kodowanie to pryszcz… nie ma to jak zapuszczone bazy produkcyjne chodzace od 10 lat na archaicznym DB2/400 ;). Ajuto!
Czesc panoowie. Prowadze bloga http://kijow.e-stoisko.com
W Wiekszosci swojej na lacine i z polskimi znakami, ale czasem trafia sie cyrylica, wiec orocz UTF8 neima lepszego wyjscia. Naradcie tylko dobry redaktor tekstowy, ktory sprawnie pisze polski litery.
Oleksa:
Najwygodniej chyba zmienić chwilowo mapowanie klawiatury na "polski programisty" i używać normalnie alt+litera. Z tym powinien sobie poradzić każdy edytor wspierający UTF8.