Для начала давайте определимся, из каких фраз состоит сайт. Все слова, которые видны при просмотре сайта, являются либо фразами продукта, либо контентом (статическим и динамическим).
Выделенные на данном скриншоте области – это , остальные фразы – .
[spoiler]
О языках продукта
“1С-Битрикс: Управление сайтом” и “1С-Битрикс: Корпоративный портал” поставляются нами на трех языках: английский, немецкий и русский. При этом в русских дистрибутивах присутствуют русский и английский языки, в немецком – немецкий и английский, в английском – только англиский.
Нашими партнерами добавляются и поддерживаются локализации продукта на некоторых .
Для того чтобы ваш сайт “заговорил” на одном из имеющемся языке локализации, вам нужно добавить новый язык и загрузить пакет переводов через систему обновления.
Подробнее в .
Если вам нужен другой язык, то следует добавить новый язык в системе и своими силами перевести фразы продукта. Подробнее:
Что еще нужно знать
В продуктах Битрикс есть публичная часть, видимая посетителям сайта, и административный раздел – раздел, содержащий интерфейс для управления модулями системы, структурой, содержанием, посетителями и другими составляющими сайта.
В этом разделе присутствует кнопка, с помощью которой осуществляется переключение языка фраз продукта в административном разделе для данного пользователя.
Функционал, позволяющий переключать язык фраз в публичном разделе, в поставку продукта не входит. Пример реализации рассмотрим ниже.
Переключатель языка в публичном разделе
Рассмотрим один из вариантов реализации переключателя языка в публичном разделе.
Данный переключатель меняет язык отображаемых фраз продукта, и каждый посетитель может выбрать нужный ему язык.
В данном примере создадим переключатель на испанский. При этом в административном разделе у нас уже добавлен язык с идентификатором la, и загружен пакет локализации через систему обновлений.
- Добавляем следующий код в файл /bitrix/php_interface/dbconn.php
<? session_register("LANG_UI"); if(isset($_REQUEST['lang_ui'])) $_SESSION["LANG_UI"] = ($_REQUEST['lang_ui']=='en'?'en':'la'); if(!isset($_REQUEST['lang']) && isset($_SESSION["LANG_UI"])) define(LANGUAGE_ID, $_SESSION["LANG_UI"]); ?> - В секцию <head> пролога шаблона сайта (/bitrix/templates/<шаблон>\header.php) добавляем такой код
<script> function action_lang() { window.location = '?lang_ui=' + document.getElementsByName('Lang')[0].value; } </script> - Добавляем вывод переключателя в шаблоне, используя код
<?echo CLanguage::SelectBox('Lang', $_SESSION["LANG_UI"],'','action_lang()');?>
Переключение языка сайта не переводит имеющийся контент на требуемый язык, осущетсвляется лишь подключение фраз продукта выбранного языка.
Тем не менее, с помощью созданного переключателя можно влиять на язык меню и сообщений шаблона.
Для этого следует использовать дополнительный шаблон сайта и подключать в нем меню, которое переведено на второй язык, а также использовать языкозависимые фразы.
Для описания пунктов меню на требуемом языке следует создать отдельные .
Рассмотрим пошагово:
- Создаем копию шаблона сайта. Для этого просто дублируем папку с шаблоном в каталоге /bitrix/templates/. Например, шаблон сайта лежит в папке /bitrix/templates/light/, делаем копию /bitrix/templates/light_la/.
- Для удобства меняем описание шаблона light_la в файле /bitrix/templates/light_la/description.php.
- Для того чтобы подключался нужный шаблон сайта при переключении языка, в настройках сайта добавляем условие (вида $_SESSION["LANG_UI"]=='la') на подключение шаблона.
- Создаем новые типы для описания меню на требуемом языке. В нашем сайте используются top и left типы меню (указаны в настройках модуля Управление структурой), добавляем top_la и left_la
- В шаблоне light_la находим подключение компонентов меню (в файлах /bitrix/templates/light_la/header.php и /bitrix/templates/light_la/footer.php) и изменям типы меню
<?$APPLICATION->IncludeComponent("bitrix:menu", "horizontal_multilevel", array( "ROOT_MENU_TYPE" => "top_la", "MENU_CACHE_TYPE" => "N", "MAX_LEVEL" => "3", "CHILD_MENU_TYPE" => "left_la", "USE_EXT" => "Y", "DELAY" => "N", "ALLOW_MULTI_SELECT" => "N" ), false );?> - Далее нужно создать копии самих файлов меню в структуре сайта (в корне и разделах ) и перевести их на требуемый язык.
if (SITE_TEMPLATE_ID !== "bitrix24" ) |
if (SITE_TEMPLATE_ID !== "bitrix24_la" ) |
Сайты с многоязыковым контентом
Если требуется разделять контент по языкам, то следует использовать .
В первом случае создается дублирующий контент на втором языке. При этом статический контент (страницы и разделы) нужно разнести по папкам, например:
/
..RU
....О компании
....Сотрудники
....Новости
..De
....Über uns
....Mitarbeiter
....News
И добавить переведенные копии динамического контента. Для того чтобы переключался динамический контент следует настраивать компоненты на источник данных на нужном языке.
Например, чтобы на странице News показывались новости на требуемом языке, нужно настроить компонент новостей на инфоблок, содержащий новости на этом языке.
Переключатель языка должен перенаправлять в папку с контентом на другом языке.
При использовании многосайтовости для языковой версии создается дополнительный сайт, контент также дублируется для обоих сайтов. Преимущества и способ настройки многосайтовости описаны в документации по вышеуказанной ссылке.
Следующий вопрос, который задает заказчик - "А почему при смене языка мы не попадаем на ту же страницу, только на выбранном языке?". И здесь начинаются танцы с бубном...
{
$APPLICATION->IncludeComponent("bitrix:news", "", array(
...),
false
);
} elseif($_SESSION["LANG_UI"]=="en")
{
$APPLICATION->IncludeComponent("bitrix:news", "", array(
...),
false
);
} else {
// russian
$APPLICATION->IncludeComponent("bitrix:news", "", array(
...),
false
);
}
<? $NewsIblockId = 4; // en if(isset($_SESSION["LANG_UI"])) { switch($_SESSION["LANG_UI"]){ case 'ru': $NewsIblockId = 1; break; case 'es': $NewsIblockId = 2; break; case 'cn': $NewsIblockId = 3; break; default: $NewsIblockId = 4; break; } } ?> <?$APPLICATION->IncludeComponent( "bitrix:news", "", Array( ... "IBLOCK_ID" => $NewsIblockId, ... ) );?>И немного оптимизируем dbconn.php
if(isset($_REQUEST['lang_ui'])) { switch($_REQUEST['lang_ui']){ case 'ru': case 'es': case 'cn': $_SESSION["LANG_UI"] = $_REQUEST['lang_ui']; break; default: $_SESSION["LANG_UI"] = 'en'; break; } }Всё описанное выше касается исключительно перевода фраз в компонентах.
Для того что бы сделать сайт с мультиязычным контентом на, например, 10 языков, нужно
- Либо докупать 10 лицензий либо создавать 10 папок в корне - '/cn/', '/cz/', '/es/' и так далее для каждого языка.
- Потом мы что делаем? Копипастим контент основного сайта туда.
- Теперь начинаем долго и муторно переводить путаясь в уже переведённом контенте и непереведённом. Вы уже представляете структуру сайта? Одну минуточку...
- На КАЖДЫЙ инфоблок делаем 10!!! копий со своим контентом. Да-да, в скопированном в предыдущем пункте контенте нужно установить правильные ID соответствующих инфоблоков.
- И вот это только начало потому что при поддержке начинается сущий АдЪ и Израиль. Например сделать одну новость на 10 языках. Создаём десять елементов в десяти инфоблоках и... ну тут всё понятно, я думаю. Займёт на пару часиков рабочего времени.
Я жду того светлого момента, когда при редактировании элемента появятся закладки с установленными в системе языками. И в зависимости от языка будет выводиться соответствующий контент элемента. Но вряд ли дождусь.Поэтому берём бубен и идём писать свои мультиязычные компоненты на каждую страницу контента.
Кстати, клиенты корпоративного портала западного рынка зачастую интересуются именно способом переключения языка фраз продукта и меню, без дублирования контента. Мы сами имеем разные языковые версии основного сайта, при этом необходимости одновременного и зеркального дублирования информации у нас нет, поскольку разный рынок, маркетинг и тд.
Он-лайн торговля, пожалуй, единственная сфера, где вариант с переводом в самих элементах самый востребованный. Но и тут никто не мешает взять бубен и решить задачу, благо в Битрикс есть все необходимое: свойства, компоненты и возможность кастомизации.
Задач может быть много, а вариантов их реализации еще больше.
Я согласен, проект достаточно уникален и стандартного функционала там крохи, но "нативная" локализация в инфоблоках значительно упростила бы жизнь разработчикам, на мой взгляд.
Там три языка - один из них китайский. Для контент-менеджера пресс-службы был сущий ад когда надо было исправить существующу новость на китайском языке. Сейчас у нее есть вкладки, переключающиеся по языковым версиям.
Странно, что проприетарная платформа такого масштаба и с такой историей развития до сих пор не имеет вменяемого механизама для публикации многоязычного контента ("вменяемого", в смысле -- "элемент инфоблока с одним айди, но разыми языковыми версиями", а не куча "куча разных элементов/инфоблоков и спагетти кода").
Даже в бесплатном WordPress эта задача легко решается.
А вот это: "элемент инфоблока с одним айди, но разыми языковыми версиями" - чревато ещё большим гемороем!!!! Потому что контент-менеджеры под разные языки тоже разные и следовательно права на инфоблоки тоже будут разные. Например, новости на русскоязычную версию добавляет тётя Дуся и ей на редактирование доступен только ИБ с российскими новостями, а новости в англоязычный сайт добавляет мистер Смит и права у него только на соответствующий ИБ. Далее, не обязательно новость должна быть на всех языковых зеркалах, например, новость о том, что американский офис не будет работать 4ого июля российским клиентам не нужна. Вообщем под каждый языковой сайт должен быть свой ИБ и у каждого элемента свой ID.
Я не пойму почему нельзя сделать мультиязычность по-человечески () сохранив при этом существующий функционал.
Кому нужно - будут пользоваться с радостью. Кому не нужно - продолжат забивать гвозди микроскопом.
В случае же когда 100% контента идентична имеет смысл сделать такие табы в редакторе элемента.
И сделать доп. настройку к какому из языков пользователь имеет доступ на редактирование. Не проблема, я считаю.
Мы сейчас работаем с такой реализацией переводов в другом проекте. Очень удобно.
Но 1С-Битрикс, по своему - хорош!
Я живу и работаю в Латвии. И все сайты которые мы делаем, они минимум на двух языках. Тенденция: три языка и больше.
На Битриксе это сразу + время + деньги на доп. лицензии.
P.S. По-этому не удобства в разработке, я тоже не вижу.
А может про это? (наполнение ланг-массива в каждой платежке)
А может про это?
Битрикс не идеален, но не надо OpenCart выставлять таковой.
PS: На скринах версия 1.4, последняя у них 1.5 как вижу. Вряд ли минор исправил всю эту порнографию.
Но черт возьми, над OpenCart трудятся студенты очкарики, тогда как битрикс - коммерческий продукт, который получает колоссальные деньги за разработку, и уже в течение 10 лет не может придумать - как сделать многоязычность удобной.
Вы перечислили 3 проблемы OpenCart'а (да. их еще больше на самом деле). Но, вы, с высоты своего опыта наверняка понимаете, что у битрикса проблем куда больше. Даже если брать в расчет один только модуль интернет магазина.
Давайте не будем холиварить тут на тему архитектуры и просто посочувствуем битриксу в том, что не может решить проблему, с которой на протяжении многих лет сталкиваются разработчики и их клиенты. Надеюсь недавние подвижки в сторону D7 хоть как-то сподвигнут руководство компании обратить внимание на вопрос многоязычности
а как вы представляете это?
Физически хранить в таблицах все поля в раскладе на N языков?
При текущей архитектуре проще на каждый язык свой инфоблок.
Раньше как то пробовал и свойства под языки плодить и сериализацией баловаться, но....
Нет ничего проще, чем сделать два абсолютно близняшных инфоблока с близняшными кодами и прочим, которые будут отличаться лишь ID и CODE. Ну а далее по описанным примерам Ким Анатлолия и Михаила Яковенко.
Ну и в этом обнаружился еще один плюс.
Представьте себе 10 языков и .... пусть на одном из них появилась новость.
В пределах одного инфоблока надо сделать перевод этой новости на все языки, или придумать что то , что скажет где ее выводить (очередные костыли)
В случае нескольких инфоблоков - ноу проблем. На каждом языке свои новости, хочешь дублируй, хочешь нет.
Форма редактирования элементов разбита на закладки RU/EN/UA
Компонент, в зависимости от выбранного языка, - работает с необходимым набором свойств.
С таким подходом пришлось немного кастомзировтаь поисковую индексацию.
Но в целом себя оправдывает, один элемент - сразу N языков.
Он подразумевает, что
Список новостей на всех сайтах должен быть абсолютно идентичен.
Т.е. выпуская новость на одном языке, контент менеджер просто обязан ее продублировать на остальных (в наборе свойств другого языка).
Либо надо плодить некий еще выключатель на каком языке выводить новость
--------
Лучше расслоить на разные инфоблоки
Отдельно вынесена закладка ОБЩЕЕ, где выводим активность элемента и прочие общие свойства.
Минус - это то, что:
1. нельзя разграничить права для контент редакторов, кто какую версию редактирует
2. Исходя из пункта 1 - нет возможности реализовать корректно модерацию (через документооборот или бизнес процессы )
Новости Ру - block_news_ru <== символьный код
Новости En - block_news_en
На страницу или в компонент давайте фильтр, например так:
Пример 1: сайт надо сделать на 3х языках. Структура абсолютно зеркальна. Абсолютно зеркально означает что статья присутствующая в одной языковой версии присутствует и во всех других.
Сделайте чтобы все статьи перенаправлялись не по #ID# а по #CODE#, то есть если адреса будут такие:
Тогда можно сделать свойство с привязкой к элементу инфоблока. Скажем, в русском инфоблоке block_news_ru создаёте свойство LINK_TO_EN и пусть контентщики привязывают в это свойство аналогичную статью из английского инфоблока block_news_en.
Требование чтобы у всех статей был символьный код естественно исчезает, так как теперь статьи не связываются по коду.
Если же у какой-то статьи нет аналога в другой языковой версии, то в ссылку нужно будет вставлять текущий раздел.
допустим в русской версии мы хотим сконструировать ссылку на аналогичную новость в английском разделе. а если аналога нет - просто перейти в раздел новостей там же.
$link_path = "/en/news/"; if(существует элемент) { $link_path = $element["DETAIL_PAGE_URL"]; }$test = CIBlockElement::GetList( array(), array("PROPERTY_LINK_TO_EN"=>$current_article["ID"])) if($test->SelectedRowsCount())Пример 3:
Просто везде расставьте ссылки на текущий раздел в другой языковой версии.
То есть, если вы находитесь в новостях на русской версии сайта, переходная ссылка будет вести на тот же раздел новостей, только на английской версии сайта.
Собственно говоря, зеркальность до уровня разделов, в то время как в примере 1 - зеркальность до уровня статей.
Вот в принципе и всё.
И в данной схеме, совершенно не обязательно что бы была полная зеркальность. Если в каком то языке новость отсутствует - выводим 404 ошибку и все.
Т.е. контент может быть совершенно независимым
Вот все до чего когда то доходил экспериментальным путем - теперь расписано на пальцах,
Ну а недостающее в тексте добавили партнеры.
Анна, спасибо за интересный и полезный пост.
в поле имя,фамилия и отчество включали оба варианта, например Иван||Ivan, в инит.пхп прописывали обработку для массивов и строку через регулярки..
Многоязычностью здесь и не пахнет.
Голосуем за идею:
1. Нельзя для каждой языковой версии сайта указать свой язык сообщения "Мне нравится".
2. Почтовые события будут приходить с языком, указанным в настройках сайта.
Подскажите пжс, что тут не так? Уже несколько недель бьюсь над многоязычностью! Буду крайне благодарен! Пытаюсь сделать английскую копию сайта.
<?
define("DBPersistent", false);
$DBType = "mysql";
$DBHost = "localhost";
$DBLogin = "***";
$DBPassword = "***";
$DBName = "***";
$DBDebug = false;
$DBDebugToFile = false;
set_time_limit(60);
define("BX_FILE_PERMISSIONS", 0777);
define("BX_DIR_PERMISSIONS", 0777);
@ini_set("memory_limit", "128M");
@umask(~BX_DIR_PERMISSIONS);
?>
<?
session_register("LANG_UI");
if(isset($_REQUEST['lang_ui']))
$_SESSION["LANG_UI"] = ($_REQUEST['lang_ui']=='en');
if(!isset($_REQUEST['lang']) && isset($_SESSION["LANG_UI"]))
define(LANGUAGE_ID, $_SESSION["LANG_UI"]);
?>
"This function has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0."
Функция считается устаревшей и не существует в версиях php > 5.4
Уже 4 года прошло, а статьи про локализацию так ни кто и не написал
ссылка не работает
session_start([
'LANG_UI',
]);
Подробнее тут:
Первое с чем сталкиваешься, это с дублированием товаров, товары и их свойства приходится переписывать в отдельный инфоблок, и соответственно нужно следить с какого каталога списывается товар и как то все это учитывать при складском учете, далее идут заказы на разных языках, потому как товары по сути разные.
При многосайтовости, у каждого сайта будет своя отдельная корзина. К примеру клиент зашел на сайт и что то добавил в корзину на языке сайта по умолчанию, а потом заметил что на сайт поддерживает его родной язык и переключился на него, в таком случае он потеряет свою корзину. Даже если делать перепривязку товаров в корзине при каждой смене языка, то в корзине будут товары на разных языках. После такого клиент сильно удивится и уйдет с бредового сайта.
Если пытаться делать подмену контента при выводе в компонентах каталога, то что делать с такими типами данных как списки, привязка к элементам и разделам, справочниками ? Как всю эту подмену совместить с кешированием и композитным режимом? Еще при этом не обидеть СЕО специалистов ?
Сделать справочник с переводами фраз, и подменивать их на выводе? Что тогда делать контент менеджерам ? Вешаться?
Как разделить данные пользователя при оформлении заказа и в личном кабинет? Подписи свойств пользователя тоже не предусматривают многоязычность!
Опять придется переделывать компоненты на вывод с учетом языка и впихивать перевод в сами компоненты.
Дальше вы столкнетесь с выгрузкой из 1С которая будет переписывать данные мультиязычных товаров и прочей магией.
Если потребовалось реализовать муьтиязычность на крупном сайте с магазином, после того как он уже запустился в работу, то это может занять еще больше времени чем разработать сайт с нуля с расчетом мультиязычности, так как придется переделывать каждый компонент под вывод нужного языка, а может быть все еще хуже, если потребуется добавить несколько языков за раз.(Примечание, я говорю про подмену фраз на уровне вывода компонента из отдельных справочников, чтобы не плодить инфоблоки.)
Обращаюсь к тем кто писал выше про разделение сайтов под мультиязычность, (ЭТО ПОЛНЫЙ БРЕД) покажите мне хоть один качественный сайт на котором это реализовано таким образом? Если я буду менять язык сайта, то все, включая корзину и уже оформленные заказы должны переводиться на другой язык !!!
Вот еще проблема, я запускаю выгрузку товаров из 1С и при выгрузке мне приходится каждый выгруженный товар дублировать в другие инфоблоки чтобы потом можно было их перевести на другие языки. Конечно для этого был написан скрипт синхронизации товаров, но это все создаст кучу проблем с количественным учетом товаров и их поддержкой контент менеджерами, так как обратную синхронизацию настроить не получится, а она будет нужна.
Амдминистративный раздел сайта не предусматривает мультиязычность даже на уровне апи, чтобы ее там реализовать, это нужно полностью отказаться от стандартного функционала битрикса и нагородить свои решения, в таком случае гораздо проще написать свою админку, но тогда зачем вообще использовать битрикс в мультиязычных магазинах, если все равно придется переделывать и вывод и управление ?
Ну еще можно включить пластинку "у нас массовый продукт, всех нюансов учесть не можем", но деньги за продукт берем, и рассказываем как круто закрываются частые кейсы прямо из коробки))
Но мягко говоря оказался в шоке когда столкнулся с мультиязычностью.
Клиент попросил перенести сайт с вордресса на битрикс, посоветовал ему подумать т.к у него стоит плагин Polylang а такой функционал как я понял на битриксе вряд ли получится реализовать.
при таком подходе:
session_start([
'LANG_UI',
]);
if(isset($_REQUEST['lang_ui']))
.... заметил баг, при сохранении раздела, элемента и т.п открывается просто белая страница, приходится назад переходить, сохранять то сохраняет и все работает но любого клиента это напугает