Прискорююча кнопка n назначена для пропусків при навігації по сторінкам. Пропуск для переходу на початок контента.

Даний документ є перекладом. У випадку будь-яких невідповідностей і помилок остання версія документу англійською мовою повинна розглядатися як офіційна. Першопочаткове авторське право належить W3C, як це вказано нижче.

Перекладач: Alexandr Shlapak

s_gotoW3cHome Інтернаціоналізація
 

Використання Accept-Language для налаштування локалі

Аудиторія: розробники скриптів (PHP, JSP, і т.д.), менеджери Веб проектів, і кожен, хто хоче використовувати інформацію про локалі.

Питання

Чи добре використовувати заголовок HTTP Accept-Language для визначення локалі користувача?

Ввідна інформація

По ряду цілком поважних причин деякі веб-додатки, хотіли б пов'язувати локаль з кожним користувачем, який заходить на сайт. Ця локаль дозволить їм надавати інформацію в місцевому форматі. Частина цієї інформації є спільною для такого традиційного програмного забезпечення локалей, як:

В інших випадках, іншу інформацію можна отримати на основі інформації локалі плюс таких додаткових знань, як:

Оскільки жоден з них не включений в протокол HTTP багато веб-розробників використовують Accept-Language заголовок, щоб зробити висновки про локалі користувача.

Заголовок Accept-Language - це інформація про мову, якій віддає перевагу користувач яка при запиті документу передається через HTTP. Основні браузери дозволяють користувачу змінювати ці мовні переваги. Значення, саме по собі, визначене BCP 47, зазвичай як дво- або трилітерний код (наприклад fr для Французької мови), за яким слідують додаткові subcodes, що відображають такі речі як країна (наприклад fr-CA відображає Французьку якою розмовляють в Канаді).

Питання в тому чи ця інформація підходить для визначення локалі користувача.

Відповідь

Спочатку заголовок HTTP Accept-Language був призначений тільки для вказівки мови користувача. Однак, оскільки багато додатків повинні знати локалі користувача, звичайно практикується використання Accept-Language, щоб визначити цю інформацію. Це не добре використовувати тільки HTTP Accept-Language заголовок для того, щоб визначити локаль користувача. Якщо ви використовуєте виключно Accept-Language, то ви можете обмежити користувача у виборі варіантів мов, які йому подобаються.

По-перше гарним початком може стати використання значення Accept-Language для визначення регіональних налаштувань, але переконайтесь, що ви дозволили в разі необхідності змінювати мову і точніше вказувати культурні налаштування. Зберігайте результати в базі данних або в cookie для пізніших відвідувань.

Деякі з потенційних проблем включають наступне:

Доречі

Використання заголовка Accept-Language це хороша відправна точка для визначення мови користувача, а не локалі, але навіть тоді ви повинні знати його обмеження і дати користувачеві якийсь спосіб змінити припущення, що ви зробили. Багато з перерахованих вище потенційних проблем застосовуються і тут.

Навіть якщо ви робите припущення про локаль або регіон навмання, ви повинні знати, що ваше програмне середовище може зробити такі припущення за вас. Багато Веб серверів, скриптових мов на сервері, та операційних середовищ, за замовчуванням, аналізують та припускають їх власні об'єкти локалі із Accept-Language. Наприклад, .NET використовує Accept-Language для визначення за замовчуванням таких параметрів: CultureInfo, Java Servlet забезпечує getLocale() та getLocales() пара методів, які аналізують Accept-Language і т.д. Ці об'єкти дуже корисні при отриманні ресурсів та іншого матеріалу, що стосується "мовних переваг". Як зазначалося вище, вони менш корисні при визначенні багатьох атрибутів користувачів або в проектуванні міжнародної поведінки сайту. Це не обов'язково означає, що коли користувач віддає перевагу es-MX, то форма поштової адреси повинна форматуватися або перевірятися по Мексиканських адресах. Користувач може як і раніше жити в США (або в іншому місці).

Розкажіть нам про те, що Ви думаєте.

Підписатися на RSS джерело.

Нові джерела

Новини головної сторінки

Twitter (Новини головної сторінки)

‎@webi18n

Додаткові матеріали

Автор: Lloyd Honomichl, Lionbridge. Перекладач: Alexandr Shlapak.

Допустимий XHTML 1.0!
Допустимий CSS!
Кодування UTF-8!

Переклад Англійського контенту від 2003-09-17. Переклад останнього оновлення 2011-07-30 12:00 GMT

Для перегляду історії внесення змін до перекладу натисність qa-accept-lang-locales в блоге i18n.