30 апреля 2012 в 22:53

Быстро локализируем WordPress (часть I)

Wordpress localisation Если у вас блог или сайт вертится на WordPress и язык сайта не английский, — то вы точно сталкивалась с проблемой локализации.

В WordPress есть свой фреймворк для перевода движка, а также отдельно шаблонов и плагинов. Об этом фреймворке и удобных плагинах мы поговорим во второй части.

Но для начала посмотрим на его недостатки и как можно с ними легко расправиться.

Несколько типичных проблем с локализацией системы:

  • Если вы используете сторонние плагины и шаблоны, перевод на русский язык, как правило, затягивается, так как часто этим занимаются другие люди нежели разработчики кода.
  • Даже если вы руками перевели плагин но код не попал на wordpress.org, при апгрейде, патч-перевод надо будет руками заливать опять.
  • Также, иногда полученный перевод может резать по ушам, и вы бы хотели кое-что быстро изменить не залезая в код и не компилируя файлы переводов.
  • Иногда переводчики пропускают некоторые фразы.
  • Часто надо просто локализировать несколько фраз видимых обычным пользователем и нет смысла переводить все фразы, особенно в админке.
  • ...


Решение этих проблем через код довольно простое. Скажем, в новой версии шаблона забыли перевести слово «Search...» и вам надо заменить его на «Поиск...».

Кодом это решается вот так:

  1. add_filter ( "gettext", "my_gettext_filter", 1000, 3 );
  2. function my_gettext_filter ( $new, $old, $domain ) {
  3.     if ( "Search..." == $old ) {
  4.         return "Поиск...";
  5.     } else {
  6.         return $new;
  7.     }
  8. }


Но если таких патчей несколько, лазить каждый раз в код, согласитесь, неудобно. Да и не нужно. Берём готовый плагин Quick Localisation. Устанавливается он просто. Скачиваем zip файл и забрасываем папку quick-localization в wp-content/plugins или устанавливаем плагин прямо через панель админа.

Активируем плагин. Дальше указываем какую фразу перевода надо заменить на нашу собственную:



Сохраняем. Кажется всё.

У плагина много дополнительного функционала. Если вы не знаете какая фраза используется и в каком пакете (домене) перевода, — можно через настройки включить дебаг-поиск и посмотреть в дампе всех вызываемых переводов.

Также в плагине Quick Localisation можно включить сбор неизвестных переводов, всех, или по указанных доменах. Плагин сохранит их в черновиках. Можно перевести нужное, а ненужное убрать одним нажатием кнопки.

Через меню Экспорт и Импорт эти переводы легко переносить с сайта на сайт, а также обрабатывать в любом текстовом редакторе.

Русский перевод самого плагина можно скачать здесь как текстовый файл и прогнать его содержимое через страницу импорта.

К слову, сайт украинских новостей Siohodni который пишет на экзотическом стандарте латиницы удалось полностью локализировать после добавления всего 120 записей. 87 из них для стандартного WordPress и 26 для шаблона Duster. Заняло это меньше часа. Перенос этого же перевода на другой сайт — меньше минуты.

Во второй части будем говорить об инструментах и плагинах которые помогают автоматизировать перевод WordPress более долгим стандартным путем.
+3
45
Londain 195,1

комментарии (7)

+3
vyacheslav_ka, #
В вордпрессе же есть инструменты для работы с языками, зачем лепить костыли из фильтров, которые очень сильно затормаживают работу?
0
Londain, #
Об этом же и речь. Когда пришёл новый апдейт плагина, а там дальше перевод не тот что нужно, — чтобы не патчить каждый раз, помогает Quick Localisation. И не плохо помогает. Работа ускоряется, а не затормаживается. О других плагинах и подходах — немножко позже.
0
xbreaker, #
Правильно ли я понял, что в этом плагине все переводы хранятся в базе? Чем же это быстрее файлов-переводов, ведь появляются лишние запросы к базе. Плюс он вешает фильтры на пару ресурсоемких экшенов ВП.
0
Londain, #
Поняли Вы правильно.

Но таблица переводов читается одним запросом и кэшируется в памяти. Если у Вас кэширование а-ля сепер-кеш, проигрыш в генерации контента — практически нулевой.

Один фильтр в ВордПрессе погоды не делает. Сам ВордПресс использует сотни фильтров и екшэнов. На них всё и держится.

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

Опять же, с самого начала я написал — это только один подход. Быстрый — в плане имплементации. В плане всё как пишет Библия — будет дальше. Но стоит другой подход гораздо больше времени.

0
Adward, #
Был опыт использования Codestyling Localization

В начале система немного тупила (или я, ввиду неудобства интерфейса плагина), но после того как втянулся — теперь без него вообще не могу. Но опять таки, у кодстайлинга в данном случае есть минус — он просто-напросто браузерный генератор .po и .mo файлов. Хотя из плюсов — ему можно скормить и как новые темы, так и установленные плагины. Но по HTML/JS коду бегать он не умеет, в общем, пощупаем сегодня Ваше решение.

Буду рад новым обзорам на эту тему, если нашли время плотно заняться этим вопросом :)
+1
ssneg, #
WPML ($29) решит все ваши проблемы. В т.ч. локализацию нелокализованного. Если нужно бесплатно — то qTranslate.
–1
varg242, #
WPML работает на УРА

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

Что нам стоит Git настроить!
Nokia 105 за 15 евро с фонариком и аккумулятором 800 мА·ч
9 лет возможности на Марсе