Правильный способ - посмотреть на заголовок HTTP Accept-Language , отправленный на сервер. Он содержит упорядоченный, взвешенный список языков, которые пользователь настроил для своего браузера.
К сожалению, этот заголовок недоступен для чтения внутри JavaScript; все, что вы получаете, это navigator.language
, который сообщает вам, какая локализованная версия веб-браузера была установлена. Это не обязательно то же самое, что предпочтительный язык (и) пользователя. В IE вместо этого вы получаете systemLanguage
(установленный язык ОС), browserLanguage
(такой же, как language
) и userLanguage
(настроенный пользователем регион ОС), которые все также бесполезны.
Если бы мне пришлось выбирать между этими свойствами, я бы сначала обнаружил userLanguage
, вернувшись к language
и только после этого (если они не соответствовали ни одному из доступных языков), глядя на browserLanguage
и, наконец systemLanguage
.
Если вы можете поместить серверный скрипт где-нибудь еще в сети, который просто читает заголовок Accept-Language и выплевывает его обратно в виде файла JavaScript со значением заголовка в строке, например ::
var acceptLanguage= 'en-gb,en;q=0.7,de;q=0.3';
тогда вы можете включить , указывающий на эту внешнюю службу в HTML, и использовать JavaScript для анализа заголовка языка. Однако я не знаю ни одного существующего библиотечного кода для этого, поскольку синтаксический анализ Accept-Language почти всегда выполняется на стороне сервера.
Что бы вы ни делали в конечном итоге, вам, безусловно, нужно переопределить пользователя, потому что для некоторых людей оно всегда будет неверным. Часто проще всего указать языковые настройки в URL (например, http: //www.example.com/en/site против http: //www.example.com/de/site) и позволить пользователю нажать связи между двумя. Иногда вам требуется один URL-адрес для обеих языковых версий, и в этом случае вам необходимо сохранить настройки в файлах cookie, но это может сбить с толку пользовательских агентов без поддержки файлов cookie и поисковых систем.