Формат URL для интернационализированного веб-приложения?

Question

Сценарий

Веб-сервер получает запрос на http://domain.com/folder/page. Заголовок Accept-Language говорит нам, что пользователь предпочитает греческий язык с кодом языка el. Это хорошо, так как у нас есть греческая версия page.

Теперь мы можем выполнить одно из следующих действий с URL:

1. Возвращает греческую версию с сохранением текущего URL: http://domain.com/folder/page
2. Перенаправление на http://domain.com/folder/page/el
3. Перенаправление на http://domain.com/el/folder/page
4. Перенаправление на http://el.domain.com/folder/page
5. Перенаправление на http://domain.com/folder/page?hl=el
6. ... другие альтернативы?

Какой из них лучше? Плюсы, минусы с точки зрения пользователя? Перспектива разработчика?

Answer 1

Я бы не стал использовать вариант 1, если ваши страницы общедоступны, т. Е. Вы не обязаны входить в систему для просмотра страниц. Причина в том, что поисковая система не сканирует версии страницы на разных языках. По той же причине повторяется опция № 5. Поисковая система с меньшей вероятностью идентифицирует две страницы как отдельные страницы, если идентификация языка идет в строке запроса.

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

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

Но просто комментарий для вдохновения. В настоящее время я работаю над веб-приложением, которое состоит из 3 основных частей, одной общедоступной и двух частей для двух разных типов пользователей. Я выбрал следующую схему URL (со ссылкой на язык, конечно):

http://www.example.com/en/x/y/z for the public part.
http://www.example.com/part1/en/x/y/z for the one private part
http://www.example.com/part2/en/x/y/z for the other private part.

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

Edit: Еще один аргумент против варианта нет. Во-первых, если вы слушаете ТОЛЬКО язык принятия, вы не предоставляете пользователю выбор. Пользователь может не знать, как изменить язык, установленный в браузере, или может использовать настройки компьютера frinds на другом языке. Вы должны по крайней мере предоставить пользователю выбор (сохранение его в файле cookie или в профиле пользователя)

Answer 2

Я бы выбрал номер 3 , перенаправить на http://example.com/el/folder/page, потому что:

1. Выбор языка важнее, чем выбор страницы, поэтому выбранный язык должен идти первым в истинно удобочитаемом URL-адресе.
2. Только один домен получает весь PR от Google. Это хорошо для SEO.
3. Вы можете рекламировать свой сайт локально с помощью встроенного языкового кода. Например. в Греции вы бы объявили как http://example.com/el/, поэтому каждый местный посетитель попадет на сайт в Греции и избежит разочарования в выборе языка.

Кроме того, вы можете выбрать номер 5 : это хорошо для Google и друзей, но не так хорошо для пользователя.

Кроме того, мы должны воздерживаться от перенаправления пользователя куда-либо, если это не требуется. Таким образом, на мой взгляд, пользователь, открывающий http://example.com/folder/page, должен получить не перенаправление, а страницу на языке по умолчанию.

Answer 3

Выберите вариант 5, и я не верю, что это плохо для SEO.

Эта опция хороша, потому что показывает, что содержание скажет:
http://domain.com/about/corporate/locations соответствует содержанию в
http://domain.com/about/corporate/locations?hl=el за исключением того, что язык отличается.
Параметр hl должен переопределять заголовок Accept-language, чтобы пользователь мог легко контролировать ситуацию. Заголовок будет использоваться только тогда, когда отсутствует параметр hl. Предоставленное связывание немного усложняется из-за этого и, вероятно, должно решаться с помощью куки-файла, который будет поддерживать перенаправление на язык, выбранный параметром hl (так как он может быть изменен пользователем из настройки Accept-language или путем обработки всех ссылок на странице для добавления текущего параметра hl.

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

Использование 1 убирает дифференциатор в URL. Использование 2 и 3 предполагает, что страница отличается, возможно, не только от языка, как в Википедии. И использование 4 предполагает, что сам сервер отделен, возможно, даже географически.

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

Answer 4

Мой собственный выбор # 3: http://domain.com/el/folder/page. Кажется, это самая популярная сеть в Интернете. У всех других альтернатив есть проблемы:

1. http://domain.com/folder/page --- Плохо для SEO?
2. http://domain.com/folder/page/el --- Не работает для страниц с параметрами. Это выглядит странно: ... page? Par1 = x & par2 = y / el
3. http://domain.com/el/folder/page --- Выглядит хорошо!
4. http://el.domain.com/folder/page --- Для развертывания требуется больше работы, поскольку для этого требуется добавить поддомен.
5. http://domain.com/folder/page?hl=el --- Плохо для SEO?

Answer 5

Номер четыре - лучший вариант, потому что он определяет код языка довольно рано. Если вы собираетесь предоставлять какие-либо перенаправления, всегда используйте тег канонической ссылки.

Answer 6

3 или 4.

3: С этим можно легко справиться, используя htaccess / mod_rewrite. Единственным недостатком является то, что вам придется написать какой-то метод автоматического внедрения кода языка в качестве первого сегмента URI.

4: Вероятно, лучший метод. Используя заголовки узлов, все они могут быть отправлены в одно и то же веб-приложение / контент, но затем вы можете использовать код для извлечения кода языка и перехода оттуда.

Simples. ;)

Answer 7

Ни один из них. «Обычный пользователь» не понимает (и не забывает) ни одного из этих сокращений.

В порядке предпочтения я бы предложил:

1. http://www.domain.gr/folder/page
2. http://www.domain.com/
3. http://domain.com/gr/folder/page

Answer 8

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

• Википедия использует субдомены для различных языки (el.wikipedia.org).
  • То же самое делает Yahoo (es.yahoo.com для испанского), хотя он не поддерживает греческий.
  • Так же, как и Граватар (el.gravatar.com)
• Google использует каталог / intl / el /.
• Apple использует каталог / gr / (хотя и на английском языке и ограничивается страницей iPhone)

Это действительно зависит от вас. Как вы думаете, что понравится вашим клиентам?

Answer 9

Я предпочитаю 3 или 4