Как правильно использовать gettext с git?

Question

У меня есть небольшое приложение, которое я разрабатываю и раздаю;Теперь я хотел бы добавить поддержку i18n с помощью gettext.Я вижу, что gettext требует выполнения нескольких команд и генерации различных файлов (и их обновления, когда в исходный код включаются новые строки).

Как обычно gettext взаимодействует с типичным рабочим процессом git?Должен ли я сам сгенерировать свой .pot файл и включить его в репозиторий, или он должен генерироваться автоматически во время сборки моим Makefile?Что насчет .mo файлов?Точно так же мне нужно включить msgmerge в мой скрипт сборки, или я просто добавляю его результат в контролируемые версиями файлы?

Я использую C ++, рукописный Makefile (без automake) иgithub, на случай, если это имеет значение.

Answer 1

Здесь задействованы три типа файлов, и все они генерируются, по крайней мере, вида.

1. Файл шаблона .pot PO, содержащий каталог главного сообщения.Это находится под контролем версий в каждом известном мне проекте, хотя он строго сгенерирован и избыточен.

2. Файлы .po с отдельными переводами.Они иногда генерируются, иногда нет.Когда вы объединяете новые строки с msgmerge, они генерируются.Но когда ваши переводчики отправляют обратно новый перевод, это не так.У вас есть , чтобы поставить их под контроль версий, поскольку они содержат переводы.

3. Файлы .mo, к которым компилируются файлы .po.Не ставьте их под контроль версий, а отправляйте их с выпусками (исходными и двоичными).

Более важна логика в вашем Makefile.Ни один из вышеупомянутых файлов не должен генерироваться автоматически, но только по требованию.В противном случае ваш каталог po/ будет грязным, когда вы редактируете исходный файл.

ИМХО, лучше всего убедиться, что клон git может быть собран без установленных инструментов gettext (xgettext, msgmerge, msgfmt),Убедитесь, что они вызываются только по требованию.

Привязка Perl для gettext libint-perl (заявление об отказе: я автор) содержит пример каталога po с полным Makefile: https://github.com/gflohr/libintl-perl/tree/master/sample/simplecal/po. Вы можетевозможно, используйте этот Makefile прямо в вашем проекте.Вам нужно всего лишь изменить вызов xgettext для выбранного вами языка программирования.

Answer 2

Я не уверен, что это правильный вопрос для SO.

Тем не менее, ответ "это решать вам".Проекты делают это обоими способами, и у каждого есть свои плюсы и минусы.Многое из этого зависит от (а) того, сколько у вас есть участников и (б) насколько легко вы хотите, чтобы другие люди могли делать сборку прямо из вашего Git-репозитория.

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

Если вы этого не сделаетепроверьте ваши производные файлы, затем ваш репозиторий станет намного чище и, абстрактно, более «правильным» (точно так же, как вы не ожидаете, что люди будут проверять объектные файлы, которые генерируются во время компиляции).Однако любой, кто хочет создать код, должен будет установить набор инструментов самостоятельно.В системах GNU / Linux это довольно тривиально, но в некоторых других это не так.Обычно люди, делающие этот выбор, предоставляют сценарий оболочки, который «подготавливает» исходный каталог.

Одно предостережение с первым методом: даже если вы проверяете все производные файлы, вам, вероятно, потребуется написать и запустить некоторые из них.своего рода «подготовительный» скрипт, предполагающий, что вы используете make и пишете make-файлы, чтобы поддерживать ваши файлы gettext в актуальном состоянии: Git не сохраняет временные метки, поэтому, если вы хотите избежать пересоздания производных файлов после того, как они были клонированы или извлечены,вам нужно запустить небольшой скрипт, который будет touch файлов в правильном порядке, чтобы make знал, что они обновлены.

FWIW, я лично никогда не проверяю какие-либо производные файлы в своих репозиториях.Я признаю, что это усложняет жизнь некоторым пользователям, но, по-моему, это правильный путь.