Содержание
Проблема создания сайтов с разными версиями языков и стран отнюдь не нова, практически все крупные сайты уже давно с ней столкнулись. Каждая компания выбирает свое решение, мы кратко остановимся на основных вариантах и посмотрим, как решить эту задачу лучшим образом.
Варианты построения 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/">
upd. В случае с Майкрософтом пришлось бы добавить 3535 строк на каждую страницу сайта. Чтобы не добавлять такое количество тегов на страницу, лучше поместить их в карту сайта. Пока не известно, поддерживает ли такое решение Яндекс.
Если нужна обязательная поддержка обоих поисковиков, приемлемым вариантом в таком случае видится закрытие от индексации всех страниц, кроме основной связки «язык — страна». Тогда, например, вместо последних трех строк из примера выше останется только
<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 языках, поэтому можно спокойно пожертвовать дополнительным добавлением десятка строк с тегами для всех версий сайта. С Википедии можно взять правильные коды языков и стран.
