Проблема создания сайтов с разными версиями языков и стран отнюдь не нова, практически все крупные сайты уже давно с ней столкнулись. Каждая компания выбирает свое решение, мы кратко остановимся на основных вариантах и посмотрим, как решить эту задачу лучшим образом.
Варианты построения URL-ов
Конечно, в жизни существует больше групп, например, часть сайтов хранят региональные настройки в cookie-файлах, другие передают параметром ?lang=ru, однако это непопулярные решения и основными являются:
1. Версия сайта на другом домене:
example.com, example.ru
Самый кардинальный способ. Этот вариант может быть удобен компаниям, имеющим локальные представительства в разных странах и работающих относительно независимо от главного офиса, например, на другом движке сайта.
2. Версия сайта на поддомене:
ru.example.com, ua.example.com
Очень похож на предыдущий вариант, но легче в администрировании. Эти два варианта легко реализуются на физически разных хостах, поэтому могут быть размещены в разных странах.
3. Версия сайта в подкаталоге:
example.com/ru/, example.com/ua/
Самый простой способ, но разделить на разные серверы сложнее.
Часто возникающий вопрос, особенно у администраторов, впервые сталкивающихся с задачей создания мультирегионального сайта, состоит в том, какой подход выбрать для построения структуры URL. Дать однозначный ответ невозможно, слишком много разных факторов влияет на решение, однако, субъективное мнение таково: если ваш сайт для разных стран и языков будет работать на одном движке, используйте третий вариант. Он гораздо удобнее в работе для типичного проекта, к тому же, по этой же схеме работают и такие гиганты, как microsoft, ibm, apple и множество других. Подробная информация по построению URL-структуры легко находится на сайтах поисковых систем, поэтому детально останавливаться на ней нет смысла.
Концепция мультирегионального сайта
Итак, мы хотим создать сайт, который будет, предположим, работать в России, Украине и США. Языками, на которых будет работать наш сайт, будут русский, украинский и английский. Для построения URL-структуры берем третий вариант.
Обычно в примерах Гугла и Яндекса фигурируют простые и ограниченные схемы работы, как-то: в США показываем сайт на английском, в России — на русском, во Франции — на французском и так далее:
example.com/en-us/
example.com/ru-ru/
example.com/fr-fr/
Однако в реальной жизни появляются новые вопросы. А что делать для Украины, какой язык будем показывать? Есть русский и украинский. Хорошо, не проблема, добавляем новую связку
example.com/uk-ua/
А если нужно запустить версию сайта еще и в Канаде? Добавляем еще варианты с английским и французским:
example.com/en-ca/
example.com/fr-ca/
Короче говоря, выясняем, какие языки будем предоставлять для нужной нам территории и добавляем связки «язык — страна».
По этой схеме, кстати, работают и версии сайтов упомянутых компаний:
Microsoft: www.microsoft.com/home/en-ca/locale.aspx
Apple: www.apple.com/choose-your-country/
IBM: www.ibm.com/planetwide/select/selector.html
Казалось бы, вот она, идеальная схема работы, тем более, крупнейшие компании по ней работают — а уж там-то умные головы сидят, они-то все-все продумали. Однако, не все так просто. Хотя мы и близки к построению многорегионального сайта, у нас все еще остались проблемы, которые в свете растущего космополитизма и интернационализации будут становиться все важнее и важнее.
Проблема с эмигрантами и высокомобильными людьми
Вернемся к нашему исходному примеру. Очевидно, что в США проживает много русскоговорящих и работать многие из них предпочтут с русскоязычной версией вашего сайта. Вариант «пусть перейдут на русскую версию сайта, example.com/ru-ru/» неверен, потому что они хотят видеть, например, цены на вашем сайте в долларах, видеть американский телефон, адрес и прочую контактную информацию, в общем, видеть все то же, что видят посетители example.com/en-us/, но при этом чтобы все было на русском языке.
Хорошо, можно создать еще одну связку языка со страной:
example.com/ru-us/
Да, но найдутся украинские эмигранты, которые предпочтут работать на американской версии, используя украиноязычную версию сайта. Естественно, многие на этом этапе махнут рукой и скажут «их мало, обойдутся». Однако, какой смысл снижать удобство работы с сайтом, ведь удобство пользователей — привязанность к вашему сайту, если человеку удобнее читать на украинском, он наверняка предпочтет ваш сайт аналогичному сайту конкурента. Тем более, у нас ведь уже есть перевод на украинский, какая проблема добавить и его? Хорошо, делаем еще одну версию:
example.com/uk-us/
Так, стоп, а ведь есть же и те, кто переехал из США в Россию, почему бы и им не дать возможность работать на английском? А ведь еще наверное есть и украиноязычные, живущие в России. Все эти примеры подводят нас к тому, что правильная схема работы сайта получается тогда, когда я сам могу выбрать язык и регион.
Вот, к примеру, сайт Майкрософта. Простой анализ показывает, что всего нам предлагается 96 связок «язык — страна», при этом языков — 38, а стран — 93. То есть выбрать другой язык можно всего лишь для нескольких стран, например, для Канады (английский и французский). Это смешно, но при огромном числе русскоговорящих жителей на Украине, можно выбрать только:
Россия — Русский
Україна — Українська
И всё! Выбрать «Украина — Русский» попросту нет возможности, при том, что преобладающий язык общения на Украине — русский. Если бы Майкрософт предлагал все возможные языки для любой страны, ему пришлось бы на странице выбора разместить 93 × 38 = 3534 связки «язык — страна». Естественно, что найти нужное на странице с такой простыней текста будет затруднительно.
Аналогичная жесткая структура работает и для упомянутых Apple и IBM.
И каков вывод?
А вывод очень прост — не надо создавать жесткие связки языков и стран. При первом заходе на главную страницу, мы автоматически определяем IP пользователя и его страну. Поскольку почти во всех случаях будет достаточно определить только страну (город нам пока не нужен), то можно использовать бесплатные базы, предоставляемые, например, MaxMind-ом. На основе данных о стране посетителя мы показываем ему версию сайта на самом распространенном языке в данной стране. А дальше пользователи сами выберут, на каком языке им удобнее работать.
И как поисковики отреагируют на это разнообразие?
Google и Яндекс предоставляют владельцу сайта возможность объяснить поисковику, что сайт работает для разных стран и языков, поддерживая атрибуты rel=«alternate» hreflang=«x». Таким образом, если на вашем сайте реализован свободный выбор страны и языка, все возможные варианты нужно добавить на каждую страницу. Это должно помочь поисковику разобраться, какую страницу в результатах поиска нужно показать пользователю. Для нашего примера будет так:
<link rel="alternate" hreflang="x-default" href="http://example.com/">
<link rel="alternate" hreflang="ru-ru" href="http://example.com/ru-ru/">
<link rel="alternate" hreflang="ru-us" href="http://example.com/ru-us/">
<link rel="alternate" hreflang="ru-ua" href="http://example.com/ru-ua/">
<ink rel="alternate" hreflang="uk-ru" href="http://example.com/uk-ru/">
<ink rel="alternate" hreflang="uk-us" href="http://example.com/uk-us/">
<ink rel="alternate" hreflang="uk-ua" href="http://example.com/uk-ua/">
<link rel="alternate" hreflang="en-ru" href="http://example.com/en-ru/">
<link rel="alternate" hreflang="en-us" href="http://example.com/en-us/">
<link rel="alternate" hreflang="en-ua" href="http://example.com/en-ua/">
Как разработчики планировали использовать эти атрибуты для сайтов с большим количеством языков и стран, неизвестно. Ведь в случае с Майкрософтом пришлось бы добавить 3535 строк на каждую страницу сайта. Почему нельзя было сделать это, например, отдельным файлом, как sitemap.xml? Зачем это на каждую страницу добавлять? Однако, что есть, то есть. Единственным вариантом в таком случае видится закрытие от индексации всех страниц, кроме основной связки «язык — страна». Тогда, например, вместо последних трех строк из примера выше останется только
<link rel="alternate" hreflang="en-us" href="http://example.com/en-us/">
Конечно, это приведет к тому, что русскоязычный пользователь в США не увидит в результатах поиска страницу
example.com/ru-us/
Скорее всего, ему будет предложена одна из таких страниц:
example.com/ru-ru/
если будет искать на русском, и
example.com/en-us/
если будет искать на английском.
Однако, даже в этом случае мы оставляем возможность сменить язык или страну на нужные пользователю, поэтому, в конечном счете, задача локализации будет решенной.
Большинство же сайтов предполагает свою работу в нескольких странах и максимум на 3—4 языках, поэтому можно спокойно пожертвовать дополнительным добавлением десятка строк с тегами для всех версий сайта. С Википедии можно взять правильные коды языков и стран.
Автор: timetogo
