Чи добре використовувати заголовок 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 для пізніших відвідувань.
Деякі з потенційних проблем включають наступне:
de-DE, de-CH або de-AT, щоб вказати Німецьку мову якою спілкуються в Німеччині, Швейцарії або Австрії, відповідно. З іншого боку, ви
можете отримати тільки de, що вказує на те, що перевагу віддають Німецькій. Якщо ви плануєте використовувати регіон для того щоб вирішити, яку валюту використовувати вам в даній
ситуації, то ваші конкретні обставини можуть дозволити вам зробити такі припущення, як "В Німеччині проживає 83 міліонів чоловік, 8 міліонів в Швейцарії,
але тільки 65% розмовляють Німецькою, в Австрії проживає 8 міліонів, так що користувач, ймовірно, використовує євро. Якщо ми помиляємось то це зачепить лише 5.4% наших Германомовних
клієнтів або лише понад 5 міліони чоловік." Не соромтеся робити такі припущення, якщо такий ризик для вас прийнятний. Набагато простіше запитати у користувача для
отримання додаткової інформації. Крім того, обрахунки стають все важчими, наприклад для Іспанської або Англійської мови.Використання заголовка Accept-Language це хороша відправна точка для визначення мови користувача, а не локалі, але навіть тоді ви повинні знати його обмеження і дати користувачеві якийсь спосіб змінити припущення, що ви зробили. Багато з перерахованих вище потенційних проблем застосовуються і тут.
Навіть якщо ви робите припущення про локаль або регіон навмання, ви повинні знати, що ваше програмне середовище може зробити такі припущення за вас. Багато Веб серверів, скриптових мов на сервері, та операційних середовищ, за замовчуванням, аналізують та припускають їх власні об'єкти локалі із Accept-Language. Наприклад, .NET використовує Accept-Language для визначення за замовчуванням таких параметрів: CultureInfo, Java Servlet забезпечує getLocale() та getLocales() пара методів, які аналізують Accept-Language і т.д. Ці об'єкти дуже корисні при отриманні ресурсів та іншого матеріалу, що стосується "мовних переваг". Як зазначалося вище, вони менш корисні при визначенні багатьох атрибутів користувачів або в проектуванні міжнародної поведінки сайту. Це не обов'язково означає, що коли користувач віддає перевагу es-MX, то форма поштової адреси повинна форматуватися або перевірятися по Мексиканських адресах. Користувач може як і раніше жити в США (або в іншому місці).