Как лучше всего отобразить язык в своем URL?
У меня есть многоязычный веб-сайт, который использует красивые URL-адреса, так называемые URL-адреса, удобные для поисковых систем.
Теперь есть несколько мест для определения языка в URL:
www.example.com/en/articles/randomwww.example.com/nl/articles/random
en.example.com/articles/randomnl.example.com/articles/random
www.example.com/articles/random?lang=enwww.example.com/articles/random?lang=nl
Есть ли какой-либо предпочтительный способ показать это, или есть другой лучший способ, который я не включил?
11 ответов
Я нашел хороший ресурс от Google о выборе, который вы можете сделать. Есть раздел с за и против каждого метода, который вы можете использовать.
Я уже давно борюсь с многоязычными сайтами.
В статье определенно есть некоторые моменты, которые не упомянуты в упомянутых ответах. Вот почему я чувствовал необходимость опубликовать это как ответ. Я надеюсь, что это поможет кому-то.
Я скажу вам, что НЕ является лучшей практикой - использование параметров (3-й). Заставление пользователей вводить сложные URL-адреса вызывает проблемы.
Ваши страницы могут внутренне использовать параметры GET для поиска языка, но использовать модуль перезаписи URL, доступный на вашем веб-сервере, чтобы упростить его, например, первый - www.mydomain.com/en/articles/random
Даже со вторым все в порядке, за исключением того, что большинство пользователей вводят доменное имя и нажимают Ctrl + Enter.
https://addons.mozilla.org/en-US/firefox/
http://msdn.microsoft.com/en-us/default.aspx
Mozilla, Microsoft и Apple находятся в трех разных уголках мира разработки программного обеспечения, с точки зрения... ну... всего. Иногда я склонен думать, что эти три больших парня делают вещи просто чтобы не соглашаться друг с другом. Но если они следуют общей практике, это должно иметь смысл...
Если вы беспокоитесь о симпатичных URL-адресах для поисковых систем, обратите внимание, что большинство основных поисковых систем способны распознавать язык во время синтаксического анализа, поэтому, если использование определенного языка не является действительно важным аспектом, вам не нужно беспокоиться о поиске. дружественный двигатель.
- Подход 1: ИМХО хорошо, когда вы хотите запустить все статьи на всех языках одновременно. Но затем, когда вы вносите изменения в одном месте, вам нужно идти во всех местах и делать те же изменения.
- Подход 2: Оптимально для таких применений, как Википедия, где разные языки означают реальные разные веб-сайты (статьи - не переводы друг от друга, а скорее другой контент)
- Подход 3: Хороший выбор, если вы обычно запускаете на каком-то языке, а переводы приходят позже (например, в случае Google). Вы можете использовать язык по умолчанию в случае, если язык не указан, или даже сохранить его в сеансе, чтобы сохранить его среди изменений страницы.
Я хотел бы добавить один, который мы выбрали для www.openimages.eu:
4)
www.mydomain.com/articles/random.en
www.mydomain.com/articles/random.nl
Но лучше всего, конечно, слушать предпочитаемый язык, который браузер сообщает в своем запросе:
Accept-Language nl,en;q=0.7,en-us;q=0.3
и по умолчанию обслуживать ваши страницы на этом языке, если он доступен. Вы можете предоставить пользователям возможность выполнять действия ".en" или ".nl".
Я думаю, что это будет зависеть от вашей среды. Вы генерируете одни и те же страницы на нескольких языках, используя веб-фреймворк с базой данных, или у вас есть статические страницы?
Во многих распространенных веб-фреймворках (rails или symfony) вы можете настроить правила маршрутизации для #1, которые будут автоматически заполнять параметр языком, который контроллер будет затем использовать для генерации соответствующего контента. Конечно, три тоже подойдут, но, на мой взгляд, это немного отвлекает.
2 особенно уместно, если вы вызывали перенаправление на уровне веб-сервера, и имеет преимущество, заключающееся в том, что URL-адреса могут быть разрешены или не потеряны в настройках языка вашего пользователя. Другими словами, ссылка на /home приведет вас к правильной языковой версии "домашней" страницы.
Последний вариант - сохранить язык в качестве предпочтения пользователя в файле cookie, а не заполнять его в URL.
Я не знаю, есть ли "лучшая практика" в этом случае, поскольку это, вероятно, сводится к личному мнению.
Для меня я бы предпочел третий вариант, так как загружается действительно та же страница, вы просто изменяете содержимое с помощью параметра GET. Использование отдельного URL (а не параметра) означало бы для меня, что это совершенно отдельная страница / ресурс, чего в данном случае не будет. Вы также, вероятно, получите поисковые системы, индексирующие страницу несколько раз на разных языках и т. Д. (Хотя, возможно, это то, что вы хотите).
Поисковые системы считают поддоменами независимые веб-сайты. Я не уверен, как это влияет на SEO, хотя.
Первый имеет больше смысла. Потому что, если кто-то хочет перейти непосредственно на вашу страницу, и он / она может просто напечатать blabla.com/en и достичь того, что он / она хочет...
Я далек от знания "правильного" ответа (полагаю, что его нет), но, как вы просите комментарии, вот мой:
URL (или URI) - это то, что описывает или идентифицирует ресурс. Если я правильно помню, URL не должен зависеть от того, как должен отображаться ресурс (HTML, XML, JSON и т. Д.).
Вы также можете рассмотреть язык как способ указать, как должен отображаться ресурс.
Поэтому, на мой взгляд, последний вариант, а именно указание языка в качестве параметра, был бы более подходящим.
Если вы ищете "дружественные для поисковых систем" и "красивые" URL-адреса, вам следует избегать немаскированных параметров GET. Они не так хороши для глаз, как поддомен или подкаталог, и не совсем подходят для SEO.
Имея это в виду, я бы выбрал поддомен. Вы получаете простой, обычный "переключатель" для изменения отображаемого языка, и он не скрывается в середине вашего URL. Очень легко обнаружить и изменить.
Я бы определенно пошел на
www.mydomain.com/articles/random?lang=en
www.mydomain.com/articles/random?lang=nl
потому что более естественно сказать: "эта ссылка (полная ссылка) на английском или голландском языке".
В противном случае (domain/lang/restof url) создается впечатление, что у вас есть какая-то структура, которая содержит разные вещи для en и nl. То же самое относится к lang.domain/...