Думаю, многим известен такой пакет, как Babel или PyBabel. Отличный пакет локализации, основанный на gettext, как и все остальное (по крайней мере, то, о чем я знаю) в современном мире.
Возникла задача подготовить сайт к будущей локализации, все шаблоны делались в Handlebars, этот шаблонизатор в первую очередь использовался как ориентир для подружки с ним.
Вопрос в том, кто.
Должен заранее прояснить, что никаких ограничений в выборе технологий у меня не было.
В конечном итоге для сборки статики мы используем полный набор — Ruby(compass), node(coffee,grunt,requirejs), python(бэкенд и основа всего), шелл-скрипты, в общем ограничений нет. Кстати, если кому интересно, могу подробно написать про сборку сборки в отдельном посте, для этого требуется js+scss+все вышеперечисленное, на данный момент в сборку включено около 1000+ файлов + развертывание на Heroku и не-Heroku с одной кнопкой.
На мой взгляд процесс в целом интересный, но не знаю на чем лучше сосредоточить внимание То есть по сути всё, что нужно было найти, это кто способен: а) Просмотрите шаблоны рулей б) Уметь работать по тому же принципу, что и Babel - то есть ключом является строка, а не константы, когда всё хранится в отдельных файлах.
в) Подготовьте файл .
po из найденных строк.
Тогда ваши руки свободны и возможностей достаточно.
Потратив несколько часов на поиски, вывод оказался неутешительным, этого почему-то никто не сделал.
Мне категорически не хотелось в это верить, но все, что существовало, было «неправильным» и «неправильным».
Что могли и могли сделать существующие решения? Строки с регулярками выдирали с разной степенью успеха.
Они не знали, как работать с ngettext, или не умели работать по принципу «строка=ключ», а только константы.
Все это необходимо было устранить.
Задача сразу была разбита на пункты, я тоже возьму минутку и опишу всю цепочку, чего я хотел добиться.
1) Определите текст перевода в шаблонах, принцип «строка=ключ».
Это гораздо удобнее использовать, чем когда ключ = имя константы.
Цена ошибки также меньше, максимум каждый получит текст на английском языке вместо перевода.
2) Передайте в Babel текст, а также номер строки.
Это необходимо, потому что во время обновлений Babel не сможет определить, что именно изменилось, если у него нет номеров строк.
3) Создать файлы .
po из строк, это и есть задача.
Вавилон -А 4) После перевода сделайте файлы .
json из файлов .
po и передайте их кому-нибудь еще на стороне клиента.
Конверсия – это задача po2json 5) Сделать помощники для рулей, как однострочные, так и блочные, с поддержкой ngettext. Опять разнообразие ради повседневного удобства 6) Оба варианта должны уметь работать с параметрами 7) Оба варианта должны передать текст для перевода «наверх», тому, кто держит те самые .
json-файлы 8) Этот же кто-то должен подставить в конечную строку параметры, полученные из шаблона.
Был выбран 8-й пункт Джед , отличная библиотека со встроенным sprintf, которая сразу решила проблему удобной передачи параметров.
Первый пункт был ключевым; Я нигде этого не видел.
Я долго смотрел на регулярные выражения и думал о своем — мне не все понравилось.
Кривой, недостаточный, ненадежный.
Еще больше времени я потратил на просмотр кода шаблона, скомпилированного в JavaScript. Отсюда получить линии было достаточно легко.
Но сама идея такого подхода приводила в ужас.
Кроме того, это не решило проблему, заключающуюся в том, что нужно знать, где в исходном шаблоне была найдена строка.
Мне пришлось посмотреть исходный код руля, и тогда меня осенило — его лексер был написан с использованием jison, а парсер jisona, который использует лексикон непосредственно из руля, был встроен внутри.
И вызов метода Руль.
parse (шаблон) вы можете получить структуру JSON шаблона.
Казалось бы, все здорово — но номеров строк по-прежнему нет. Но счастье было близко и оставалось копать в том же направлении - но уже в собранном руле, в коде сгенерированного парсера, оставалось найти правильное место, куда вписать две строки и вуаля, на выходе получается шаблонная структура , где для каждого блока указаны начальная и конечная строки.
Все это есть в самом парсере, оно просто не было передано наружу в нужное время в нужном месте.
Дальше дело техники, собрать все воедино, прикрутить к бабелю как экстрактор Те: Функция Python (экстрактор), которая вызывает скрипт node.js, который загружает исправленный handlebars.js. Далее этот скрипт рекурсивно проходит по структуре, собирает строки и возвращает их экстрактору в нужном ему формате.
Вся вавилонская логика остается неизменной.
Логика получения строк также является встроенной в handlebars.js. Все это не может нас не радовать.
Конечно, этот пост не имел бы смысла без следующих строк.
Думаю, что хоть кому-то сэкономлю время, потраченное на поиск правильного направления экспорта строк.
— pip install pybabel-hbs — github.com/tigrawap/pybabel-hbs Пакет устанавливается вместе с пропатченными рулями, а в исходниках есть примеры реализации хелперов (правда, на кофе) Само использование в шаблонах лично для меня оказалось идеальным, 4 помощника на GitHub, вот самый толстый, для наглядности
Вам нужно добавить его в конфиг Babel.{{#ntrans num_to_check_aganst param_1="something" num=num_to_check_against}} Some text to be translated with %(param_1)s and %(num)s {{else}} Some plural text to be translated with %(param_1)s and %(num)s {{/ntrans}}
[hbs: path/to/project/**.
hbs]
Для работы вам необходимо иметь в среде node.js. В планах оптимизация, чтобы node.js запускался не каждый раз для каждого файла отдельно, а один раз за всю жизнь основного процесса Babel. Это было реализовано в версии 0.2.0, пока пост находился на модерации.
Конечно, ускорение оказалось неплохим, пачка из 150 шаблонов стала обрабатываться за ~ минуту.
До этого это занимало пару минут, что было совершенно недопустимо.
Но даже минута – это слишком много для такого звонка.
Он был существенно (еще в 4 раза) оптимизирован за счет того, что изначально я передавал данные в node.js из python через pexpect, но теперь (версия 0.2.1) передаю только имя файла и node.js его читает. (минус здесь, конечно, в том, что оба файла по очереди открывают) Теперь обработка 150 файлов занимает менее 15 секунд. Есть еще возможности ускорить этот процесс, но на данный момент я этим доволен.
С учетом того, что запускать его не придется часто, результат достаточно хороший.
— Мораль этой истории такова: прежде чем тратить часы на написание и тестирование регулярных выражений в поисках обходных способов анализа любого языка, вам следует посмотреть, как он анализирует себя.
Может быть, так проще.
В конечном итоге вся проблема решилась несколькими строками, прописанными в самом handlebars.js, а то, что сегодня предлагается в Интернете,.
как минимум не удобно.
Теги: #handlebars #handlebars #handlebars #локализация #JavaScript #i18n #babel #разработка сайтов #python #JavaScript
-
Узнайте Об Аппаратных Кейлоггерах
19 Oct, 24 -
Сколько Вы Должны Платить За Оплату За Клик?
19 Oct, 24 -
Заметки Компьютерщика. Zsh Оболочка
19 Oct, 24 -
Разведка С Помощью Geo2Ip И Обратного Whois
19 Oct, 24 -
Дизайн Против Макета?
19 Oct, 24 -
Как Создать Музыку Для Видеоигры
19 Oct, 24
