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