shoorick | Entries tagged with gettext

Свежая новость: оказалось, что трёхпалая чайка — не моёвка, а мóевка.
Mojowka теперь умеет показывать страницы посетителю на нужном ему языке. Язык может быть указан явно самим посетителем либо (если не указан) может выбираться автоматически, исходя из переданного заголовка Accept-Language. Пока доступны два языка — английский и русский.

Сделано с использованием Mojolicious::Plugin::Textdomain, о котором я писал в декабре. К сожалению, Анатолий Лапицкий (nuclon) до сих пор не выложил свой модуль на CPAN.
Увидев в моёвке экземпляр jQuery плюс мою яваскриптовую писанину, GitHub почему-то решил, что проект в целом яваскриптовый, а не перловый. Как переучить его обратно — пока не знаю.

Current Mood: работаю

Анатолий Лапицкий (

nuclon) написал Mojolicious::Plugin::Textdomain — плагин к Mojolicious для использования в нём геттекста. Я тоже начал писать, но он успел быстрее :-)

Вроде, работает.

На CPAN пока нет, но, надеюсь, скоро появится.

upd/20:48: Слепил пример использования: по запросам /язык/чё-то выдаёт страницы на нужном языке, если язык незнакомый — пытается определить по Accept-Languages, какой язык подходит посетителю и, если есть подходящий, выдаёт страницу на подходящем языке, а если нет подходящего — на английском.

В комментариях подбросили ссылку:
On the state of i18n in Perl

When it comes to making your application tranlatable in Perl, there are actually two schools of doing this: via Maketext and via GNU gettext. GNU gettext is the most known software translation tool used in most open-source projects while Maketext is a child of the Perl world. And the bad thing is: Maketext is currently more popular, but if you are using Maketext for making your application translatable, you are doing it wrong!

Ну и там ещё несколько страниц текста, где автор подробно объясняет, чем плох популярный среди перловиков Maketext и почему следует всё-таки использовать более распространённый в остальном мире GNU gettext.

В мануале на геттекст пишут, что есть несколько переменных окружения, на которые смотрит геттекст, принимая решение о выборе языка

In the function dcgettext at every call the current setting of the highest priority environment variable is determined and used. Highest priority means here the following list with decreasing priority:
LANGUAGE
LC_ALL
LC_xxx, according to selected locale category
LANG

Под FreeBSD (в попадавшихся мне серверах) переменная LANGUAGE была неопределена — можно было смело использовать более короткую LANG. Под убунтой такой фокус не проходит.

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

Когда-то я уже находил список значений для ключа -k программы xgettext. Внимательное чтение документации на Locale::TextDomain позволяет понять, что тот список неполон.

Правильнее использовать такой:

-k__ -k\$__ -k%__ -k__n:1,2 -k__nx:1,2 -k__np:2,3 -k__npx:2,3 -k__p:2 -k__px:2 -k__x -k__xn:1,2 -kN__ -kN__n -kN__np -kN__p -k

Снова задумался о применении геттекста в Mojolicious — существующий метод, когда вместо написания отдельных геттекстовых po--файлов прямо в перловый код засовывается что-то такое:

our %Lexicon = ( 
    'Add'    => 'Добавить',
    'Remove' => 'Удалить'
);

никоим образом не может считаться достойным. Порывшись по CPAN, добрёл по ссылкам до Locale::Maketext::TPJ13, где авторы ругают геттекст, приводя корявые якобы геттекстовые примеры обслуживания множественных чисел, надеясь оправдать этим существование собственного других модулей, которые не лучше.

Написал на annocpan коммент, хотя сомневаюсь, что авторы получит его и пойдёт читать мануал по Locale::TextDomain. Похоже, процитированная в Locale::Maketext::TPJ13 статья вышла очень давно (first appeared in The Perl Journal #13 and is copyright 1999) и авторы о ней забыли.

В мануале советуют использовать модуль Locale::TextDomain, в котором уже сразу есть функция __ и ещё куча удобных штуковин, при этом нет ненужного ООП. В том же мануале — ключи для xgettext:

-k__ -k\$__ -k%__ -k__x -k__n:1,2 -k__nx:1,2 -k__xn:1,2 -kN__ -k

Чтение мануалов просветляет...

Бодание с перловым интерфейсом к геттексту завершилось успешно. Результат можно понаблюдать на http://urc.ac.ru/cgi/ftpsearch/ — скрипт пишет ответ на нужном языке в зависимости от языковых настроек браузера посетителя и использует правильные формы множественного числа (о применении геттекста для множественного числа мне zauberer Яша ещё в позапрошлом году говорил).
Множественные числа можно добывать функцией nget. Для неё псевдоним тоже не будет лишним:
# __ и _n - псевдонимы для $d->get и $d->nget sub __ ($) { $d->get( @_ ) } sub _n ($$$) { $d->nget( @_ ) }
Посмотрел в исходники Locale::gettext — там вызываются обычные функции. Нафига было приплетать сюда ООП?
Функция setlocale не хочет понимать переданный язык, ориентируясь исключительно на переменную окружения $LANG. Чей это глюк — непонятно. В результате приходится использовать костыль:
# Вопреки мануалу, второй параметр функции setlocale игнорируется $ENV{'LANG'} = ( $ENV{'HTTP_ACCEPT_LANGUAGE'} =~ /ru/ ) ? 'ru' : 'en';

Current Mood: пора обедать
Current Music: шум из-за окна

Держать по несколько версий одного и того же скрипта, отличающихся лишь выводимыми строками — неправильно. Значит, надо разобраться с интернационализацией.
Пытаюсь понять, как использовать gettext в перлосриптах. Пока не совсем понятно. Толковую доку на русском не нагуглил, пытаюсь понять на аглицком.
Глядя в мануал и творчески применяя напильник, сотворил скрипт (тут приведена далеко не первая итерация):
#!/usr/bin/perl -w use strict; use Locale::gettext; use POSIX; setlocale( LC_MESSAGES, '' ); # OO interface my $d = Locale::gettext->domain_raw( 'man_1' ); $d->dir( 'i18n' ); # __ is alias for $d->get sub __ ($) { $d->get( shift ) } print __ 'Hello world!', "\n"; print gettext( 'Who they are?!' ), "\n"; print $d->get( 'Goodbye world!' ), "\n";
добыл список строк командой xgettext, добавил к нему перевод (можно вручную, можно задействовать kbabel), скомпилировал при помощи msgfmt, сложил полученный перевод в ./i18n/ru_RU.UTF-8/LC_MESSAGES, подвожу итоги:
- gettext обнаруживается xgettext'ом, но не работает (в мануале: Perl programs should use the object interface.)
- $d->get работает, но отвратительно выглядит (что обходится вводом псевдонима — функции __) ~~и не обнаруживается xgettext'ом~~
- __ работает, выглядит хорошо, ~~но тоже не обнаруживается xgettext'ом~~.
Исходя из имеющейся ситуации самым правильным, наверное, будет научить xgettext находить в исходнике те строки, перед которыми стоит __
Пошёл читать мануал дальше...

upd/19:30: xgettext можно научить понимать разные ключевые слова: запущенный с ключами -k__ -kget, он всё находит. Завтра попробую применить на практике.