Content-Language

Content-Language to nagłówek wskazujący język, w jakim została napisana treść wiadomości.

Content-Language — czym jest ten element i do czego służy

Content-Language to oznaczenie języka używanego w treści dokumentu, wiadomości albo odpowiedzi generowanej przez aplikację internetową. Informacja ta może odnosić się do całego zasobu lub do konkretnego fragmentu tekstu. Dzięki niej przeglądarka, czytnik ekranu, narzędzie tłumaczące oraz inne programy mogą lepiej rozpoznać, jak należy interpretować zawartość. Nie chodzi wyłącznie o wybór języka interfejsu. Interfejs może być ustawiony po polsku, podczas gdy sama wiadomość będzie napisana po angielsku, niemiecku albo w kilku językach jednocześnie.

W praktyce Content-Language występuje najczęściej jako nagłówek odpowiedzi HTTP. Serwer przekazuje wtedy informację dotyczącą języka zwracanej reprezentacji zasobu. Przykładowo odpowiedź może zawierać wartość pl, en albo bardziej szczegółowe oznaczenie, takie jak pl-PL. Pierwsza część wskazuje język, a druga wariant regionalny. Sam zapis nie tłumaczy tekstu i nie zmienia jego treści. Jest metadanymi opisującymi zawartość, podobnie jak typ dokumentu, kodowanie znaków lub informacje o pamięci podręcznej.

Warto odróżnić język dokumentu od języka preferowanego przez osobę odwiedzającą stronę. Content-Language opisuje to, co faktycznie zostało dostarczone. Preferencje odbiorcy są zwykle przekazywane w żądaniu za pomocą nagłówka Accept-Language. Przeglądarka może wysłać informację, że preferowany jest język polski, lecz dopiero serwer decyduje, którą wersję zasobu zwrócić. Jeżeli wybrana reprezentacja jest polska, odpowiedź może zostać oznaczona jako Content-Language: pl.

Content-Language w protokole HTTP i w porównaniu z innymi oznaczeniami

Nagłówki językowe uczestniczą w negocjacji treści, ale każdy z nich pełni inną funkcję. Accept-Language jest częścią żądania i przedstawia oczekiwania klienta. Content-Language należy do odpowiedzi i opisuje język otrzymanego materiału. Nie powinno się traktować tych pól jako zamienników. Jedno mówi o preferencji, drugie o rezultacie.

Istotne jest również rozróżnienie między Content-Language a atrybutem lang w HTML. Atrybut lang wskazuje język elementu dokumentu i może być stosowany osobno dla całej strony, sekcji, akapitu lub pojedynczego cytatu. Jest szczególnie przydatny dla technologii asystujących, ponieważ pozwala zmienić sposób wymowy w środku dokumentu. Nagłówek HTTP ma szerszy, transportowy charakter i opisuje dostarczoną reprezentację z perspektywy protokołu.

Nie należy mylić Content-Language z kodowaniem znaków. Za informację o sposobie zapisania bajtów odpowiada zwykle parametr charset w nagłówku Content-Type, na przykład UTF-8. Język określa, czy tekst jest polski, czeski albo angielski, natomiast kodowanie określa, jak zapisane są znaki w danych. Błędne kodowanie może prowadzić do wyświetlania krzaków zamiast liter, lecz poprawienie kodowania nie ustawi automatycznie języka dokumentu.

W serwisach wielojęzycznych Content-Language może wspierać rozróżnienie kilku wersji tego samego adresu lub kilku wariantów odpowiedzi. Jeżeli system dobiera treść na podstawie nagłówka Accept-Language, warto zadbać o spójność oznaczeń oraz o poprawną obsługę pamięci podręcznej. Gdy odpowiedź zmienia się w zależności od języka żądania, często potrzebna jest także informacja Vary: Accept-Language. Bez niej pośrednia pamięć podręczna może zwrócić użytkownikowi wersję przygotowaną dla innego języka.

Oznaczenie regionalne nie zawsze jest konieczne. Kod pl wystarcza, gdy treść jest przeznaczona ogólnie dla osób posługujących się językiem polskim. Forma pl-PL może być przydatna, gdy znaczenie zależy od odmiany regionalnej, słownictwa, norm zapisu dat lub lokalnych wariantów języka. Nie należy jednak dopisywać regionu bez powodu, ponieważ nadmierna szczegółowość utrudnia późniejsze zarządzanie wariantami.

Content-Language a typowe problemy z interpretacją języka

Jednym z częstych problemów jest całkowity brak nagłówka przy stronie zawierającej treść w określonym języku. Nie zawsze powoduje to widoczny błąd w przeglądarce, ale może pogorszyć działanie czytnika ekranu, automatycznego tłumaczenia lub mechanizmów wyboru wersji językowej. Czasem aplikacja wysyła nagłówek wskazujący jeden język, mimo że dokument zawiera długie fragmenty w innym. Taka niespójność jest szczególnie kłopotliwa dla odbiorców korzystających z syntezy mowy.

Inny przypadek występuje wtedy, gdy warstwa aplikacyjna ustawia język według ustawień konta, a serwer dostarcza zawartość wybraną według Accept-Language. W efekcie nagłówek może wskazywać polski, podczas gdy faktycznie widoczny tekst jest angielski. Źródłem problemu bywają także przekierowania, systemy tłumaczeń, pamięć podręczna, połączenie kilku modułów oraz ręczne ustawienia serwera. Sama obecność nagłówka nie świadczy jeszcze o jego poprawności.

Trudność może sprawiać także używanie jednej wartości dla dokumentu zawierającego wielojęzyczne elementy. Jeżeli strona ma polską nawigację i angielski cytat, nagłówek odpowiedzi może opisywać dominujący język zasobu, natomiast poszczególne fragmenty powinny otrzymać właściwe oznaczenia w kodzie HTML. Dzięki temu narzędzia nie muszą zgadywać, czy zmiana słownictwa jest zamierzona.

W diagnostyce należy sprawdzić pełną odpowiedź HTTP, a nie tylko kod źródłowy strony. Pomocne jest porównanie nagłówków dla kilku adresów, wersji językowych i typów urządzeń. Warto sprawdzić, czy odpowiedź po przekierowaniu zachowuje właściwe oznaczenie, czy serwer nie zwraca przypadkowo języka domyślnego oraz czy cache nie miesza wariantów. Jeżeli problem dotyczy wymowy, trzeba dodatkowo przeanalizować atrybuty lang w strukturze HTML.

Content-Language — praktyczne wskazówki dla strony i aplikacji

Najlepiej ustalać język na podstawie rzeczywistej wersji wysyłanej treści. Jeżeli endpoint zwraca polski opis, odpowiedź powinna mieć adekwatne oznaczenie. Jeżeli ten sam adres może zwrócić różne wersje, należy połączyć wybór języka z konsekwentną polityką pamięci podręcznej i testami dla kilku wartości Accept-Language. Warto również ustalić, czy aplikacja rozróżnia język interfejsu, język danych wprowadzonych przez użytkownika oraz język wygenerowanego komunikatu.

W dokumentach HTML warto określić język na elemencie głównym, a zmianę języka zaznaczać lokalnie. Przykładowo polski dokument może zawierać angielski tytuł produktu albo cytat, lecz każdy taki fragment powinien mieć własne oznaczenie, jeśli wpływa ono na wymowę lub interpretację. Takie podejście jest czytelniejsze niż próba opisania całej strony jednym ogólnym założeniem.

Nie należy używać Content-Language jako substytutu tłumaczenia. Oznaczenie nie tworzy drugiej wersji strony, nie zmienia słów i nie gwarantuje, że użytkownik zobaczy język zgodny z preferencją. Do przygotowania wersji językowych potrzebne są odpowiednie zasoby, mechanizm routingu, tłumaczenia oraz kontrola jakości. Nagłówek jedynie przekazuje informację o wybranym wariancie.

Przy testowaniu warto zweryfikować kilka scenariuszy: pierwsze żądanie bez preferencji językowej, żądanie z jednym językiem, żądanie z listą preferencji, zmianę języka w ustawieniach oraz odpowiedź przechowywaną w cache. Należy sprawdzić zarówno nagłówki, jak i zachowanie czytnika ekranu. W przypadku stron zawierających formularze trzeba także pamiętać, że język etykiet, komunikatów walidacyjnych i treści wpisywanej przez użytkownika może być różny.

Kiedy sprawdzić Content-Language w serwisie komputerowym

Do weryfikacji warto zgłosić się wtedy, gdy strona jest odczytywana w niewłaściwym języku, automatyczne tłumaczenie wybiera nieodpowiednią wersję, czytnik ekranu stosuje błędną wymowę albo po zmianie ustawień przeglądarka nadal pokazuje poprzednią treść. Wskazaniem jest również sytuacja, w której wersja językowa działa poprawnie po odświeżeniu, lecz nieprawidłowo po przejściu przez przekierowanie lub po wejściu z innego urządzenia. W takich przypadkach potrzebne jest sprawdzenie odpowiedzi serwera, kodu strony, konfiguracji aplikacji i pamięci podręcznej.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić analizę problemów z działaniem strony, przeglądarki lub komputera, gdy nieprawidłowa interpretacja języka utrudnia codzienną pracę. Przydatne jest przygotowanie adresu strony, przykładowej błędnej odpowiedzi, informacji o używanej przeglądarce oraz opisu kroków prowadzących do problemu. Takie dane ułatwiają odtworzenie sytuacji i rozdzielenie błędu po stronie urządzenia od błędu w konfiguracji serwisu internetowego.

Warto reagować także wtedy, gdy problem pojawia się tylko na jednym komputerze. Przyczyną może być lokalny cache, rozszerzenie przeglądarki, ustawienia językowe systemu albo uszkodzone dane witryny. Jeżeli natomiast nieprawidłowy nagłówek jest widoczny dla wielu odbiorców i w różnych sieciach, większe znaczenie ma konfiguracja serwera lub aplikacji. Poprawne rozpoznanie źródła pozwala dobrać działanie bez przypadkowej zmiany ustawień, które nie mają związku z Content-Language.