Использование Accept-Language для настройки локали

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

Question

Хорошо ли использовать заголовок HTTP Accept-Language для определения локали пользователя?

Background

По ряду вполне уважительных причин некоторые веб-приложения, хотели бы связывать локаль с каждым пользователем, который заходит на сайт. Эта локаль позволит им предоставлять информацию в местном формате. Часть этой информации является общей для такого традиционного программного обеспечения локалей, как:

Какие числовые форматы ожидает пользователь?
Как будут отформатированы дата и время?

В других случаях, другую информацию можно получить на основе информации локали плюс таких дополнительных знаний, как:

Должна ли быть метрической система мер (сантиметры, километры, литры) или imperial (Великобритания) (дюймы, мили, галлоны)?
Какой часовой пояс пользователя?
Использует ли пользователь бумагу формата листа или A4?
Какие системы размеров обуви и одежды должны использоваться?
Где физически находится пользователь?

Поскольку ни один из них не включен в протокол 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 для позднейших посещений.

Некоторые из потенциальных проблем включают следующее:

Многие пользователи никогда не меняют настройки по умолчанию для Accept-Language. Они устанавливаются, при установке клиентских приложений. Они могут говорить на разных языках или иметь какие-то другие причины для настройки языковых предпочтений, они могут даже не знать о существовании таких настроек. Таким образом, пользователь может даже и не иметь утвержденных Accept-Language настроек.
Клиентское приложение может послать запрос, который определяет только язык, а не регион, например, вы можете получить заголовок без de-DE , de-CH или de-AT , чтобы указать Немецкий язык на котором говорят в Германии, Швейцарии или Австрии, соответственно. Кроме того, вы можете получить только de , что указывает на, то что предпочтение отдают Немецкому. Если вы планируете использовать регион для того чтобы решить, какую валюту использовать вам в данной ситуации, то ваши конкретные обстоятельства могут позволить вам сделать такие предположения, как "В Германии проживает 83 миллионов человек, 7 миллионов в Швейцарии, но только 63% говорят Немецкой, в Австрии проживает 8 миллионов, так что пользователь, вероятно, использует евро. Если мы ошибаемся то это затронет лишь 4.6% наших германоязычных клиентов или только более 4 миллионов человек." Не стесняйтесь делать такие предположения, если такой риск для вас приемлем. Гораздо проще спросить у пользователя для получения дополнительной информации. Кроме того, расчеты становятся все труднее, например для Испанского или Английского языка.
Люди заходят на сайты от друзей, или из интернет кафе. В таких случаях определение локали может быть неуместным, и следует позаботиться, чтобы пользователи могли выбрать соответствующий язык и локаль на любой странице, которую они просматривают.

By the way

Использование заголовка Accept-Language это хорошая отправная точка для определения языка пользователя, а не локали, но даже тогда вы должны знать его ограничения и дать пользователю некий способ чтобы поменять предположения, которые вы сделали. Многие из перечисленных выше потенциальных проблем применяются и здесь.

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

📎📎📎📎📎📎📎📎📎📎