Как веб-сайты должны иметь дело с настройками локализации? (от, “Что такое общие неправильные представления UI и раздражения?”)

Я согласен, дайте пользователю возможность переопределить их с помощью пользовательских настроек в вашем приложении. Это особенно удобно для таких вещей, как проблемы с локализацией часового пояса, которые нельзя решить в настройках браузера.

Я рискую, что меня сочтут невежливым, но я думаю, что в моем сообщении по этой теме будут более информативные ответы, в основном потому, что мой пост действительно является вопросом. Мне очень жаль, что я не нашел это сообщение раньше.

Существует разница между интеллектуальными настройками по умолчанию и возможностью пользователей отменять их. . В больших приложениях, над которыми я работал, я предполагал локаль пользователя из настроек браузера, геолокации и т. Д. - но всегда давал пользователям возможность легко переключаться.

Я не знаю, как еще можно это сделать . Не дать пользователям возможности исправить ваши предположения - это серьезная проблема, потому что иногда вы будете ошибаться.

ДОПОЛНЕНИЕ:

Я думаю, ваша проблема здесь в том, что, хотя вы можете редактировать настройки локали, если они выглядят в основном так же, как и по умолчанию, разработчик приложения не может сказать, оставили ли вы его намеренно или потому, что вы его не оставили. я не знаю, как и зачем его менять.

Я предлагаю соблюдать пользовательские настройки локализации, за исключением , если это подавляющее значение по умолчанию, которое пользователи не могут изменять. Например, я считаю, что подавляющее большинство (90 +%) пользователей с настройкой en-us с геолокацией во Вьетнаме почти всегда будут лучше удовлетворены просмотром вьетнамского контента, а не контента на английском языке, если есть тривиальный способ переключить язык. С другой стороны, если пользователь, геолокация которого находится в США, использует вьетнамский язык, во что бы то ни стало дайте ему или ей контент на вьетнамском языке.

Раздражает ли это пользователей, говорящих на английском языке США во Вьетнаме? Конечно. Но это также величайшее благо для наибольшего числа людей и помогает гарантировать, что средние нетехнические пользователи получат лучший реальный опыт. Пока мы не сможем держать оружие перед пользователями

В какой-то момент моей карьеры я поддерживал части стека TCP / IP. Это ставит меня в довольно редкое положение, когда я очень хорошо знаю, что IP-адреса не должны использоваться ни для чего другого, кроме адресов сетевого уровня. Любая связь между IP-адресом и местоположением почти случайна - это артефакт способа распределения адресов, а не какая-либо фундаментальная часть того, что означает IP-адрес.

(Они также бесполезны в качестве уникального идентификатора компьютер, но это уже другая история)

Я предлагаю не использовать геолокацию. Стандарт HTTP включает в себя способ, позволяющий браузеру или другому пользовательскому агенту включать предпочтения культуры пользователя в каждый запрос (и помните, что это список взвешенных предпочтений, а не обязательно только одну культуру). Поскольку браузер ближе к пользователю, чем вы, вы должны соблюдать этот запрос, по крайней мере, как значение по умолчанию.

Затем можно разрешить пользователю изменять свои предпочтения для вашего сайта, временно или навсегда. Можно даже позволить пользователю выбирать для просмотра разный контент с разными настройками культуры. Ярким примером может служить сайт, содержащий как политические новости, так и техническую информацию. Вполне разумно, что кому-то нужны новости на их «естественном» языке, а техническая информация - на английском.

Наконец, нормально иметь запасной вариант. Если, например, у вас есть сайт, который обслуживает пользователей в зависимости от их региона (например, реселлеров), то возможно, что японский контент существует только на вашем азиатском региональном суб-сайте. Япоговорящий пользователь, посещающий ваш сайт в регионе EMEA, может просто застрять на просмотре англоязычного контента.

Я видел достаточно убедительных отчетов об ошибках от клиентов, которые при расследовании показали, что у одного из пользователей была неправильная настройка культуры браузера, и теперь мы позволяем клиенту переопределять браузеры с помощью конфигурации настройка. Настройки языка и региональных параметров браузера достаточно часто ошибочны, так что они не очень полезны; большинству конечных пользователей также слишком сложно их найти или изменить.

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

Распространенным аргументом против этого является то, что «обычные пользователи «недостаточно умен, чтобы найти языковые настройки и настроить их в соответствии со своими предпочтениями, поэтому эти настройки, как правило, неверны (если пользователь не находится в США).

Это неверно решение.

Если значительная часть пользователей не может найти (или не может потрудиться найти) языковые настройки своего браузера, то правильный ответ - упростить их поиск , не для сайтов, чтобы игнорировать то, на что они были настроены. Возможно, сделать языковые настройки напрямую доступными из программы ' s меню верхнего уровня вместо того, чтобы скрывать его в слишком сложном диалоге «Настройки». Возможно, спросите языковые настройки при первом запуске программы. Возможно, воспользуйтесь настройками локализации операционной системы. Или, может быть, что-то совершенно другое, если это то, что нужно, чтобы быть почти уверенным, что браузер будет отправлять правильную информацию о предпочтениях пользователя. Но не просто разводите руками, говорите «это бесполезно и не может быть исправлено!» И игнорируйте это.

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

На сайтах, которые я создаю, я обычно следую этому шаблону:

• Каждая страница имеет уникальный URL-адрес с указанным на нем языком,
  • Доступен ли файл cookie из предыдущего сеанса?
  • Если нет, доступен ли Accept-Language и могу ли я сопоставить его с языком, доступным на сайте?
  • Если нет, если это возможно, могу ли я угадать по IP?
  • Если нет, по умолчанию используется язык сайта по умолчанию.
• Я устанавливаю файл cookie с предполагаемым языком и перенаправляю пользователя на сайт с соответствующим URL.
• Я помещаю переключатель языка на каждой странице, поэтому / en / page можно легко переключить на / xx / page
  • Cookie обновляется, если пользователь переключается на другую страницу

В идеале я только необходимо угадать один раз и с этого момента использовать cookie пользователя, иначе пользователь зайдет на нужную страницу напрямую.