Pull to refresh

Comments 20

К сожалению, полный разбор HTTP_ACCEPT_LANGUAGE вряд ли имеет смысл, потому как: 1) тяжеловесен 2) если сайт не поддерживает язык с наибольшим весом, в общем-то, всё равно какой язык предлагать взамен.
Тут я бы поспорил :) Например, мне кажется, украинцам или белорусам русский язык будет предпочтительнее английского
Так давайте же поспорим %)
Имею мнение, что мало кто на клиенте вручную выставляет веса в порядке be_BY, ru_RU и uk_UA, ru_RU. Если знаете ОС и браузеры, в которых такие веса выставлены по умолчанию при установке, поделитесь пожалуйста.
Когда я в опере выставил язык интерфейса на ураинский, то вторым в списке предпочитаемых языков выставился русский. Хотя я не берусь утверждать, что так будет у всех: могла учитываться локаль системы или то, что ранее основням языком стоял русский.
Я говорил об этом
если сайт не поддерживает язык с наибольшим весом, в общем-то, всё равно какой язык предлагать взамен
Т.е. даже если у человека после украинского языка идёт английский, по-моему логичнее ему предложить русский язык при отсутствии украинской локализации

Ну а, скажем, немцу я бы всё же английский предложил :)
Ну, так вы контекст фразы во внимание возьмите ;) Речь идет о том, что всё равно какой из менее весомых объявленных языков использовать.

Кстати, вы наталкиваете на толковую функциональность для библиотеки, которая могла бы использоваться в клиентском приложении: получаем код языка с максимальным весом; пытаемся установить локаль приложения; если не получается, проходим по дереву родственных языков, пытаясь отыскать тот, для которого предусмотрена локализация. Главное вовремя остановиться, а иначе и до праязыков дойти можно.
Согласен. BTW, мы обычно в своих проектах так и делаем: берём язык с наибольшим приоритетом и смотрим есть ли у нас такая локализаиця. Если нет, то смотрим таблицу соответствия языка пользователя и языковой группы, в которую он входит, и, соответственно, предлагаем ему имеющуюя у нас локализацию из этой группы
UFO just landed and posted this here
Да, выбор конечно, это при первом входе, потом используются куки, где хранится выбранный язык
Аналогично. У меня система, все программы итд — на английском(русская локаль даже не установлена). Сайтами предпочитаю пользоваться на английском(даже если есть русская локализация). И очень раздражает когда мне какой-нить сайт показывает русскую версию ориентируясь на моем географ. положении а не на локали системы.
Но в статье то как раз описывается правильный способ, учитывающий именно предпочтения пользователя, которые, как правило, браузер выставляет по локали системы.
Да я вижу, я же не на статью отвечал а на комментарий.
Кажется вы чего-то не поняли. Статья как раз о том, чтобы дать выбор ВАМ. У вас же в HTTP_ACCEPT_LANGUAGE перечислены те языки, на которых вы хотите видеть сайты, правда? Если нет, то почемы вы возмущаетесь, что сайт выдает вам страницы на том языке, который вы запросили?
Ключевая фраза «раз за разом»
HTTP_ACCEPT_LANGUAGE является единственно верным способом выбора языка страницы. Использование cookie таковым не является, так как противоречит основным концепциям, заложенным в HTTP, что приводит к архитектурным проблемам в серверном коде. В частности использование cookie мешает масштабированию сервисов.

К сожалению, совеменные браузеры еще не доросли до нормальной поддержки языков и клиентскую логику приходится реализовывать в серверном ПО. Переключение языков должно быть простым и удобным, сделанным кнопкой на панели инструментов. Не надо будет искать, куда дизайнер вставил переключалку: она всегда на одном и том же месте.
W3C прямо заявляет, что этот способ не должен расцениваться как «единственно верный».
Тут важна грань между «как должно быть» и «что можно сделать с текущими технологиями». С текущими технолгиями и практиками их применения HTTP_ACCEPT_LANGUAGE действительно невозможно использовать как «единственно верный» способ т.к. пользователям надо давать возможность выбора языка и этот выбор где-то должен запоминаться. Клиентское ПО не дает простого сопособа для этого. Потому W3C и дает такие рекомендации.

Просто в последние годы наметилась тенденция по использованию всех тех возможностей, которые были заложены в HTTP 12 лет назад. Появилась мода на REST, на HATEOAS. Мобильные браузеры научились позволять пользователю легко, в два клика, выставлять заголовки, переключающие сайт в вид для мобильных устройств и для настольных ПК. Поэтому у меня есть надежда, что в ближайшие год-два новейшие версии браузеров научаться более широко использовать заголовки типа ACCEPT*, а через несколько лет этим можно будет пользоваться на серверах.
Не факт, что так быть должно.
Взгляните: клиентское ПО не даёт простого способа, потому что это никому не нужно — хватает одной базовой локали (соотвествующей системой), и одной дополнительной (обычно английский). Это предпочтения, выставлющиеся на этапе установки браузера.
Есть, конечно, вероятность, что ваши надежды оправдаются. Но есть и обратная.
Очередная бесполезная статья школьника, открывшего для себя Accept-Language.
Почему бесполезная, если бы я нашел эту статью на момент поиска решения своей задачи, она бы мне помогла. И я не думаю что я один такой, кто открывает для себя Accept-Language. К тому же в статье описан не один из сотен более простых способов определения языка описанных ранее, а с синонимами для разных языков.
Sign up to leave a comment.

Articles

Change theme settings