Klucz dostępu n przeskakuje w nawigacji strony. Przejdź do początku.

Ten dokument jest tłumaczeniem. W przypadku rozbieżności i błędów aktualna wersja angielska powinna być uznana za autorytatywną. Pierwotne prawa autorskie należą do W3C jak wykazano poniżej.

Tłumacz: Tłumaczenia team.

s_gotoW3cHome Internacjonalizacja
 

Kiedy stosujemy negocjację języka?

Potencjalni odbiorcy: webmasters, server administrators, and anyone who wants to better understand language-based content negotiation.

Pytania

Kiedy należy, a kiedy nie należy, stosować negocjację języka?

Tło informacyjne

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.

Odpowiedź

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 .

Wady negocjacji języka

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:

  1. Przeglądarka Sylvii jest poprawnie skonfigurowana preferując jako pierwszy język włoski a następnie niemiecki. Język włoski nie jest dostępny na witrynie www.example.be, strony wyświetlane są po niemiecku, odwiedzająca jest w miarę zadowolona i wszystko jest w porządku. Do tego właśnie służy negocjacja języka!
  2. Sylvia jest osobą, która nie zna się na technice, nigdy nie słyszała o negocjacji języka w HTTP i nigdy nie czuła potrzeby zmian w ustawieniach przeglądarki. Przeglądarka jest w wersji włoskiej, która (prawidłowo) preferuje domyślnie język włoski. Wchodząc na www.example.be język włoski nie będzie dostępny i wyświetlony zostanie domyślny dla witryny język flamandzki pomimo, iż dostępny jest język niemiecki. Źle.
  3. Sylvia nie używa swojej własnej przeglądarki, lecz siedzi w kafejce internetowej w Moskwie. Ta przeglądarka skonfigurowana została (lub używa go domyślnie) by używać języka rosyjskiego. Zatem Sylvia znowu dostanie strony w języku flamandzkim. Źle.

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.

Nadrabianie braków

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.

Nawigacja

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.

Dodadkowe informacje

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ą..

Powiedz nam co myślisz (po angielsku).

Prenumeruj kanał RSS.

Nowe źródła

Wiadomość ze strony głównej

Twitter (Wiadomość ze strony głównej)

‎@webi18n

Warto przeczytać

Autor: François Yergeau. Tłumacz: Tłumaczenia team..

Ważny XHTML 1.0!
Ważne CSS!
Zakodowano w UTF-8!

Angielska wersja dokumentu z dnia 2004-02-26. Tłumaczenie wykonano dnia 2010-09-03 19:40 GMT

Historia zmian dokumentu qa-when-lang-neg w blogu i18n.