По моему мнению реализация многоязычности в битриксе реализована плохо, чтобы не сказать хуже. Не скажу, что в других системах ситуация чем-то кардинально отличается, но от используемого инструмента всегда хочется больше.
В битриксе проблема многоязычности сайта решается обычно многосайтовостью, т.к. каждому сайту можно применить только 1 язык. Эта "языковость" сайта проявляется в выборе битриксом папки с переводом фраз у компонента, и как следствие все управляющие интерфейсы так же переводятся на язык сайта. Создание же отдельного сайта, решает проблему статической информации редактируемой на каждой странице и возможности настроить необходимые компоненты по разному. Сам же контент требуется дублировать на других языках либо в дополнительных свойствах либо в других инфоблоках.
В финансово сложных условиях конечно никто не хочет покупать дополнительные лицензии для создания сайтов под каждый язык. Более того, различия сайтов на разных языках отличаются лишь выводимой информацией, сами макеты одни и теже. Поэтому решение в таких случаях, создавать свойства с языковым постфиксом в названии, например, PREVIEW_TEXT_RU, а в шаблоне выводить $arItem["PROPERTIES"]["PREVIEW_TEXT_".strtoupper(LANGUAGE_ID)][ "VALUE"].
Вместо LANGUAGE_ID можно использовать и сохраненный в куку параметр языка либо сам параметр из адреса. Но была бы не полноценная многоязычность если не использовать наборы переводов текстовых строк из коробки. Поэтому тут надо обзавестись модулем для php под названием "runkit". Его придётся компилировать из исходников, потому что пекловская версия устаревшая и подойдет только для php 5.2 и старших версий. Исходники находятся на гитхабе по адресу https://github.com/zenovich/runkit
После того как модуль установлен, можно менять значения констант. УЧТИТЕ, изменение констант – плохой стиль программирования и может привести к плохим последствиям. В своём модуле или файле init.php необходимо подписаться на событие OnPageStart, т.к. перед ним иницилизируются все настройки для сайта и необходимая нам константа. В теле функции, вызывающейся по этому событию необходимо задать правильное значение, например, вот так получив из параметра значение подставляем его в константу:
Это решение позволяет избежат нескольких проблем простых сайтов – дублирование шаблонов и дублирование инфоблоков, а главное удешевить разработку и поддержку сайта.
Для более изящного варианта, можно добавить в тело функции еще определение текущей локали пользователя, я это делал добавив модуль Zend_Locale из zend framework-а.
Еще важно заметить, что битрикс не учитывает обозначения языков принятых в ISO(http://en.wikipedia.org/wiki/List_of_...39-1_codes, поэтому украинский язык определяемый Zend_Locale надо заменять с 'uk'(ISO) на 'ua'(Битрикс).
А почтовые события? (пожалуй, это чаще всего требуется при многосайтовости (когда нужна почта) когда без доп.сайта не обойтись) И при необходимости поиска по сайту - все равно же придется дублировать информацию по инфоблокам (чтобы на одном языке только по одному ИБ искалось, а на другом по другому)
Да. иногда кажется, что стоит добавить несколько полей в инфоблок и проблема решается, но не все так ласково и гладко. Самым приянтным для меня моментом в Битриксе является все таки файловая составляющая. ленги реализованы. а вот как только доходим до БД... что поделаешь. Обижаться на Битркис за то, что не решают мегахитрую проблемку, востребованную только на N% сайтах (далеко не 100%)? А кто то может предложить ее простое решение вообще? Антон вскрыл только два из проблемных камней преткновения
Антон Долганин в этом решении не стояло задачи почту рассылать на разных языках(та и вообще почта пользовалась крайне редко) и прикреплять поиск по сайту, поэтому и приемлемо было лишь продублировать свойства в 1 инфоблоке, с дополнительным языковым. С почтой думаю можно справиться написав свой обработчик отсылки, который и будет подставлять нужный языковой ключ к ключу свойства инфоблока, а вот с поиском действительно проблема. В любом случае этот вариант подходит когда клиенту очень нужно сэкономить деньги на лицензиях и можно пожертвовать неким функционалом.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».