Когда должны создаваться файлы .mo?

Двоичные файлы MO необходимо создавать во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO, используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext) в конечном итоге создаст их.

Итак, чтобы ответить на последнюю часть вопроса, да, файлы MO зависят от машины. [ ! d5]

Создание файлов MO трудным путем

Теперь о том, как их создать, в стандартном макете gettext обычно будут все файлы PO в одном каталоге, по одному на каждый язык и именоваться после 2-буквенный или трехбуквенный код каждого из языков:

po/
po/ca.po
po/de.po
...

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

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Но вы не хотите этого делать, когда уже существует установленный способ и автоматизированные инструменты, созданные специально для работы с созданием файлов MO.

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

Создание файлов MO умным способом

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это построит все файлы PO в вашей папке /po и поместит их под build (это создаст если это не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение с помощью переводов либо: * Копирование содержимого /build на [ f13] или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain():

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Стоять на плече гигантов. Просто создайте тестовое приложение с помощью gettext.bindtextdomain() и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше. [ ! d20]

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска не должны включать файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для вашего приложения, а затем заменить исходный код Quickly для тестового приложения кодом вашего приложения.

Двоичные файлы MO должны быть сгенерированы во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO , используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext ) в конечном итоге создаст их.

po/
po/ca.po
po/de.po
...

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Если вы используете Python, я очень рекомендую использовать пакет python-distutils-extra (установить pde), который автоматизирует и скрывает сложность просто необходимо указать следующее в файле setup.py, которое вы будете использовать для сборки, установки и распространения вашего приложения. Тот же пример, что и @dobey, уже указывал на его ответ:

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это создаст все PO-файлы в вашей папке /po и поместит их под build (это создаст если он не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение на перевод или путем: * Копирование содержимого /build на /usr/share/locale или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain() :

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Встаньте на плечо гигантов. Просто создайте тестовое приложение с помощью Быстро и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше.

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска, не должен включают файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

• Создайте файл setup.py с содержимым, аналогичным указанному выше
• Создайте файлы управления упаковкой в ​​разделе debian /. Используя pde, ваш файл debian/rules может стать очень простым и состоять всего из нескольких строк.

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для ваше приложение, а затем замените исходный код Quickly для тестового приложения кодом вашего приложения.

Двоичные файлы MO должны быть сгенерированы во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO , используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext ) в конечном итоге создаст их.

po/
po/ca.po
po/de.po
...

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Если вы используете Python, я очень рекомендую использовать пакет python-distutils-extra (установить pde), который автоматизирует и скрывает сложность просто необходимо указать следующее в файле setup.py, которое вы будете использовать для сборки, установки и распространения вашего приложения. Тот же пример, что и @dobey, уже указывал на его ответ:

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это создаст все PO-файлы в вашей папке /po и поместит их под build (это создаст если он не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение на перевод или путем: * Копирование содержимого /build на /usr/share/locale или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain() :

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Встаньте на плечо гигантов. Просто создайте тестовое приложение с помощью Быстро и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше.

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска, не должен включают файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

• Создайте файл setup.py с содержимым, аналогичным указанному выше
• Создайте файлы управления упаковкой в ​​разделе debian /. Используя pde, ваш файл debian/rules может стать очень простым и состоять всего из нескольких строк.

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для ваше приложение, а затем замените исходный код Quickly для тестового приложения кодом вашего приложения.

Двоичные файлы MO должны быть сгенерированы во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO , используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext ) в конечном итоге создаст их.

po/
po/ca.po
po/de.po
...

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Если вы используете Python, я очень рекомендую использовать пакет python-distutils-extra (установить pde), который автоматизирует и скрывает сложность просто необходимо указать следующее в файле setup.py, которое вы будете использовать для сборки, установки и распространения вашего приложения. Тот же пример, что и @dobey, уже указывал на его ответ:

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это создаст все PO-файлы в вашей папке /po и поместит их под build (это создаст если он не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение на перевод или путем: * Копирование содержимого /build на /usr/share/locale или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain() :

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Встаньте на плечо гигантов. Просто создайте тестовое приложение с помощью Быстро и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше.

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска, не должен включают файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

• Создайте файл setup.py с содержимым, аналогичным указанному выше
• Создайте файлы управления упаковкой в ​​разделе debian /. Используя pde, ваш файл debian/rules может стать очень простым и состоять всего из нескольких строк.

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для ваше приложение, а затем замените исходный код Quickly для тестового приложения кодом вашего приложения.

Двоичные файлы MO должны быть сгенерированы во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO , используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext ) в конечном итоге создаст их.

po/
po/ca.po
po/de.po
...

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Если вы используете Python, я очень рекомендую использовать пакет python-distutils-extra (установить pde), который автоматизирует и скрывает сложность просто необходимо указать следующее в файле setup.py, которое вы будете использовать для сборки, установки и распространения вашего приложения. Тот же пример, что и @dobey, уже указывал на его ответ:

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это создаст все PO-файлы в вашей папке /po и поместит их под build (это создаст если он не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение на перевод или путем: * Копирование содержимого /build на /usr/share/locale или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain() :

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Встаньте на плечо гигантов. Просто создайте тестовое приложение с помощью Быстро и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше.

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска, не должен включают файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

• Создайте файл setup.py с содержимым, аналогичным указанному выше
• Создайте файлы управления упаковкой в ​​разделе debian /. Используя pde, ваш файл debian/rules может стать очень простым и состоять всего из нескольких строк.

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для ваше приложение, а затем замените исходный код Quickly для тестового приложения кодом вашего приложения.

Двоичные файлы MO должны быть сгенерированы во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO , используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext ) в конечном итоге создаст их.

po/
po/ca.po
po/de.po
...

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Если вы используете Python, я очень рекомендую использовать пакет python-distutils-extra (установить pde), который автоматизирует и скрывает сложность просто необходимо указать следующее в файле setup.py, которое вы будете использовать для сборки, установки и распространения вашего приложения. Тот же пример, что и @dobey, уже указывал на его ответ:

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это создаст все PO-файлы в вашей папке /po и поместит их под build (это создаст если он не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение на перевод или путем: * Копирование содержимого /build на /usr/share/locale или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain() :

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Встаньте на плечо гигантов. Просто создайте тестовое приложение с помощью Быстро и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше.

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска, не должен включают файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

• Создайте файл setup.py с содержимым, аналогичным указанному выше
• Создайте файлы управления упаковкой в ​​разделе debian /. Используя pde, ваш файл debian/rules может стать очень простым и состоять всего из нескольких строк.

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для ваше приложение, а затем замените исходный код Quickly для тестового приложения кодом вашего приложения.

Двоичные файлы MO должны быть сгенерированы во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO , используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext ) в конечном итоге создаст их.

po/
po/ca.po
po/de.po
...

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Если вы используете Python, я очень рекомендую использовать пакет python-distutils-extra (установить pde), который автоматизирует и скрывает сложность просто необходимо указать следующее в файле setup.py, которое вы будете использовать для сборки, установки и распространения вашего приложения. Тот же пример, что и @dobey, уже указывал на его ответ:

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это создаст все PO-файлы в вашей папке /po и поместит их под build (это создаст если он не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение на перевод или путем: * Копирование содержимого /build на /usr/share/locale или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain() :

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Встаньте на плечо гигантов. Просто создайте тестовое приложение с помощью Быстро и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше.

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска, не должен включают файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

• Создайте файл setup.py с содержимым, аналогичным указанному выше
• Создайте файлы управления упаковкой в ​​разделе debian /. Используя pde, ваш файл debian/rules может стать очень простым и состоять всего из нескольких строк.

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для ваше приложение, а затем замените исходный код Quickly для тестового приложения кодом вашего приложения.

Двоичные файлы MO должны быть сгенерированы во время сборки. Это означает, что ваша система сборки должна иметь цель сборки, чтобы читать текстовые файлы PO , используемые в качестве источника, и преобразовывать их в бинарные файлы MO, которые будут установлены в системе пользователя. Как вы правильно заметили, команда msgfmt (часть инструментов gettext ) в конечном итоге создаст их.

po/
po/ca.po
po/de.po
...

$ msgfmt -c po/ca.po -o build/locale/LC_MESSAGES/ca/myapp.mo

Если вы используете Python, я очень рекомендую использовать пакет python-distutils-extra (установить pde), который автоматизирует и скрывает сложность просто необходимо указать следующее в файле setup.py, которое вы будете использовать для сборки, установки и распространения вашего приложения. Тот же пример, что и @dobey, уже указывал на его ответ:

DistUtilsExtra.auto.setup(
    name='myapp',
    version='0.1',
    #license='GPL-3',
    #author='Your Name',
    #author_email='email@ubuntu.com',
    #description='UI for managing …',
    #long_description='Here a longer description',
    #url='https://launchpad.net/myapp'
)

Это позаботится обо всем для вас.

Если вы хотите проверить перевод перед отправкой, вы может использовать удобную команду build_i18n из python-distutils-extra:

$ python setup.py build_i18n

Это создаст все PO-файлы в вашей папке /po и поместит их под build (это создаст если он не существует) в том же макете gettext ожидает, когда они будут установлены в системе.

Затем вы можете проверить свое приложение на перевод или путем: * Копирование содержимого /build на /usr/share/locale или * Указание вашего приложения на каталог сборки с помощью функции gettext.bindtextdomain() :

gettext.bindtextdomain(domain='myapp', localedir='/home/me/dev/myapp/build')

Быть даже умнее

Встаньте на плечо гигантов. Просто создайте тестовое приложение с помощью Быстро и скопируйте, как переводы настроены в setup.py, что в основном сводится к использованию модуля DistutilsExtra в режиме auto, как описано выше.

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

Упаковка

tarball, который вы собрали вместе в качестве части выпуска, не должен включают файлы .mo. То есть вам не нужно создавать их вручную. Это должно произойти, когда кто-то создает содержимое tarball для установки вручную или когда, например, создается бинарный пакет Debian.

Глядя на исходное дерево, я бы предложил снова использовать систему сборки, такую ​​как python-distutils-extra, которая также поможет в упаковке. Пример:

• Создайте файл setup.py с содержимым, аналогичным указанному выше
• Создайте файлы управления упаковкой в ​​разделе debian /. Используя pde, ваш файл debian/rules может стать очень простым и состоять всего из нескольких строк.

На самом деле вы можете просто использовать Quickly для создания жгута для системы сборки и упаковки для ваше приложение, а затем замените исходный код Quickly для тестового приложения кодом вашего приложения.