Современная, быстрая и удобная система управления сайтом

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

Архив записейКомментарии: 18Просмотров: 6558

Решил написать эту статью здесь, потому что она затрагивает 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). Правда пока это касается только самого шаблона, но со временем, думаю, отработаем и тексты записей, рубрики, метки, заголовки и т.д.

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

Комментариев: 18 RSS

1Whole pesso gender14-11-2008 07:27

Максим, когда вы уже наконец начнёте мыслить абстрактно? Ну какие файлы перевода, какие массивы? всё это уже - прошлый век.

2Umclidet14-11-2008 08:56

2Whole pesso gender.

Ну, продолжайте свою мысль.

Вы предлагаете иной путь решения проблемы?

Ждём-с...

3Роман14-11-2008 10:20

Круто було би включити зразу в ядро можливість абстрагування від джерела перекладу, тобто шоб мона було написати модуль який робить переклад скажімо через translate.google.com, а не тільки бере з статичного *.mo чи *.po файлу. Ви скажете низька швидкість, ну та, але треба давати користувачу вибір, може для когось це не критично...

4Tesmon14-11-2008 15:53

Whole pesso gender:
14 ноября 2008 в 07:27
Максим, когда вы уже наконец начнёте мыслить абстрактно? Ну какие файлы перевода, какие массивы? всё это уже - прошлый век.

А что же сегодня рулит?

5ABTOP14-11-2008 19:27

Ещё одно достоинство выбранного вами метода заключается в использовании языка по умолчанию, английского, например, в случае отсутствия файла перевода и одновременного использования разных языков в админке и пользовательской части.

6Lecactus15-11-2008 09:48

кстати о локализации ВП. сейчас ради эксперимента проверил на своем сайте (вчера снова обновил его до самой последней беты 2.7)

если файл локализации (полный для версии 2.7. весит 350кб) в наличии есть, то

MySQL: 45запросов / 0.577 Потребление памяти: 13.3MB

а если его убрать вообще, то

MySQL: 45запросов / 0.550 Потребление памяти: 10.1MB

если подсунуть вместо полновесного ru_RU.mo кастрированный файл который ru_RU_lite переименовав его в ru_RU.mo то потребление памяти вырастает всего килобайт на 300 вместо трех мегабайт

вот и думаю вложить ли в дистрибутив отдельный конфиг для подключения таких вот различных языков для админки и морды сайта

7Umclidet15-11-2008 09:58

Ну, тогда, позвольте естественный вопрос.

Если 45 запросов на сайте это НОРМАЛЬНО(сайт "голый" или со всякими полезностями, примочками и фенечками?), то сколько же это МНОГО - 100, 150 запросов?

8Lecactus15-11-2008 10:13

у меня установлено и активно БОЛЕЕ 60 плагинов, в т.ч. есть и ресурсоемкие типа статистики firestats (много "фенечек" полезных и для красоты). 45 это на морде, на одиночных записях у меня 40-65запросов (в основном от количества коментов)

на голом сайте примерно 20 запросов на морде и +\- 3 на одиночных

9Lecactus15-11-2008 10:22

замена в конфиге строки стандартной на

if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU');
else define ('WPLANG', 'ru_RU_lite');

снизило потребление на главной странице до...7,7мб. тут конечно отвалился перевод некоторых плагинов, т.к. для них тоже нужно создать ru_RU_lite файлы, да и самих плагинов, которые что то пишут по русски вне админки всего несколько штук

2Umclidet - некоторые плагины и виджеты ведут себя неадекватно на разных версиях ВП + например известный многим nextgen gallery при использовании виджета выдает огромное количество запросов (больше 130 точно было на одном сайте)

11Максим15-11-2008 11:25

Ну я думаю, что файл можно включить, а в конфиге дать два варианта. В конце-концов напишешь в readme для чего какой вариант. ;)

12Lecactus15-11-2008 11:37

Максим, мыслим одинаково. даже устроил опрос на эту тему

http://lecactus.ru/2008/11/15/3110/

13Alexpts15-11-2008 12:59

В дистрибутив включить надо обязательно.

14Umclidet15-11-2008 13:43

В дистрибутив, несомненно!!!

(Конечно, с добавкой хотябы небольшога текстового файлика с разъяснениями.)

15Александр22-11-2008 21:49

Ну дак можно пока старой версией пользаваться пока все проблемы не будут решены

16sn00k22-11-2008 22:35

А вот, что касается локализации для шаблона, то насколько я знаю, так ничего и не придумали. То есть все переводимые фразы следует включать в основной файл локализации.

Если при разработке темы автор ипользует для вывода текстов _e('some text','theme_dir_name')

(или __('some text','theme_dir_name')

), то установив плагин CodeStyling Localization перевести эту тему в дальнейшем очень легко. Кстати этим же плагином легко "переводить" и сам ВП, и другие плагины. PoEdit не нужен, т.к. CodeStyle сам создает .mo файлы.

17Николай Громов (nicothin)07-01-2009 13:24

всегда удивлялся принципу перевода в WP и друпале.

оптимально - так, как сделали Вы (похоже сделано и в джумле)

очень жду появления перевода материалов, ибо часто приходится делать многоязычные сайты.

18Meghan12-02-2014 13:52

Добрый день! Если Вы заинтересованы в локализации web-ПО, ПО для персональных компьютеров, ПО для мобильных устройств либо иного вида программного обеспечения, я рекомендую Вам использовать этот инструмент на базе web: https://poeditor.com/ POEditor является интуитивным, хорошо проработанным инструментом, обладающим рядом полезных свойств, которые помогают организовать процесс управления переводом. Он поддерживает множество популярных форматов файлов и обладает собственным API, что обеспечивает лучшую автоматизацию. Желаю Вам больших успехов в Ваших проектах!

Оставьте свой комментарий!

Комментарий будет опубликован после проверки

Вы можете войти под своим логином или зарегистрироваться на сайте.

(обязательно)