Kiedy należy, a kiedy nie należy, stosować negocjację języka?
Negocjacja języka jest funkcją protokołu HTTP, która pozwala serwerowi wybrać spośród kilku wersji językowych strony w oparciu o adres
URL i informacje o preferencjach wysyłanych przez przeglądarkę (ściślej, informacje w nagłówku Accept-Language
). Jest to funkcja różna
od wyboru strony w oparciu o adres IP przeglądarki oraz od ręcznego wyboru przez użytkownika na stronie wyboru języka. Jeżeli nie ma zgodności
pomiędzy preferencjami przeglądarki a językami dostępnymi na serwerze wyświetlana jest albo strona wyboru języka lub używany jest język domyślny.
W wielu przypadkach początkowe ustawienia preferencji językowych agenta użytkownika są w porządku. Na przykład, jeżeli używasz japońskiej wersji przeglądarki, będzie ona zazwyczaj zakładać, że wolisz przeglądać strony w języku japońskim i taką informację prześle do serwera. Dominujące przeglądarki pozwalają na modyfikacje preferencji językowych. Aby uzyskać więcej informacji na ten temat zapoznaj się z FAQ Ustawianie preferencji językowych przeglądarki.
To FAQ zajmuje się odpowiedzą na pytanie kiedy należy (bądź nie należy) ustawiać negocjację języka na serwerze.
Krótka odpowiedź brzmi: zawsze.
Nieco dłuższa odpowiedź brzmi: prawie zawsze, lecz są pewne wyjątki.
Negocjacja języka nie zawsze działa zgodnie z założeniami; istnieją pewne techniki pozwalające nadrobić braki; należy także wziąć pod uwagę konsekwencję w nawigacji .
Negocjacja języka jest ewidentnie użytecznym narzędziem, jednak zanim je zaimplementujemy ważne jest zrozumienie jego ograniczeń. By je zilustrować posłużymy się przykładową witryną, www.example.be, która udostępnia swoją zawartość w językach flamandzkim, francuskim i niemieckim, posiada zaimplementowaną negocjację języka a domyślnym językiem dla wszystkich stron jest flamandzki. Nasza odwiedzająca, Sylvia, posługiwać się będzie językiem włoskiem, ale radzi sobie także z niemieckim. Może to prowadzić do kilku różnych sytuacji:
Mam nadzieję, że wszystko jest teraz jasne - negocjacja języka nie zawsze przynosi oczekiwane rezultaty.
Co więcej, negocjacja języka nie jest użyteczna kiedy strony nie są jednakowe, czyli nie mają takiej samej zawartości w różnych językach. FAQ Jednojęzyczne i wielojęzyczne witryny internetowe rzuca trochę światła na ten problem. Na szczególną uwagę zasługują sekcje "Wielojęzyczne o tej samej zawartości" oraz "Wielojęzyczne o zmienionej zawartości". Weź jednak pod uwagę, że pewien stopień adaptacji kulturowej (jak na przykład zmiana waluty) nie musi wcale czynić stron różnymi. Tak naprawdę ograniczenie negocjacji języka istnieje wtedy, kiedy witryna jest adaptowana tak, że strony w różnych językach nie są już dłużej swoimi odpowiednikami.
Pomimo swoich ograniczeń negocjacja języka jest użyteczną funkcją i pożądana jest jej implementacjach w witrynach wielojęzycznych. Należy jednak odnieść się jednak także do jej wad. Pokrótce, ważne jest zapewnić odwiedzającym środki pozwalające na obejście automatycznego wyboru języka, kiedy jest on błędny. Oznacza to umieszczenie na stronie pewnych elementów interfejsu (będziemy je tu nazywać przełącznikami języka), które będą odnośnikami do innych dostępnych języków. Przełączniki te muszą być wyraźnie widoczne i zrozumiałe dla odwiedzającego, który nie jest zaznajomiony z językiem, w którym storna jest aktualnie wyświetlana.
Nasuwa się pytanie - czy negocjacja języka i ręczne przełączniki języka powinny być implementowane na wszystkich stronach czy tylko na stornie głównej? Najlepszą odpowiedzią jest "na wszystkich stornach" z wyjątkiem tych zbiorów stron, które nie są wystarczająco równoznaczne. Negocjacja języka jest dobra ponieważ, jeśli Jaap wyśle emailem odnośnik z witryny www.example.be do Pierre'a, ten, ku swojemu zadowoleniu, otrzyma wersję francuską pomimo, iż Jaap przeczytał wersję flamandzką. Przełączniki języka muszą także być dostępne niezależnie od tego czy negocjacja została zaimplementowana czy nie. Jeżeli negocjacja jest nieobecna, Pierre będzie potrzebował przełączników, aby dostać się do francuskiej wersji strony z odnośnika Jaapa; nawet, jeśli negocjacja będzie obecna, Sylvia będzie ich potrzebować, żeby przełączyć się ręcznie na język niemiecki w sytuacjach 2 i 3 wymienionych powyżej.
Przy okazji, niektóre witryny wyświetlają specjalną stronę wyboru języka, kiedy nie ma zgodności pomiędzy preferencjami odwiedzającego a dostępnymi językami (www.example.be może wyświetlać taką stronę zamiast wybierać domyślnie język flamandzki). Ma to tę zaletę, że czyni sytuację przejrzystą i nie daje żadnemu z języków pierwszeństwa nad innymi, co może być czasami kwestią politycznie delikatną. Niestety, część witryn zawsze wyświetla tego rodzaju stronę specjalną (dla strony domowej) zamiast zaimplementować negocjację języka. Zmusza to każdego do ciągłego przechodzenia przez tą stronę nie oferując w zamian żadnych korzyści. Taki projekt źle sobie radzi z uwzględnieniem czynnika ludzkiego.
Przypuśćmy, że Sylvia odwiedza www.example.be i strona wyświetla się w języku flamandzkim (sytuacje 2 i 3). Klika wtedy na przełączniku na język niemiecki i zapoznaje się z jej zawartością już bez żadnych problemów. Jednak potem klika na odnośniku do interesującej ją strony znajdującej się w obrębie witryny. Ups, znowu flamandzki! Na szczęście przełącznik na język niemiecki wciąż jest obecny, jednak po paru takich "skrótach" rosnąca frustracja Sylvii będzie zupełnie zrozumiała. Czy www.example.be nie może zwyczajnie zapamiętać, że nie potraci czytać po flamandzku? W tym wypadku potrzebna jest odrobina konsekwencji w jasno sprecyzowanym wyborze języka.
Jest kilka sposobów, za pomocą których www.example.be może zapewnić taką konsekwencję. Wybór któregoś z nich zależny będzie od dostępnej technologii stanowiącej podłoże dla serwera oraz od wysiłku, jaki gotowi jesteśmy włożyć
Jeżeli witryna ma zaimplementowane mechanizmy sesji (korzysta na przykład z ciasteczek), wtedy uczynienie języka częścią stanu sesji jest dość prostą sprawą. Kiedy Sylvia kliknie na przełączniku na język niemiecki, informacja o tym zostanie zachowana (albo w samym ciasteczku bądź na serwerze, gdzie odpowiadać jej będzie numer sesji zapisany w ciasteczku) i od tego momentu podczas nawigacji w obrębie witryny będą się jej wyświetlać strony tylko w języku niemieckim. Taki ciasteczko można nawet uczynić stałym (chociaż wpływa to negatywnie na kwestie ochrony prywatności), także Sylvia otrzyma strony w języku niemieckim automatycznie, kiedy następnym razem powróci do www.example.be. Witryny zapewniające mechanizm logowania mogą również zapisywać preferencje językowe jako część profilu użytkownika i odpowiednio wyświetlać strony. Negocjacja języka jest wtedy stosowana tylko w przypadku użytkowników, którzy jeszcze się nie zalogowali.
Innym sposobem zmniejszenia frustracji jest uczynienie wszystkich wewnętrznych odnośników w obrębie witryny określonymi
językowo. Na niemieckiej stronie domowej odnośniki do stron położonych głębiej będą miały formę href="company/about.de.html"
(zamiast formy company/about.html
, która byłaby ogólna językowo)*. Nawigacja zostaje wtedy ograniczona do stron w języku
niemieckim do czasu, aż zostanie ręczne zmieniona za pomocą specjalnych przełączników języka. Ma to jednak swoje minusy. Jednym z nich jest fakt, że
wszystkie wewnętrzne odnośniki stają się materiałem przekładalnym, co zwiększa koszt przekładu, jak również prawdopodobieństwo popełnienia
potencjalnych błędów. Kolejnym minusem jest to, że kiedy Jaap wysyła odnośnik do Pierre'a adres URL (skopiowany z paska adresu przeglądarki) będzie
określony językowo a zatem Pierre otrzyma stronę w języku flamandzkim. Żaden z powyższych minusów nie jest jednak niczym strasznym, zatem
zastosowanie odnośników określonych językowo jest prawdopodobnie dobrym sposobem, kiedy konsekwencja nie może być zapewniona przez stan sesji lub
mechanizm profilowania.
Zauważ, że zaprezentowane tu przykładowe formy adresów URL określonych i ogólnych językowo (company/about.de.html oraz company/about.html) zależą od technologii stosowanych przez serwer do implementacji negocjacji języka. Używając Apache MultiViews zobaczylibyśmy raczej formę company/about.html.de oraz company/about.html lub też, odrzucając całkowicie rozszerzenie .html, formę company/about.de oraz company/about.
Nagłówek HTTP Accept-Language
nie jest jedynym dostępnym źródłem informacji o języku. Wszystkie przeglądarki wysyłają
również nagłówek User-Agent
określający markę przeglądarki, numer wersji oraz, w niektórych przypadkach, wersję językową. Można to
wykorzystać przy próbach odgadnięcia języka preferowanego przez użytkownika, jeśli brakuje nagłówka Accept-Language
, jednak jest to
sposób bardziej zawodny i bardziej ograniczony (udostępnia tylko jeden język) niż użycie nagłówka Accept-Language
. Zalecane jest stosowanie tylko z
wyjątkową ostrożnością..
Negocjacja języka jest tylko jednym z aspektów negocjacji zawartości HTTP. Innymi aspektami, które mogą być automatycznie negocjowane są typy mediów (tj. format - na przykład HTML, PDF lub zwykły tekst), kodowanie znaków i kodowanie transferu (szyfrowany, skompresowany, etc.). Negocjacja języka jest funkcją najbardziej użyteczną i powszechnie stosowaną..