Хорошо ли использовать заголовок 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, то форма почтового адреса должна форматироваться или проверяться по Мексиканских адресам. Пользователь может по-прежнему жить в США (или в другом месте).