Как сделать мультиязычность php
Добавил пользователь Евгений Кузнецов Обновлено: 05.10.2024
Здесь могла бы быть ваша реклама
Помог: 3 раз(а)
Секрет
Теперь, когда вы уже наверняка второпях отправили свой запрос,
я расскажу вам простой секрет, который сэкономит вам уйму ожиданий,
даже если первый ответ по теме последуем сразу же.
После этого приходится начинать уточнять этим неграмотным что мне надо.
Они что, сами читать не умеют? А уточнять приходится.
И иногда пока они переварят то что я им скажу проходит и не одна ночь..
Уверен что если бы я им сказал что у меня есть
фиолетовый квадрат, и нужно превратить его в синий треугольник
и я пытался взять кисточку, макнуть в банку и поводить ей по квадрату
но почему то кисточка не принимала цвет краски в банке,
то на мой вопрос - где взять правильные банки мне бы ответили гораздо быстрее
предложив её открыть, а не тратить еще стольник на жестянку.
Поэтому с тех пор я строю свои вопросы по проверенной давным давно схеме:
Что есть
Что нужно получить
Как я пытался
Почему или что у меня не получилось.
На последок как оно происходит на форумах
Отредактировано модератором: Uchkuma, 26 Апреля, 2011 - 10:21:12
А вот и сам плагин, реагирует на событие OnHandleRequest:
То есть, при указании параметра ?lang=en или ?lang=ru любой ссылке — контекст сайта переключается, а вместе с ним и язык — и это запоминается в сессию, то есть ссылка больше не нужна.
Прощай геморрой с настройками!
Бонус в виде сниппета для вывода ссылки на переключение:
Поисковики такой сайт индексируют нормально — ведь на каждой странице есть ссылка на другую языковую версию, и урл отличается.
То есть в индексе страницы с разным ?lang=(en|ru) и с разным содержимым.
Два месяца назад пришла очередная идея по извечному вопросу всех веб-мастеров — как расширить аудиторию сайта и привлечь новых уникальных посетителей.
А идея состоит в том, чтоб вылезти из РФ на просторы Запада, Востока, ну и дальше по глобусу, то есть сделать свой сайт мультиязычным и посмотреть — что из этого получится.
Сразу скажу — мне это и удалось и получилось, чего и вам желаю. Читайте статью.
Проблем, связанных с реализацией этой идеи, набралось достаточно.
Теперь, когда большинство из них решены, настало время поведать об этом всем тем, у кого нет-нет возникают подобные желания, чтоб по возможности облегчить им сей тернистый путь.
Тернистый — без преувеличения.
Возможно, особо глубоких и разносторонних познаний в этой области я и не выкажу, но зато и мусора у вам в голову не накидаю.
Всем, думаю, знакомо закипание мозгов, в процессе окучивания гугла, когда море инфы никак не не получается втиснуть в берега собственных возможностей и желаний.
Я покажу конкретное, рабочее и успешное решение задачи.
Итак, первым делом из гугла вылез вопрос: каким способом создать иноязычную версию сайта.
1. Замутить несколько поддоменов и создать несколько разноязыких сайтов с перелинковкой.
Способ вполне рабочий, но меня он не устроил потому, что мой сайт очень маленький, и хотелось бы набрать ему побольше веса, а не дробить на несколько частей.
2. Окучивание своей CMS на предмет создания отдельных папок с разными языковыми версиями и прочими заморочками, обзываемыми страшными словами синхронизация, локализация и т.п.
Мне этот метод не подошёл, так как в программировании я вероплавка, а постигать глубины нет ни времени, ни особого желания.
3. Воспользоваться плагином, который должен всё за меня создать, синхронизировать и локализовать.
Деваться некуда. Хотя, по полученному в дальнейшем опыту, выяснилось, что плагин никому и ничего не должен.
Это вы должны, если хотите, чтоб за вас всё было сделано, сперва заплатить неплохую денежку, а потом уж получить неплохой плагин.
А если вам платить не хочется, или как я, принципиально отвергаете денежные вложения в сайт, то и получите что нибудь простенькое, да не особо функциональное.
Короче, и понапрягаться придётся, и погуглить, и попеределывать. Хотя, вам-то уже, надеюсь, не придётся.
Как бы там ни было, а методом тыка и веб-матери был выбран бесплатный плагин Polylang. Вроде и инфы много, и поддержка сообщества обещана.
Только FAQ, и обещание всесторонней помощи после приобретения Pro версии.
Но мы тоже не пальцем деланные, и в конце концов данный плагин меня полностью устроил, и даже понравился, так что сейчас подробно расскажу, как этого зверька приручить и получить от него то, что нам надо.
Установка стандартная, так что сразу перейдём к настройкам.
Софт имеет 4 опции, начнём с Languages — выбор языка, или нескольких языков, которые вы хотели бы предложить своим посетителям.
Здесь всё просто и понятно. Плагин определяет все языковые папки, имеющиеся в вашей сборке WordPress и выводит их в списке, который открывается в первом поле опции.
Если какого либо нужного вам языка нет, то гуглите по запросу Как добавить языковую папку в WoedPress.
Как только вы выберите нужный язык, все остальные поля, которые ниже, заполнятся автоматом.
Вам нужно только проставить цифру в последнем поле Order. Обычно основному языку ставится 1, а остальным в порядке возрастания, по мере добавления.
В поле справа будут отображаться все установленные языковые версии, и некоторые данные по ним.
Там же, кстати, их можно удалить, в случае чего.
И ещё, как я заметил, плагину нужна некоторая раскачка, как прогрев для машины, но только в самом начале работы, потом шпарит четко.
А по началу путал флаги языков, и с первого раза не сохранял перевод некоторых элементов интерфейса.
Следующий пункт Strings translations пока пропустим, и перейдём в Settings (Настройки).
1. URL modifications (Изменение URL)
Здесь выбираем структуру адреса переводов. Все возможные структуры показаны, я выбрал так:
И сохраняем настройки.
2. Detect browser language (Определение языка браузера)
Плагин определяет местоположение и предполагаемый язык пользователя, чтоб выдать ему соответствующую языковую версию страницы.
Эту опцию лучше деактивировать, так как и определить может неверно, и вообще, в дальнейшем станет ясно, что эта опция нам бесполезна.
Оставляем активированной, так как картинки останутся прежними.
Доступно только в Peo версии
5. Synchronization (Синхронизация)
По умолчанию всё синхронизировано — так и оставим.
6. WPML Compatibility (Совместимость с WPML)
Есть такой довольно крутой, и довольно дорогой плагин переводчик WPML, так к вот, наш парень может работать совместно с ним.
Может для каких-то крутых порталов и актуально.
7. 8. и 10. — для Pro версии.
Здесь ставим галочку в чекбокс, чем даём согласие на удаление всех следов плагина, в случае сноса его самого. Как будто может возникнуть желание оставить пару соплей, в случае чего.
В настройках всё. Переходим в Strings translations (Строчные переводы).
Вот тут уже интереснее — перевод интерфейса сайта, как раз то, что надо, и чего без плагина я сделать не смогу.
По умолчанию Строчные переводы откроются на том языке, у которого вы установили Ордер № 1. Кнопка переключения языков находится в верхней части окна.
Всё просто — выбираем нужный язык, и переводим всё что есть в окнах справа, кроме кода ссылок, хотя для экзотов, возможно, придётся менять и их. Точно не знаю.
А есть там весь интерфейс: и заголовок и описание, и все виджеты из сайдбаров. Что не поместилось на первой странице, есть на следующей.
Но прежде чем перейти на следующую страницу, нужно в самом низу поставить галочку в чекбоксе и сохранить изменения. На каждой странице. Как в кредитном договоре.
Что мне особо понравилось, так это возможность создания различных интерфейсов для разных языковых версий.
А конкретно — можно менять все данные и оформление в виджетах.
Можно для России и ближнего зарубежья вывести одно меню в сайдбаре, а для всех остальных другое и т.п.
Допустим, некоторые рубрики и статьи сайта рассчитаны только на родного россиянина, и никак не вяжутся со всем остальным миром.
Зачем же их переводить и показывать этому остальному миру?
Значит в виджет, который показывает эти рубрики и статьи, можно вбить что-то другое, или вообще оставить пустое поле.
Тогда в русскоязычной версии всё будет показываться как обычно, а в иноязычной — то что вы создадите при переводе.
Вот так. Для своих можно сделать одну навигацию, а для не своих другую.
Вроде как отдельный сайт в сайте! Как надо перелинкованный с основным контентом. И в то-же время это один сайт.
Теперь несколько слов о том, как сделать перевод, если не хочется платить переводчику, а свои знания, например в китайском — полный нуль.
Тут уж придётся поработать. Но за большой текстовый контент лучше не браться.
Например, вот этот пост, для перевода придётся или сократить до предела, или вообще не показывать на другом языке.
Итак, во-первых — самый лучший перевод даёт Гугл, и открыть этот переводчик нужно в двух окнах, чтоб в одном делать перевод с русского на нерусский, а в другом обратно, таким образом подбирая и составляя фразы.
Во-вторых — проверку перевода можно сделать забивая переведённые нерусские словосочетания в поиск, выбирая из выдачи нечто похожее и проверяя выбранное опять же в переводчике.
Та ещё работёнка.
Первели? Значит оформление страницы готово. Осталось решить с контентом. И вот тут начинается самое интересное и необычное.
Переходим в Записи. Тут уже есть флажки выбранных языков и плюсики под каждым флажком, напротив каждой записи.
Стоит нажать на плюсик, и откроется Добавить запись, пустая страница, привязанная к той записи, напротив которой мы нажали плюсик.
Справа указан язык, на который мы будем делать перевод, а чуть пониже — язык с которого делается перевод.
Я, кажется, ещё не сказал ранее, что перевод контента делается самостоятельно, т.е. плагин сам ничего не переводит.
Ну в общем, по идее, вставляй перевод в редактор, публикуй, и всё, новая статья на другом языке и с другим адресом готова.
Там ещё у плагина есть переключатель языков для посетителя, в виде флажков, видели небось такие, его можно поставить в виджете в любое место страницы.
Вроде всё как по маслу, но не стоит расслабляться, так как всё это, как оказалось, работает совсем не так, как было задумано, и не решает изначально поставленных задач.
А задача-то была, если помните, нарастить массу сайта статьями и привлечь новых иностранных посетителей.
На деле же получилось вот что.
Статьи-то публикуются, вот только в поиске им появиться оказывается не суждено, так как они остаются в недрах сайта чисто в качестве переводов, а вот в карте сайта XML Sitemap они не появляются, и не пингуются и не индексируются.
Может когда нибудь бот их и обнаружит и проиндексирует, но тут есть ещё один нюанс — переводы публикуются с тем-же числом, которым была написана статья.
Получился странный предмет — новый пост вроде есть, но его как бы нет.
По идее — всё верно. Есть статья и есть её перевод, в чём проблема?
А проблема в том, что не видать нам с неё сколь нибудь ощутимого трафика, как своих ушей.
Безусловно, появилось некоторое удобство для некоторых посетителей, и на этом всё.
Вот так! За что старались! Иностранные ключи подбирали, в из сетях регались и т.д. и т.п.
Но, этой статьи не было-бы, если бы не было решения. И решение нашлось.
А состоит оно в том, что на этапе публикации перевода, или новой статьи нужно частично отказаться от услуг плагина.
1. Открываем в режиме редактирования, выбранную для перевода запись.
2. В новой вкладе, из меню консоли, не с помощью плюсика, а из консоли, открываем Добавить запись.
В результате у нас открыто две вкладки — в одной статья в режиме редактирования, та что будем переводить, в другой редактор с пустыми полями.
3. Во вкладке с пустым редактором переключаем верхним переключателем язык с русского на требуемый.
4. Справа, в виджете Рубрики добавляем новую рубрику, с названием на требуемом языке.
5. Копируем заголовок и статью из первой вкладки и вставляем в пустую.
6. Начинаем работать над переводом во второй вкладке, то есть по мере создания, убираем русский заголовок и текст и вводим перевод.
7. Связываем обе статьи переключателем языков.
Вот тут остановимся поподробнее.
Так как не все статьи сайта планируется переводить на другие языки, и навигация разных версий будет отличаться, то и виджет-переключатель плагина, устанавливающийся на всех страницах, нас не устроит.
Переключатель нужен только на тех страницах, которые переведены.
Вопрос решается предельно просто.
Пишем свой переключатель, и вставляем его в обе статьи после текста.
Моих познаний на это с лихвой хватило.
Пример переключателя, а так-же обе языковые версии можно посмотреть вот на этой странице, так как данную статью я пока переводить не планирую.
Обратите внимание так-же на адреса, заголовки и сайдбары. В русскоязычном варианте всё как обычно, а в англоязычном — всё как сделано с помощью плагина.
А для тех, кому своих знаний недостаточно, я привожу полный код переключателя.
Вам нужно будет только поставить свои адреса во всех ссылках. Ссылки должны вести со станицы на страницу — не перепутайте.
С англоязычной на русскую и наоборот.
Картинки вырезаны в Яндекс. Картинках — их там много всяких.
Переключатель ставится на обе страницы, затем первая обновляется, а вторая, новая, публикуется в новой иноязычной рубрике.
Теперь идем в XML Sitemap и проверяем, появилась ли там новая статья.
Всё нормально. Статья появилась и все поисковики извещены о рождении новой статьи на моём сайте, которая будет незамедлительно проиндексирована и помещена в поисковую выдачу.
А вот на какую позицию — это уже отдельный сеошный разговор. Здесь скажу только, что у меня уже пошёл трафик из-за "бугра"
Не большой, но лиха беда начало — сделано пока всего-то 20 постов.
Получившийся мультиязычный сайт очень удобен в управлении из консоли.
После выбора языка верхним переключателем, в Записях отображаются только записи, опубликованные на соответствующем языке.
В Рубриках — только рубрики созданные на этом языке. Та же ситуация со страницами и с меню Станицы.
В старых шаблонах это горизонтальное вордпресовское меню в пределах шапки сайта.
Тут то же, что и с рубриками. Переключаем язык на нужный, создаём новые страницы, на этом языке, затем переходим Внешний вид — Меню, там будет пусто, создаём новое меню и добавляем в него новые страницы.
Всё. На данном языке в горизонтальном меню будут только страницы, созданные на этом языке.
Как видите, мы действительно создали отдельный сайт, с отдельной админкой, в пределах своего сайта и в то-же время сайт остался единым и число его записей стало увеличиваться.
Число посетителей тоже растёт, причём показатель отказов уменьшается.
Прошёлся по посетителям из США и Канады — время на сайте от 00.50 до 2.00 мин. Есть и нулевые, но не много.
Что и требовалось.
В дальнейшем можно будет создать ещё парочку языковых версий, и перемещаться между ними с помощью переключателя языков.
Не знаю как вам, а по моему — просто здорово. И как после такого не отнестись с уважением к плагину Polylang.
Желаю успехов в создании мультиязычного сайта.
PS. Прошло ровно три месяца со дня публикации статьи и начала работы с переводами. Заглянул в Метрику География.
И вот результат.
До этого США были где-то в конце списка с 3-5 визитами, а теперь вышли на 5-е место. Переведено 36 постов.
Практически все уважающие себя и популярные CMS или FrameWork имеют функционал мультиязычность. Главная цель i18n как и мультиязычности - предоставить сайт посетителям на удобном им языке. Давайте эту тему более подробно рассмотрим.
Определение языка и страны пользователя
Страну пользователя можно определить по IP через geoip. Язык пользователя в элементе массива $_SERVER, а именно:
Хранение и вывод указанного языка
Первый этап через который проходят многие заказчики - давайте переведём через Google Translate. Просто вбейте в гугле смешной перевод гугл переводчика и насладитесь перлами :) . Демонстрация существующей ошибки вот уже более нескольких лет, данный пример взят лишь потому, что он не исправляется:
Просто пояснение, М - это не только Михаил, но и Максим, Мартин, Макар, Марат и другие. Отсюда вывод прост, что нельзя пользоваться автоматическим переводчиком. А если нет в штате переводчика, то лучше и вовсе не переводить, чем делать это лишь бы как.
Часовой пояс
Если взять тему формата времени, то ничего сложного в этом нет, прописали в выводе формата времени вызов второго класса - определение страны по IP, и формат времени автоматом будет выводить нужный вариант. А вот с часовым поясом проблема другая, дело в том, что определить часовой пояс поможет лишь JavaScript:
Как Вы уже догадались, определять часовой пояс необходимо через 3 значения: дата записи на сервере (зависит от формата и часового пояса), часовой пояс у клиента, и "+5" смещение часового пояса сервера. Вот таким не сложным образом я произвожу смещение времени:
Но этот способ имеет и минусы, дело в том, что часовой пояс меняется. Так, допустим, РФ отменил переход часового пояса, а значит не обновляемые системы будут давать неправильный часовой пояс, а значит и неправильное время. Так же кривизна рук пользователя, который не смог корректно настроить часовой пояс на своём компьютере, из-за чего будут у него проблемы и на других сайтах. Пути решения парочку, первый рассказывать и обучать людей как правильно настраивать часовой пояс на его компьютере, именно этим и занимаются в тех.поддерже Google, Microsoft и FaceBook, иначе почему они не рассматривают мои заявки о неправильной работе их фильтров :) . Второй более популярный и грамотный - давать возможность пользователю самому выбрать свой часовой пояс, то есть смещение будет идти не относительно getTimezoneOffset у клиента, а на уровне сервера в зависимости от настройки в его личном кабинете. Но по умолчанию ставится всё равно часовой пояс клиента.
Работы много, но работа не сложная. Тут нужна внимательность и усидчивость, удачи!
Комментарии о School-PHP (0):
В основном в данном блоке идут посадочные страницы с целью привлечения аудитории из Google и Yandex. Под каждый поисковый запрос создаётся отдельная страница, в итоге мы получаем много статей на разные темы, при этом полезны только для того, кто был заинтересован именно этим запросом. Для остальных же всё же советую сосредоточиться на прохождении общей программы курса!
Технически использование многоязычности не сложная задача, но влечет скрытые риски для SEO. О принципах безопасного внедрения мультиязычности и тонкостях ее настройки.
Статья из блога АРТИЗАН-ТИМ
Запуск мультиязычной версии сайта — важный шаг для проектов, нацеленных на глобальный рынок. Использование многоязычности также актуально для локальных проектов, в странах, где жители разговаривают на нескольких языках. С технической точки зрения — это не самая сложная задача, но на поверку она влечет немало скрытых рисков для SEO. О принципах безопасного внедрения мультиязычности и тонкостях ее настройки — рассказываем в нашем материале.
Три способа реализации мультиязычности
Существует три основных способа запустить многоязычную версию сайта. На преимуществах и недостатках каждого из них остановимся более подробно.
Отдельные версии на разных доменах
Речь идет о том, чтобы под конкретную языковую локализацию сделать отдельный сайт. С точки зрения лояльности поисковиков и удобства для пользователей — это самое эффективное решение. Но, как несложно догадаться, такой способ более сложный в плане технической реализации и на порядок затратнее.
Под каждую локализацию компания реализовала отдельную версию сайта. Доменные зоны наглядно отображают, на какую языковую аудиторию ориентирован каждый проект.
С точки зрения SEO преимущества такой стратегии в том, что версии ресурсов полностью автономны и не зависят друг от друга в вопросах продвижения. При этом поисковики лучше ранжируют сайты на национальных доменах в локальной выдаче. В то же время такая реализация многоязычности ― палка о двух концах. Из плюсов вытекают минусы, которые при отсутствии серьезных корпоративных бюджетов делают эту стратегию неподъемной.
В этом случае необходимо с нуля разработать несколько версий сайтов. Для каждого ресурса нужно приобрести отдельное доменное имя, которое к тому же может оказаться занятым в какой-то из зон. В дальнейшем каждая версия сайта будет нуждаться в отдельном администрировании и автономном SEO. Таким образом, бюджет на веб-поддержку и поисковое продвижение, по сути, придется умножить на количество имеющихся сайтов. Из-за своей организационной сложности и дороговизны к такому варианту прибегают редко. Обычно, это делают только крупные международные компании, с серьезными бюджетами на веб-разработку и продвижение своего бренда.
Языковые версии на поддомене
Поддомены (домены третьего уровня или субдомены) используют для создания отдельных версий сайта внутри основного проекта. Это еще один популярный способ внедрения мультиязычной архитектуры. В этом случае языковая версия сайта отображается в адресной строке через точку слева от основного названия. К слову, на поддомены могут быть вынесены не только версии сайта на другом языке, но и региональные филиалы, например, того же магазина или функционировать разделы сайта.
Такой способ создания мультиязычности — нечто среднее между отдельным сайтом и использованием разделов и папок (об этом ниже). Ему свойственны свои особенности, которые необходимо принимать во внимание. В плане технической реализации здесь не все так сложно (и дорого) как с сайтами на разных доменах, но и не так просто как может казаться изначально.
Версия на поддомене — это полностью самостоятельный сайт с отдельной базой данных. Такая архитектура требует больше ресурсов на оптимизацию, чем, если бы речь шла о создании разделов. Помимо основных работ (проработка структуры, наполнение контентом, заполнение метатегов и пр.) для всех поддоменов необходимо создать отдельный robot.txt и sitemap.xml. Что касается ссылочного веса, то хотя он и перераспределяется между основным доменом и поддоменами, происходит это не так эффективно. Передача веса от домена становится возможной главным образом за счет грамотной перелинковки, поэтому ей уделяют основное внимание в рамках внутренней SEO-оптимизации.
Чтобы улучшить пользовательский опыт, можно настроить специальный скрипт, который будет распознавать IP-адрес посетителей и автоматически перенаправлять их на нужную версию сайта.
Несмотря на все вышеописанные сложности, мультиязычная архитектура, созданная по принципу домен+поддомен, обладает важными преимуществами. При такой схеме имеется возможность переноса данных на отдельный сервер. Когда речь идет о крупных ресурсах, это становится стратегическим преимуществом, позволяющим снизить нагрузку на сайт и оптимизировать скорость его загрузки.
Размещение поддомена на отдельном сервере может сыграть на руку проектам, которые имеют стабильную аудиторию по всему миру. Например, разместив англоязычную версию сайта на иностранном сервере, а русскоязычную — у местного хостера, можно добиться оптимальной скорости загрузки сайта для всех пользователей, вне зависимости от их географической удаленности.
Отдельно стоит отметить вопрос аналитики. В случае с поддоменами она существенно упрощается, поскольку нет необходимости сегментировать данные для поддерикторий — настройка счетчика реализуется для всего поддомена.
Создание разделов на основном сайте
Создание категорий и папок на основном домене — самый популярный способ реализации мультиязычности. Такая архитектура дает больше всего преимуществ с точки зрения поискового продвижения и внедряется значительно проще, чем описанные выше варианты.
Поскольку действие происходит в рамках общего домена — ссылочный вес эффективно перераспределяется между всеми страницами. Версии документов на другом языке наследуют трастовость основного домена, что положительным образом сказывается на их позициях в выдаче. Ускоренная индексация страниц — еще один существенный плюс мультиязычной архитектуры, реализованной через папки и категории. Также, поскольку при таком подходе языковая версия является лишь одним из разделов домена — отпадает необходимость в создании отдельного Sitemap.
Реализация мультиязычности через разделы удобна тем, что изменения на сайте можно внедрить сразу на всех страницах. Это значит, что добавив какой-то функционал, например, на русскоязычной версии сайта, он будет реализован во всех остальных языковых адаптациях. С теми же поддоменами такого не получится — изменения на каждой версии придется вносить отдельно, что добавляет немало головной боли при проведении работ по внутренней оптимизации сайта.
Мультиязычность через разделы — это оптимальный вариант, если вы планируете использовать не два-три языка, а значительно больше версий. С поддоменами вы будете ограничены в этом вопросе, т.к. количество субдоменов зависит от настроек сервера. Разделов же может быть сколько угодно в рамках одного сайта. При этом не стоит забывать, что чем больше языковых версий используется на сайте, тем выше нагрузка на сервер, и потребуется больше дискового пространства.
Что касается практической реализации такого способа, то в большинстве случаев это делают автоматизированным методом, используя специальные модули, которые сами создают категории и папки под контент на другом языке. Во многих расширениях имеется возможность автоматического перевода страниц. Если такая опция отсутствует, это можно реализовать при помощи отдельных плагинов машинного перевода.
Таким образом, создание мультиязычности через папки — самый простой и доступный способ в плане реализации и наиболее эффективный с точки зрения SEO. Именно поэтому он используется на абсолютном большинстве многоязычных проектов. Но есть один существенный нюанс — в этом случае следует особенно ответственно подойти к разметке локализованных страниц.
Атрибут hreflang
Элемент в Sitemap.xml
Сообщить поисковым системам о локализованных версиях страниц также желательно с помощью карты сайта. Для этого в файл Sitemap.xml добавляют элемент , указывая в нем URL документа. В дочерних тегах прописывают ссылки на все языковые и региональные версии, включая саму страницу. Более подробно о том, как указывать в Sitemap страницы на других языках и для разных регионов можно почитать в официальной справке Google.
Оптимизация тегов
Корректная локализация тегов — еще один важный пласт работ, от которого во многом зависит качество SEO мультиязычного сайта. В идеале перевод Title, H1 и Description следует поручить профессиональному переводчику. Нечитабельные теги не только ухудшают CTR и наносят существенный урон поведенческим, но и могут расцениваться поисковыми системами как спам, что повлечет проблемы с SEO для всего сайта.
Владельцам проектов, которые не имеют возможности выделить ресурсы на перевод и вычитку метатегов, необходимо делать максимально короткие Title и H1 — так вероятность грубых ошибок при машинном переводе будет существенно ниже. Заполнением Description в таких случаях целесообразно пренебречь вовсе. Перевод тегов для страниц, которые генерируют больше всего трафика, целесообразно поручить специалисту.
Контент и другие нюансы языковой локализации
Использовать мультиязычность на сайте не имеет особого смысла, если его страницы останутся пустыми. Как и в случае с тегами, поручать перевод контента целесообразно специалистам. Когда такой возможности нет — единственной альтернативой остается машинный перевод.
Используя переводчик, старайтесь максимально упрощать синтаксис исходного текста — простые короткие предложения уменьшают вероятность некорректно переведенных конструкций. Сам текст лучше переводить предложениями или небольшими абзацами, это помогает улучшить результат на выходе. Также важно обращать внимание на грамматические ошибки в исходном тексте, поскольку алгоритм не распознает такие слова и оставляет их в непереведенном виде. Адаптацию контента для главной, основных категорий и трафикогенерирующих страниц уместно поручать специалисту.
Важно не забывать, что языковая локализация сайта также предполагает перевод всех интерфейсов. В противном случае пользователи не смогут полноценно взаимодействовать с ресурсом и обеспечивать хорошие поведенческие, которые напрямую влияют на позиции сайта в выдаче. В рамках языковой адаптации дополнительно проводят аудит структуры ресурса: определяют какие страницы имеют сугубо локальную специфику и не нуждаются в переводе, например, разделы с акциями, региональными предложениями и т.д.
Читайте также: