У тебя есть еще? Конечно, я делаю. Но сначала ...
Объявление 1. Amazon имеет разные каталоги, потому что на самом деле Amazon Deutschland (ее немецкая дочерняя компания), Amazon UK (ее британская дочерняя компания) фактически являются разными компаниями (на юридической основе). Их предложение, как правило, различается, и, конечно, юридические требования (то есть налоги) существенно различаются. Поэтому эти сайты похожи (я уверен, что они используют общее программное обеспечение и используют общую инфраструктуру), но не совсем одинаковые (серверная часть БД, вероятно, отличается).
Если вы создаете сайт для аналогичной компании, это имеет смысл.
Объявление 2. Перенаправление на языковой домен имеет смысл в том же случае, что и в первом примере - если у вас есть существенно иное предложение для международных клиентов.
Объявление 3. Использование параметра URL и настройка cookie на самом деле рекомендуется, но имейте в виду, что это должно быть только частью рабочего процесса (подробнее об этом позже). Особенно это имеет смысл, если ваш веб-сайт на самом деле является одним и тем же приложением, и содержание не отличается для всех пользователей, но вы просто хотите перевести его.
Пример 4. Иногда (см. CNN) люди используют часть локального домена, то есть http://english.example.com/, http://arabic.example.com/. Это можно рассматривать как вариант 3 - вы бы на самом деле использовали какой-то фильтр URL и установить язык в куки.
Пример 5. Для типичных веб-приложений / веб-сайтов (везде одинаковый контент), на мой взгляд, лучше всего использовать какой-то рабочий процесс определения локали. В этом случае, конкретный домен или нет, вы бы обслуживали контент на любом языке.
КСТАТИ. Возможно, вы захотите разделить свою инфраструктуру географически, чтобы пул серверов, расположенный в России, отвечал на http://example.ru/, и этот пул содержал только российские ресурсы - в этом случае вы определенно будете использовать перенаправление. Если у вас есть один, центральный пул серверов, это на самом деле не имеет особого смысла.
Возвращаясь к процессу обнаружения ...
- Определить локаль из веб-браузера (в конце концов, были некоторые причины для появления заголовка HTTP Accept-Language). Это должно быть преобладающим: пользователь обычно хочет видеть контент на своем языке. И это уже установлено в настройках веб-браузера, так почему мы хотим заставить пользователя выбрать его снова?
После определения языка (в любом домене) вы просто установили cookie-файл сеанса, чтобы все последующие запросы использовали эту информацию (если только ...).
- Если ваше приложение содержит профили пользователей, рекомендуется изменить язык пользовательского интерфейса по умолчанию и язык форматирования в профиле. Это также хорошее место для хранения предпочтительного часового пояса. Пожалуйста, имейте в виду, что для этих настроек браузера по умолчанию должны быть хорошие значения по умолчанию - для языка пользовательского интерфейса вы должны использовать запасной механизм (я бы углубился в него позже), поэтому, если пользователь предпочитает локаль de-AT (немецкий, Австрия), он будет просто de (общие ресурсы для немецкого языка), форматирование локали не будет резервным, поэтому будет de-AT (или de_AT, в зависимости от фактического представления локали). Часовой пояс более проблематичен, но он не является предметом этого ответа.
Очевидно, это должно переопределить локаль веб-браузера.
- Вы можете использовать либо параметр URL (т. Е. http://example.com/index.html?lang=de), либо доменное имя более низкого уровня (т. Е. http://deutsch.example.com/)), чтобы переопределить текущий выбранный выбор. Это важно по двум причинам: одна - разрешить пользователям добавьте в закладки ссылку на данном языке, во-вторых, чтобы можно было точно выбрать данный язык, который может быть полезен во время сеансов технической поддержки (представьте, что какой-то инженер службы технической поддержки удаленно управляет веб-браузером на китайском языке - как переключить язык?).
- При желании вы можете реализовать раскрывающееся меню переключения языков. Очевидно, он может просто перенаправить на т. Е. http://deutsch.example.com/.
Пример 6. Некоторые веб-сайты, хотя я категорически против, используют IP-адрес пользователя для оценки его / ее географического местоположения с целью перенаправления его / ее на локализованный веб-сайт.Геолокация также может быть использована для этой цели.Опять же, это может иметь мало (просто мало) смысла, если ваши локальные веб-сайты значительно отличаются.
Теперь на языковой запас.Обычно заголовок HTTP Accept-Language выглядит так:
Accept-Language: da, de;q=0.8, fr;q=0.7
Наиболее предпочтительным языком в этом случае является датский, но пользователь, кажется, также понимает немецкий и французский.Поэтому было бы неуместно возвращаться к английскому, если вы не можете найти ресурсы для датского, но на самом деле есть немецкие.Вам следует пройтись по списку и вернуться к настройкам приложения по умолчанию, только когда ничего не подходит.
Это также показывает другую проблему: иногда в этом заголовке нет информации о стране.Так какой язык нужно использовать для форматирования дат, чисел и т. Д.?Я не думаю, что есть хороший ответ на этот вопрос - в этом случае профили пользователей - действительно хорошее решение.Проблема в том, что если у вас уже есть какая-то пользовательская база, было бы трудно заставить их настроить эту информацию.