Alterator/l10n
alterator-l10n
help
Старая схема
- хелпы хранятся в пакете alterator-l10n, устанавливаются в директорию /usr/share/alterator/l10n/help/ и не используются альтератором
- модуль, использующий хелп из alterator-l10n должен иметь сборочную зависимость на alterator-l10n
- при сборке модуля хелпы автоматически берутся из /usr/share/alterator/l10n/help/ и устанавливаются в директорию /usr/share/alterator/help/, где их и ищет альтератор.
- (неочевидная хитрость: хелп устанавливается только, если он упомянут в desktop-файле модуля)
Таким образом, при изменении хелпа в alterator-l10n следует пересобирать модуль.
Новая схема
- Хелп пакуется либо в alterator-l10n либо в модуль и в любом случае устанавливается сразу в /usr/share/alterator/help/
При правке хелпа пересборки модуля не требуется.
В 4.1 работает только старая схема, в 5.0 и Сизифе — обе схемы. Для поддержки двух схем в исходниках пакета alterator-l10n сделаны директории old_help и new_help. При переходе со старой схемы на новую надо следить, чтобы хелп не оказался запакован и в alterator-l10n и в модуль, и не возникло конфликта.
Переводы
Старая схема
- словарь, общий для всех модулей, лежит в alterator-l10n
- существует процедура обновления словаря, при которой по списку обновляются git-репозитории для всех модулей, использующих alterator-l10n, в них генерятся pot-файлы, берутся po-файлы и затем мерджатся с общим словарем внутри alterator-l10n.
- модуль, использующий переводы из alterator-l10n должен иметь сборочную зависимость на alterator-l10n
- при сборке модуля переводы автоматически берутся из alterator-l10n, создаётся отдельный словарь для данного модуля и устанавливается в систему.
Недостатки старой схемы
- При изменении модуля, приходится пересобирать alterator-l10n, а затем — опять модуль.
- При пересборке alterator-l10n требуется иметь актуальные git-репозитории для всех модулей, которые используют alterator-l10n (в том числе, за которыми я вообще не слежу). Дело осложнено тем, что для модулей альтератора сложилась традиция сборки, при которой неясно, в чьём репозитории в данный момент находится актуальная версия. Существуют, впрочем «нечестные» способы обновления базы переводов alterator-l10n.
- «Общий» файл переводов очень неудобно мерджить, в случае, если несколько человек параллельно обновляют alterator-l10n
- «Общий» файл переводов неудобно переводить без контекста.
- В модуле, не использующем alterator-l10n может быть нужна сборочная зависимость на модуль, использующий alterator-l10n. В этом случае локальные переводы пропадут из модуля.
Новая схема решает все эти проблемы.
Предложение новой схемы
- утилита update-module, для «мейнтейнеров модулей»: получает внешнюю директорию с модулем, обычным образом обновляет словарь для данного модуля (внутри altertator-l10n), берет недостающие переводы из общего словаря. После применения этой утилиты можно дополнить или исправить переводы только для данного модуля и сделать коммит, который затронет только словарь одного модуля.
- тривиальная возможность для переводчиков смерджить переводы всех модулей в общий словарь, посмотреть несоответствия, массово перевести на иностранный язык… Там, где нужен контекст, переводчики могут переводить словари отдельных модулей, а потом уже мерджить их…
- при сборке alterator-l10n собираются словари для всех модулей, причём опять недостающие переводы берутся из общего словаря.
Новая схема
В данный момент новая схема почти реализована и работает параллельно со старой. На неё переведены модули alterator-{x11,lilo,xinetd,services,samba}
С точки зрения мантейнера модуля устроено так:
- В alterator-l10n находится общий словарь (обновляется редко, «переводчиками»).
- Там же есть отдельные словари для каждого модуля (обновляются при обновлении модулей, «мейнтейнерами модулей»).
- Находясь в alterator-l10n обновляем словарь своего модуля модуля: ./update_module <директория с модулем>. При этом недостающие переводы берутся из общего словаря. (Директория с модулем - та, в которой живет Makefile)
- Правим переводы, относящиеся только к своему модулю в alterator-l10n/po/<язык>/<имя>.po
- Коммитим, пушим, просим мейнтейнера alterator-l10n втянуть…
- Из своего модуля убираем паковку mo-файлов (иначе будет конфликт!) и (если уже и хелп переведён на новую схему) вообще сборочную зависимость на alterator-l10n
- При сборке alterator-l10n для каждого модуля соберутся и установятся в систему mo-файлы. Причём недостающие переводы возьмутся из общего словаря.
С точки зрения переводчика:
- можно добавлять переводы в общий словарь (при пересборке alterator-l10n они добавятся во все модули)
- можно править переводы в модулях
- можно слить переводы модулей в общий словарь (msgcat), посмотреть на несоответствия переводов и разобраться с каждым несоответствующем модулем по отдельности
- Все это происходит внутри alterator-l10n, при изменениях модули пересобирать не нужно.
Некоторая особенность связана с переводами полей Name и Comment в desktop-файлах. Использовать gettext при разборе desktop-файлов не хочется (при этом для построения главного меню придется каждый перевод вытаскивать из своего словаря, что долго и странно), хочется переводы таскать внутри desktop-файлов, однако дать возможность переводчикам переводить их внутри alterator-l10n.
Сейчас сделано так:
- строчки для перевода вытаскиваются в alterator-l10n точно также, как и все остальное.
- запуская в alterator-l10n скрипт './update_desktop <директория с модулем>' мы обновляем desktop-файлы модуля...
Оставшаяся проблема: скрипт для сливания общего словаря из всех модулей — синяя стрелка на картинке. Это несложно сделать, но пока общий словарь используется для построения словарей модулей в старой схеме, это не нужно делать.