Задача довольно сложная, но, учитывая большой опыт локализации WordPress, я решил сразу не спешить, а хорошенько подумать. Сделать качественный алгоритм локализации довольно тяжело, потому что нужно учитывать сразу множество факторов. Главные это легкость изменения и поддержки разработчиком; легкость интеграци (по возможности «на лету») и небольшая ресурсоемкость.
Таким образом я предлагаю всем желающим потестировать новую возможность, скачав последний latest.zip (от 14 ноября 2008 г.).
По-умолчанию система работает на русском языке. Для того, чтобы переключить язык следует в файле mso_config.php указать $MSO->language = 'en'; (для английского языка). Естественно должны быть сами файла перевода.
Общий принцип трансляции таков: фразы, которые должны или могут быть переведены оформляются в виде функции t(). Первый параметр - переводимое слово. Второе - каталог с файлом перевода. Файл перевода должен находиться подкаталоге language и иметь имя «язык».php. Файл перевода представляет собой обычный php-файл, в котором указан массив с переводом:
$lang['Слово 1'] = 'perevod 1';
$lang['Слово 2'] = 'perevod 2';
Например для плагина ушки: .../application/maxsite/plugins/ushki/language/en.php
$lang['Ушки'] = 'Ushki';
В самом плагине переводимые фразы указываются так:
t('Ушки', __FILE__);
или можно так:
t('Ушки', 'plugins/ushki');
Константа __FILE__ используется в PHP для указания имени текущего php-файла. Функция t() сама определит каким способом указан каталог. Таким образом, если у вас используется свой языковой файл, то удобней использовать __FILE__. Если же используется какой-то предопределенный, то лучше указать явный. Если второй параметр не указывать, то будет использован файл перевода из /common/.
Если данный алгоритм окажется эффективным, то я запланирую во всех входящих в комплект поставки плагинах, файл перевода включить в единый language-файл. Это будет проще для переводчиков. Также будет единый файл системы в каталоге common и admin. То есть все сведется к трем файлам локализации: общий, админки и плагинов.
Комментариев: 15 RSS
1G3D14-11-2008 17:27
Давним давно очікував цього кроку! Спасибі за розуміння)
2Александр Захаров15-11-2008 13:01
Судя по отзывам, движок действительно очень хороший. Я веду свой блог на WordPress, и у меня возник вопрос: если я переведу свой ресурс на MaxSite CMS, возможно ли сделать так, чтобы остались все мои старые записи (причем по старым url-ам) и комментарии, а также url-прочих страниц - архивы, разделы, метки и т.д.?
И второй вопрос - а где можно скачать MaxSite CMS? Я что-то не нашел ссылки :(
3WaveСайт15-11-2008 13:42
1. Нет.
2. http://max-3000.com/page/maxsite-cms-025
4Александр Захаров15-11-2008 13:43
Прошу прощения, ссылки уже нашел :)
5Вот ты какой15-11-2008 22:52
Бывает.
Движек действительно класный
6Vaswiliy24-11-2008 22:48
а на денвер его можно поставить а то поставил
Версия: 0.25 а у меня в самом верху пишет
A PHP Error was encountered
Severity: Warning
Message: Cannot modify header information - headers already sent by (output started at X:\home\maxsite.fp\www\application\config\database.php:1)
Filename: libraries/Session.php
Line Number: 295
A PHP Error was encountered
Severity: Notice
Message: Undefined variable: mso_install
Filename: common/common.php
Line Number: 142
=(
7WaveСайт24-11-2008 23:54
Vaswiliy, читай readme идущую в архиве. Там эта ошибка описана.
8Аноним02-12-2008 09:14
перевод стандартный будет?
9Николай Громов (nicothin)30-12-2008 12:37
а уже сейчас, для самой новой (0.27) версии движка можно делать многоязычные сайты (хотя бы простой установкой нескольких копий движка)?
php-фреймворк включен в двигло, вопрос: можно ли сделать несколько сайтов на MaxSite CMS с использованием одних и тех же сайлов фреймворка?
довольно часто делаю сайты, присматриваюсь к Вашей CMS :)
10WaveСайт30-12-2008 14:01
Можно даже на одной копии движка. Просто разные префиксы для базы данных задать и немного допилить напильником в сторону выбора языка до выбора префикса БД. Где-то на форуме это обсуждалось.
Проблема ещё в том, что в исходниках много русского языка. Приходится лазить по исходникам и менять func_name($param, 'что-то по русски') на func_name($param, t('что-то по русски', __FILE__)) после чего ещё перевод вписывать в соответствующем файлике.
Мне вот понадобилось украиноязычный сайт с желательно украинской админкой сделать, так я думал, поседею, когда глянул, сколько вылавливать хардкод и менять на функу перевода.
Конечно, можно было бы просто менять русский на украинский, или если понадобится — на английский (а больше я языков не знаю), но хочется сделать правильно, с заделом на будущее, чтобы если что, только файлы перевода отдать переводчикам. Тем более, что уже дважды приходилось сталкиваться с арабским, где куча дополнительных приколов из-за Right-To-Left написания и рендеринга в браузерах.
11Максим30-12-2008 15:57
Арабский это круто! :)
Но вообще если я правильно понял, то данный механизм перевода не вызывает нареканий. У меня, правда есть еще несколько чисто технических вопросов, которые я надеюсь решить в ближайшее время. Думаю, что это позволит выйти на нормальный окончательный алгоритм.
12Николай Громов (nicothin)07-01-2009 15:50
посотой поиск по форуму с запросом "func_name" никаких результатов не дал.
а вообще, очень неудобно искать по WP-форуму темы, касающиеся MaxSiteCMS.
имхо, но уже созрела необходимость для отдельного форума.
13WaveСайт07-01-2009 16:19
func_name — это как «такой-то имярек». Т.е. просто в коде дофига функций (разных), которые вызываются с русскими строками в параметрах. Или печатают-возвращают что-то по русски.
Но что неудобно искать по WP-форуму темы, касающиеся MaxSiteCMS — поддерживаю. Как впрочем и припоминаю чайников, задающих вопросы по WP в подфоруме MSO.
Самый неудобный цимес там, где по нескольку строк идёт. Например, описания плагинов или вступительное слово в админке. Описание, как зарегиться комьюзеру. И так далее. Вызывать функи вида:t('Этот плагин предназначен для … здесь длинное многострочное описание', __FILE__)
как-то некошерно.
Т.е. теоретически можно так:
t('descr-01', __FILE__);
$lang['descr-01'] = 'Этот плагин предназначен для … здесь длинное многострочное описание';
Но тоже не самое удобное решение.
14Максим07-01-2009 17:00
Верно. Меня этот вопрос тоже смущает. Но есть одна идея, которая имеет совсем другой подход к локализации и при этом значительно проще в использовании. Пока я не готов об этом говорить, вначале сам поэкспериментирую, а потом уже предложу для обуждения. Так что пока остаемся на текущем алгоритме.
Кстати вместо __FILE__ удобней использовать явное указание каталога. Я в админке буду делать единй файл перевода, поэтому там получается просто:
t('фраза', 'admin');Для плагинов, которые в комплекте тоже будет один общий каталог. Там не очень большой файл, поэтому удобней его править в одной куче.
15WaveСайт07-01-2009 17:14