Когда заглядываешь в код переведённого кем-нибудь плагина или темы оформления, то частенько сталкиваешься с таким вот явлением: все сообщения переведены «в лоб» прямо в PHP-коде самого плагина. И сразу возникает вопрос. А зачем?
Конечно, бывают ситуации, когда плагин состоит только из одного файла или программер был не очень квалифицированный: ничего не слышал о GetText, поэтому при написании кода не пользовался тегами вышеуказанной системы. Здесь перевод «в лоб» наиболее оправдан.
Но если плагин состоит из нескольких файлов кода, а программист заранее позаботился о том, чтобы можно было его творение быстро и без особых заморочек заставить говорить на другом языке и использовал при кодировке плагина GetText, то нафига рыться в коде десятков php-файлов, меняя тексты сообщений там, если можно сделать всё аккуратно и с меньшими трудозатратами?
Начинаем процесс.
Сначала загляните в текст php-файлов плагина, который решили перевести, и поищите, нет ли в коде следующих тегов: _e или __?
Примером подобных строк могут быть следующие:
<?php _e(’This entry was posted on’,'wp_multiflex’); ?>
…
<?php the_content(__(’Read the rest’,'wp_multiflex’)); ?>
Если эти теги присутствуют в коде, то нам очень повезло: процесс перевода будет очень лёгок и удобен. В общем-то, настоящий пост именно об этом случае.
Как вы уже, наверное, поняли, именно эти теги и используются системой GetText, которая была создана для того, чтобы было легко локализовывать софт.
Нужно предварительно сказать, что GetText работает следующим образом: она в процессе работы ищет в папке плагина файлы с расширением .po и .mo. Это и есть файлы перевода на нужный язык. Если находит, то начинает использовать их для вывода сообщений. Если не находит, то выводит на экран сообщения, которые прописаны внутри кода плагина.
Так вот, чтобы перевести плагин, нам нужно получить файлы .po и .mo.
Для начала нам необходимо найти и извлечь все, требующие перевода, строки из php-кода плагина. Кроме того, желательно поместить все найденные строки в файл .po, который затем и нужно будет переводить. Поможет нам в этом деле утилита xgettext.exe которую можно легко найти в сети.
Будем считать, что она найдена и готова к первому запуску на вашем компе.
Если в плагине всего один файл, то строка запуска этой утилиты будет выглядеть следующим образом:
xgettext nameplugin.php
Где, xgettext — название запускаемой программы, а через пробел — название файла, с которым производятся манипуляции.
Результатом работы этой утилиты будет файл «messages.po», который будет содержать список строк, которые нужно перевести на русский язык.
Но если файлов в плагине много, то действовать будем несколько по иному.
Напишем в «Блокноте» небольшой bat-файл, который будет содержать в себе следующий примерный текст:
xgettext –keyword=__ –keyword=_e –default-domain=namedomainplugin –language=php –output= nameplugin.po 1.php 2.php 3.php 4.php
Давайте подробно рассмотрим команды этого bat-файла:
- –keyword=__ –keyword=_e — описывают те теги, строки с которыми нужно искать
- –default-domain=namedomainplugin — название папки, где находятся файлы плагина
- –language=php — указывает, на каком языке программирования написан плагин (в нашем случае это PHP, так как WordPress написан именно на нём)
- –output=nameplugin.po — определяет название выходного .po файла (nameplugin.po)
Далее, через пробелы, перечисляются названия всех файлов плагина.
Это не все опции, с которыми можно запускать утилиту. Остальные — вспомогательные. Вы можете ознакомиться с ними, запустив xgettext с опцией «–help» для вывода подсказки. Один минус — эта подсказка тоже англоязычная.
Итак, файл .po создан. Что дальше?
Приступаем к, собственно, переводу.
Полученный в результате предыдущих действий файл представляет собой обыкновенный текстовый файл, содержащий в себе все строки, нуждающиеся в переводе.
Он выглядит примерно так:
# SOME DESCRIPTIVE TITLE.
# Copyright (C) YEAR THE PACKAGE’S COPYRIGHT HOLDER
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
#
#, fuzzy
msgid “”
msgstr “”
“Project-Id-Version: PACKAGE VERSION\n”
“POT-Creation-Date: 2007-03-03 02:56-0800\n”
“PO-Revision-Date: 2007-11-19 11:39+0300\n”
“Last-Translator: Вася Пупкин <VPupkin@yandex.ru>\n”
“Language-Team: Russian < VPupkin@yandex.ru >\n”
“MIME-Version: 1.0\n”
“Content-Type: text/plain; charset= utf-8\n”
“Content-Transfer-Encoding: 8bit\n”
#: prueba.php:12
msgid “Hello world”
msgstr “”
#: prueba.php:12 prueba.php:13
msgid “This is a test ”
msgstr “”
#: prueba.php:13
msgid “This is a test”
msgstr “”
Сначала идёт блок служебных строк. Некоторые служебные строки требуют внесения значений. Наиболее важные из них следующие:
“Last-Translator: Вася Пупкин <VPupkin@yandex.ru>\n”
“Language-Team: Russian < VPupkin@yandex.ru >\n”
“Content-Type: text/plain; charset= utf-8\n”
- Last-Translator: — вводите имя и email переводчика, т. е. свои,
- Language-Team: — тут «Russian» (язык перевода) и опять email,
- Content-Type: — тут вводите text/plain; charset= utf-8.
Кодировка UTF-8 — стандартная для WordPress. Ну вот, все важные заголовки заполнены. Далее идут, собственно, строки, требующие перевода. Например:
msgid “Hello world”,
а ниже неё
msgstr “”
строка, в которую между кавычками нужно поместить перевод фразы.
Переводим все сообщения до конца и вот у нас полностью готов файл .po. Двигаемся дальше.
GetText не работает с .po файлом. Чтобы информация из него стала доступной плагину, этот файл нужно скомпилировать. Этим занимается ещё одна утилита, которую нужно скачать из сети на ваш компьютер. Эта утилита — msgfmt.exe.
Запускаем её со следующими (я думаю, понятными) параметрами
msgfmt file.po file.mo
В результате её работы появляется второй файл. С расширением .mo.
Вот, собственно, и всё. Перевод готов.
Обязательная хитрость.
Чтобы переведённый плагин говорил на русском языке, структура названия .po и .mo файлов должна быть следующая:
nameplugin-ru_RU.po
и
nameplugin-ru_RU.mo.
Префикс -ru_RU должен присутствовать обязательно, иначе плагин так и не заговорит по-русски.
Закачайте готовые файлы .mo и .po в папку с вашим, переводимым на русский язык плагином. Обязательно удостоверьтесь, что в файле настроек блога на WordPress (wp-config.php) в строке
define (’WPLANG’, ‘ru_RU’);
стоит именно ru_RU. Если все рекомендации соблюдены, то ваш плагин теперь будет общаться с вами на русском языке.
Автор: Геннадий Ка.
Интересное...
Комментарии:
Lecactus пишет:
24 декабря 2007 в 13:50
К сожалению не всегда это возможно даже если механизм поддерживается “вроде бы”. существует например плагин wpg2 (для подключения gallery2) и ему хоть как пытался подсунуть файл с переводом как своим русским, так и другими языками, но он их игнорировал хотя файлы лежали в нужных каталогах с нужными именами. пришлось переводить внутри. кстати даже если механизм предусмотрен, то перевод “внутри” снижает нагрузку на некоторые хостинги, особенно если это касается тем или плагинов, которые что то показывают в блоге, а не админской части. минус это то что при обновлении плагина придется либо снова перелопатить все файлы плагина копируя готовые строки из старого либо все переводить во внешнем файле. так что механизм этот изначально хорош, но не всегда реализауем. сейчас у меня 50/50 плагины стоят переведенные и так и эдак. при выходе новых версий я уже сразу перевожу их в PO файлах, т.к. плагины потом снова обновятся и можно будет затратить 5-3минут вместо нескольких часов. кстати бывает часто что некоторые слова не переводятся даже через PO и их все равно приходится переводить в коде.
PS в командной строке компилировать -декомпилировать PO-MO файлы это конечно интересно, но процесс выдирания строки из кода плагина-темы полностью автоматизирован при использовании POEDIT, а все перечисленные консольные утилиты входят в него же и для декомпиляции чужого MO их нужно использовать в консоле
PS надеюсь комент не слишком длиннный
Infoman пишет:
6 марта 2008 в 12:51
И ещё важно чтобы в базе данных в конфиге и везде стояло либо ru_RU или ru и соотвественно плагинные рус файлы называть соответственно
ато вот я 1 день мучался :(
вот у КактусаЛе wpMU по умолчанию стоит ru а плагины делаются ru_RU вот и неопытные мучаются :(
Alex пишет:
3 мая 2008 в 16:26
Если самому внутри переводить - то получается при след апдейте все заново прийдеться делать- я правильно понимаю?
Интересно ктото делал замеры по производительности при использовании перевода внутри и при помощи внешних po и mo?
И может линки на эти утилитки что описаны в тексте?
Вячеслав пишет:
7 июня 2008 в 10:58
В статье есть запись …строка запуска этой утилиты будет выглядеть следующим образом:
xgettext nameplugin.php
не указано запускать ее с командной строки или необходимо запустить саму программу Gettext . Возникает вопрос как же запустить утилиту xgettext
alexvgrey пишет:
3 декабря 2008 в 09:17
Прекрасный пост. Жаль, не описан вариант, где отсутствует механизм (po-mo). У меня плагин kb-countdown, к сожалению скудные познания языка php и правка файла плагина не помогли мне :(
Комментариев нет:
Отправить комментарий