Локализация в MaxSite CMS

Решил написать эту статью здесь, потому что она затрагивает WordPress. Речь идет о локализации.

Как известно, для WordPress я долго использовал свой способ: русский текст внедрялся прямо в php-файлы.

Хотя нет. Еще в самом-самом начале я делал перевод в отдельном языковом файле wp-language.php. Схема была очень простая: вместо существующей трансляции «gettext» использовался массив с переводом. Стоит отметить, что в то время (2005) ресурсы серверов были несколько скромнее, поэтому оригинальный способ локализации создавал довольно существенную нагрузку. Выражалось это в несколькосекундном «притормаживании» страниц. При этом, если отключить файл локализации, то скорость увеличивалась в несколько раз.

Проблема была более-менее решена к выходу WordPress 2.1 (2007). Тут сложно как-то однозначно сдалать вывод: то ли подросли возможности серверов, то ли были улучшены алгоритмы, но в результате стандартная локализация стала не так сильно сказываться на скорости работы.

Чтобы было понятно, в чем суть проблемы, объясню. Локализация для WordPress хранится в специальным образом скомпилированном mo-файле. Из-за того, что WordPress содержит в себе массу текстов, файл перевода получается довольно приличный: 150-250Кб. То есть каждый посетитель заставляет WordPress «дергать» этот файл и, при этом, сам файл должен еще пройти процедуру «распаковки». И, лишь после этого, может быть выполнен сам перевод.

В WordPress локализация выполняется в едином файле. С одной стороны это может и неплохо (для переводчика), но с другой, львиную долю перевода занимает админ-панель. То есть та часть, которая никогда не доступна посетителю. В цифрах это выглядит так (WordPress 2.3.3):

• общий mo-файл перевода 221Кб,
• mo-файл вне админки - 34Кб.

Комментарии, как говорится, излишни.

В итоге всех экспериментов я придумал, что следует разделить mo-файлы на эти две части. Таким образом для обычного посетителя загружался небольшой (lite) файл, а для тех, кто входит в админку - полный. Вместе с Иваном мы сделали эти файлы и в таком виде выходила моя сборка до последнего момента (2.3.3).

Я расказываю про все эти моменты, чтобы вы оценили масштабность проблемы.

Для WordPress сам процесс локализации довольно сложен и в общих чертах выглядит так:

• После того, как вышла новая версия, переводчик должен «прогнать» в спецальной программе все файлы системы на поиск «трансляторских» функций. Раньше был (сейчас просто не знаю) т.н. шаблонный файл для переводчиков, но он не очень оперативно обновлялся, поэтому быстрее и надежнее было получить такой файл самому.
• После того, как все функции определены, из них «вычленяются» переводимые фразы.
• Дальше нужно выполнить сам перевод. Если это первый перевод, то фразы следует переводить с нуля. Если это перевод уже существующий, то можно подключить «словарь» - перевод выполнит программа.
• После всех этих манипуляций нужно скомпилировать mo-файл, который и используется WordPress'ом.

Как видите это довольно муторная работа, постоянно нужно перепроверять изменения, потом опять вносить правку и компилировать. И продолжаться это может довольно долго. Да и сами разработчики WordPress не очень то себя утруждают сохранять изначальные фразы. Иногда изменения бывают до одной буквы и все это приходится обрабатывать.

Таким образом я очертил уже две проблемы: первая - излишняя ресурсоемкость, вторая - сложность поддержки локализации. Понятно, что всё это ошибки на начальном уровне проектирования системы и, похоже, ситуация уже никогда не изменится.

Существует и еще одна проблема - это поддержка локализации на уровне плагинов и шаблонов. С плагинами разобрались более-менее и теперь сам перевод (mo-файл) может подключаться в каталоге плагина. Это, конечно, хорошее решение. А вот, что касается локализации для шаблона, то насколько я знаю, так ничего и не придумали. То есть все переводимые фразы следует включать в основной файл локализации.

То есть третья проблема - это сложность интеграции переводов.

Грубо говоря, ситуация с локализацией WordPress на данный момент можно обрисовать в двух словах: если блогер решил изменить переводимую фразу, то фиг что у него выйдет. Потому что ему нужно сделать mo-файл, а для этого нужна соответствующая программа, со своими нюансами, да еще и нужно предварительно сделать шаблонный файл для перевода. А потом выходит новая версия WordPress и все нужно повторять заново. :-(

Что же касается MaxSite CMS, то я не стал спешить и потратил довольно много времени, чтобы учесть все эти «ляпы» WordPress. На данный момент механизм локализации впервые выложил только сегодня, да и то для тестирования. Вопрос сложный, не хочется делать ошибок.

Первым делом, я конечно же, отказался от сторонних программ. То есть для создания файла перевода для MaxSite CMS никаких программ не требуется: файлы перевода это обычные текстовые (php) файлы.

Формат перевода выполнен в виде массива:

$lang['Слово 1'] = 'perevod 1';
$lang['Слово 2'] = 'perevod 2';

Я должен отметить, что такой способ давным давно применяется на форумах. Именно оттуда я и взял идею вначале для WordPress (wp-language.php), а теперь и для MaxSite CMS.

Файл перевода это обычный php-файл, который находится в каталоге (плагина, шаблона, админки и т.п.) language. То есть можно сделать свою версию перевода «en-my» и система его с удовольствием «скушает».

Сама же трансляция выполняется единственной функцией t(). В функции указывается выводимая/переводимая фраза и, если установлен какой-то язык, выполнится перевод.

Особенностью моей локализачии является еще и то, для трансляции можно использовать не только свой «родной» каталог, но и другой. Например перевод всех плагинов можно выполнить в едином файле: по размеру перевод небольшой, поэтому можно его хранить в одном месте. То же самое касается и админ-панели (возможно), и общего файла системы.

Для разработчика получается довольно простая схема: только прописать строки в t(). Для переводчика определить эти строки и вынести их в файл перевода. Все изменения сразу видны: никаких дополнительных действий не требуется. Ну а для владельца сайта всегда есть возможность подправить перевод без каких-либо ухищрений.

Что же касается шаблонов, то в перспективе такой механизм позволит «на лету» переключать языковую версию сайта (язык указывается в переменной, а не константе, как в WordPress). Правда пока это касается только самого шаблона, но со временем, думаю, отработаем и тексты записей, рубрики, метки, заголовки и т.д.

Надеюсь, что такой подход к локализации окажется более приспособлен к жизни.