Возникла задача - подружить gettext и кириллицу. Да к тому же еще и кириллицу в cp1251. И, что самое главное, оригинальные строки для перевода в кириллице.
Попробовав Zend_Translate ощутил несоответствие идее:
[cc lang="php"]
_("Example")."\n";
[/cc]
Вот что должно произойти если нет /my/path/source-de.mo? Правильно, должно отобразиться "Example". На самом же деле отображаются матюки об отсутствии .mo. Что есть неправильно.
Кроме того Zend_Translate не предоставляет никаких возможностей по работе с кодировками.
Хоть я и приверженец ZF, но тут он меня сильно разочаровал.
Так я вернулся к стандартному подходу, несколько доправив его. Итак, вот что получилось:
[cc lang="bash"]
locale -a
[/cc]
убедился что есть локаль ru_RU.cp1251 на сервере. В убунте если она отсутствует ее можно создать так:
[cc lang="bash"]
sudo locale-gen ru_RU.CP1251
[/cc]
Отлично. Теперь очередь php:
[cc lang="php"]
[/cc]
По сравнению со стандартным примером тут появилась такая строка:
[cc lang="php"]bind_textdomain_codeset ($domain, 'cp1251');[/cc]
Это говорит, что все строки будут нам возвращаться в cp1251.
Далее мы выдираем на сервере все строки для перевода:
[cc lang="bash"]xgettext ./*.php --from-code=cp1251[/cc]
с указанием кодировки, в которой текст внутри, потому что по умолчанию gettext считает, что там ASCII.
Теперь внутри файла messages.po все лежит в UTF-8, и никаких проблем... если бы не cp1251, черт подери.
[cc lang="bash"]iconv -f utf-8 -t cp1251 ./messages.po > messages.po1251[/cc]
Вот так мы конвертаем его в cp1251. Полученый файл редактируем, добавляя перевод, и кроме того заменяем в нем строку:
[cc lang="text"]"Content-Type: text/plain; charset=UTF-8\n"[/cc]
на
[cc lang="text"]"Content-Type: text/plain; charset=CP1251\n"[/cc]
Теперь переименовываем файл messages.po1251 и убираем из его имени 1251, затем делаем
[cc lang="bash"]
msgfmt messages.po
[/cc]
и так получаем скомпилированый перевод. Который теперь работает ;) Наконец-то.
А вообще русские строки в качестве ключей работают чудесно и без такого шаманства если они в UTF8.