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

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

Question

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

Background

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

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

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

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

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

Answer

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

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

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

By the way

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

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