Посты с тэгом i18n


[Из песочницы] Babel и handlebars, пора бы и подружить

Думаю многим известен такой пакет как Babel, либо PyBabel.
Отличный пакет для локализации, который базируются на gettext, как и все остальное ( по крайней мере мне известное) в современном мире.

Встала задача, подготовить сайт к будущей локализации, все темплейты сделаны в Handlebars, на этот движок шаблонов в первую очередь и был ориентир, что подружить нужно с ним. Вопрос кого.

Должен заранее оговориться, что у меня не было никакого ограничения в выборе технологий.
У нас в конечном счете для билда статики используется полный набор — ruby(compass), node(coffee,grunt,requirejs), python(бэкенд и основа всего и вся), шелл скрипты, в общем ограничения нет никакого.
Читать дальше →



Переводы браузерных приложений

Рано или поздно, если приложение ориентировано не на англоязычный рынок, всем приходится сталкиваться с локализацией. Пару недель назад у нас подошëл момент, когда дальше уже нельзя и пора что-то делать. :)

И я пошëл искать библиотеку, которую можно было бы использовать для переводов. Я нашëл какое-то их количество, некоторые из них были с зависимостью от jQuery (нынче уж и 2 + 3 не посчитаешь без неë), некоторые не обновлялись уже много лет и их работоспособность сомнительна, были еще какие-то проблемы. Самая похожая на победителя библиотека называется Jed.

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

Очевидно, с такими проблемами мириться было нельзя и была рождена новая библиотека, которая получила говорящее имя puttext, и API, который на gettext походит только издалека



Интернационализация локального проекта django

Хорошо, когда при разработке проекта под django, разработчики проекта изначально озаботились его интернационализацией.

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

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

Читать дальше →



Django - глубоко в i18n

Казалось-бы обычная ситуация, есть поддержка 2 разных языков в проекте. Как получить перевод разных слов на разных языках в django. На первый взгляд звучит просто, но в официальной документации на этот счет не было ничего. Пришлось руками залесть в код (спасибо twisted за такой скилл), и найти нормальный способ сделать это.

from django.utils.translation.trans_real import translation

trans_en = translation('en') 
trans_es = translation('es')

print trans_en.ugettext('word') 
print trans_es.ugettext('word')

Теперь в деталях. Функция-шоткат translation возвращает экземпляр объекта DjangoTranslation который в свою очередь является наследником объекта GNUTranslations. Чтоыб собрать нужный DjangoTranslation функция language собирает все django.mo файлы доступные в проекте.

Единственный, на мой взгляд минус такого подхода - скор



Работать надо меньше...

Минут пятнадцать сидел и "тупил" по поводу того, почему Джанго не хочет переводить строчку, когда локализация к ней написана и скомпилирована. Оказалось, что надо было просто лишь перегрузить девсервер.
Кстати, по поводу локализации: в грядущей версии 1.2 появится новый флажок с говорящим за себя названием - USE_L10N.



Советская власть и русификация всей страны

Обнаружил тут вдруг, что, несмотря на довольно хорошую поддержку интернационализации в Джанго, с локализацией не всё так тривиально, как хотелось бы. По сути надо было решить очень простую задачу - выводить локализованные имена месяцев в архиве новостей (хотя кто знает, что там дальше понадобится ещё). Есть, конечно, datetime.strftime, только вот он пляшет от текущей локали, которая задаётся на весь процесс и не управляется Джанго. В итоге поставил BabelDjango и использовал format_date(date, 'LLLL') оттуда.