# General Translation Knowledge Base: General Translation и GNU gettext: нужны ли оба? URL: https://generaltranslation.com/ru/kb/general-translation-vs-gettext.mdx Docs index: https://generaltranslation.com/llms.txt Description: Оставьте GNU gettext для извлечения и рендеринга, а General Translation подключите для генерации и сопровождения PO-файлов. General Translation учитывает при генерации заметки для переводчиков и контекст сообщений, применяет общую терминологию и предоставляет рецензентам редактор в панели управления. Существующие вызовы gettext и скомпилированные каталоги остаются на месте. Category: Интернационализация Last updated: 2026-10-16 Authors: Kevin Wu, Jackie Chen Published: 2026-10-16 GNU gettext — набор инструментов, на котором до сих пор держится бо́льшая часть перевода программного обеспечения. Вы оборачиваете видимые пользователю строки в `_()` или `gettext()`, `xgettext` извлекает их в шаблон POT, `msginit` создаёт PO-файл для каждого языка, `msgmerge` обновляет эти файлы при изменении источника, а `msgfmt` компилирует их в файлы `.mo`, которые программа загружает во время выполнения. Этот формат используют программы на C, расширение gettext для PHP, модуль `gettext` в Python, WordPress, Django и Babel. Но бо́льшую часть самого перевода gettext оставляет вам: начиная с версии 1.0 он умеет готовить черновики записей с помощью локальной LLM, однако каждый `msgstr` в каждом PO-файле доводите до ума вы, ваши переводчики или сторонний сервис. General Translation не заменяет ни один из этих инструментов: его CLI создаёт PO-файлы на основе вашего шаблона, а остальная настройка gettext остаётся прежней. ## Video The video is narrated in English, with English captions. [General Translation vs. GNU gettext: do you need both?](https://caxecubb9c64cezv.public.blob.vercel-storage.com/films/kb-general-translation-vs-gettext.mp4) (46 с) Keep GNU gettext for extraction and rendering, and let General Translation generate and maintain the PO files, with translator notes, message context, shared terminology, and Dashboard review. To set it up, point `gt.config.json` at your POT template with a transform for each language, and run `npx gt translate` between xgettext and msgfmt in your build. ## В чём gettext силён * **Ключом служит исходный текст.** В коде пишется `_("Inbox")`, а не имя ключа, а для строки без перевода [выводится исходный текст](https://www.gnu.org/software/gettext/manual/html_node/Interface-to-gettext.html), а не ошибка. * **Правила множественного числа для каждого языка.** Каждый PO-файл содержит [заголовок `Plural-Forms` с правилом для своего языка](https://www.gnu.org/software/gettext/manual/html_node/Plural-forms.html), и `msginit` заполняет его за вас. Для польского задаётся правило с тремя формами и три слота `msgstr[n]` в каждой записи с множественным числом. * **Контекст хранится вместе со строкой.** `msgctxt` (из `pgettext`) [позволяет различать «Archive»-глагол и «Archive»-существительное](https://www.gnu.org/software/gettext/manual/html_node/Contexts.html), комментарии `#.` передают заметки переводчикам (`xgettext --add-comments`), строки `#:` указывают на место в исходниках, а флаги вроде `python-format` позволяют `msgfmt --check` отклонить перевод, в котором сломана подсказка. * **Безопасные обновления.** `msgmerge` [сохраняет существующие переводы при изменении шаблона](https://www.gnu.org/software/gettext/manual/html_node/msgmerge-Invocation.html) и помечает записи с изменившимся источником как fuzzy, сохраняя прежний исходный текст для сравнения (`--previous`). * **Черновики от локальной LLM.** Начиная с версии 1.0, [`msgpre` и `spit` выполняют предварительный перевод PO-файлов](https://www.gnu.org/software/gettext/manual/html_node/Pretranslating.html) с помощью локально установленной LLM через ollama. Результат служит отправной точкой, которую затем проверяет переводчик. * **Повсеместная поддержка.** PO-файлы читают и записывают PO-редакторы вроде Poedit и большинство систем управления переводами (TMS), а сами инструменты — [свободное ПО](https://www.gnu.org/software/gettext/manual/html_node/Licenses.html) (GPL; библиотека среды выполнения распространяется под LGPL). ## Что gettext перекладывает на вас Вот небольшой скрипт на Python, использующий модуль `gettext` из стандартной библиотеки: ```python title="inbox.py" import gettext, sys lang = sys.argv[1] count = int(sys.argv[2]) t = gettext.translation("inbox", localedir="locale", languages=[lang], fallback=True) _ = t.gettext # TRANSLATORS: заголовок страницы «Входящие» print(_("Inbox")) print(t.ngettext("You have %d unread message.", "You have %d unread messages.", count) % count) print(t.pgettext("email verb", "Archive")) ``` Рабочий процесс gettext в [GNU gettext 1.0](https://lists.gnu.org/archive/html/info-gnu/2026-01/msg00007.html): ```bash xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py msginit --no-translator --locale=pl_PL.UTF-8 -i po/inbox.pot -o po/pl.po # кто-нибудь заполняет все msgstr в po/pl.po msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po ``` Как только польский файл будет заполнен, `python3 inbox.py pl 5` выведет «Masz 5 nieprzeczytanych wiadomości.» Затем кто-то меняет в коде «unread message» на «new message». `xgettext` и `msgmerge --update --previous` переносят старый польский вариант и помечают его как fuzzy, поскольку теперь это перевод другого текста: ```text title="po/pl.po" #: inbox.py:10 #, fuzzy, python-format #| msgid "You have %d unread message." #| msgid_plural "You have %d unread messages." msgid "You have %d new message." msgid_plural "You have %d new messages." msgstr[0] "Masz %d nieprzeczytaną wiadomość." msgstr[1] "Masz %d nieprzeczytane wiadomości." msgstr[2] "Masz %d nieprzeczytanych wiadomości." ``` `msgfmt` [пропускает нечёткие (fuzzy) записи](https://www.gnu.org/software/gettext/manual/html_node/msgfmt-Invocation.html) (и сообщает "2 translated messages, 1 fuzzy translation"), поэтому та же команда теперь выводит "You have 5 new messages." по-английски — прямо посреди польского экрана. В старом польском переводе по-прежнему написано «непрочитанных», так что его нужно обновить. General Translation может сгенерировать обновлённый перевод из нового шаблона прямо в процессе сборки. ## Перевод каталогов gettext с помощью General Translation CLI от General Translation считывает ваш POT-шаблон, переводит каждую запись и создаёт PO-файл для каждого языка перевода. Укажите в `gt.config.json` путь к шаблону и место, куда сохранять файл для каждого языка. Эта конфигурация проверена на `gt` 2.26.5: ```json title="gt.config.json" { "defaultLocale": "en", "locales": ["de", "pl", "pt_BR"], "customMapping": { "pt_BR": { "code": "pt-BR" } }, "files": { "pot": { "include": ["po/inbox.pot"], "transform": { "match": "^po/inbox\\.pot$", "replace": "po/{locale}.po" }, "transformationFormat": "PO" } } } ``` * **`pot` читает файлы PO и POT**, а `"transformationFormat": "PO"` задаёт формат вывода — переведённые файлы `.po`. (См. [справочник по формату PO / POT](/docs/cli/reference/formats/po-pot-files).) * **`transform` задаёт имена выходных файлов.** `{locale}` подставляет локаль точно в том виде, в каком она записана в `locales`, поэтому на выходе получаются `po/pl.po` и `po/pt_BR.po`. (См. [`transform`](/docs/cli/reference/config#files).) * **Сохраняйте имена локалей gettext.** [`customMapping`](/docs/cli/reference/config#custom-mapping) сопоставляет `pt_BR` со стандартным кодом локали `pt-BR`. Этот же паттерн подходит и для других структур, например для `languages/my-plugin.pot` и `languages/my-plugin-de_DE.po` в плагине WordPress. После настройки CLI (см. [Быстрый старт CLI](/docs/cli/quickstart)) рабочий процесс выглядит так: ```bash xgettext --language=Python --keyword=pgettext:1c,2 --add-comments=TRANSLATORS -o po/inbox.pot inbox.py msgconv --to-code=UTF-8 -o po/inbox.pot po/inbox.pot npx gt translate msgfmt --check -o locale/pl/LC_MESSAGES/inbox.mo po/pl.po ``` `xgettext` оставляет `charset=CHARSET` в заголовке шаблона как подсказку, а `msgconv` заменяет его на UTF-8 — так же, как это сделал бы `msginit` для языкового файла. [`npx gt translate`](/docs/cli/reference/commands/translate) отправляет каждую запись вместе со всем, что о ней известно из PO-файла, в качестве контекста: `msgctxt`, комментарии для переводчиков `#.`, ссылки `#:` и флаги формата. Для записи с формами множественного числа General Translation прописывает заголовок `Plural-Forms` языка перевода и заполняет все слоты `msgstr[n]`, которых требует этот заголовок (три для польского, шесть для арабского), а также проверяет, что подсказки вроде `%d` сохраняются без изменений. Если `msgid` меняется, при следующем запуске General Translation сгенерирует перевод нового текста; для неизменённых записей используются прежние переводы. Перед первым запуском генерации импортируйте существующие переводы из PO-файлов с помощью [`npx gt upload`](/docs/cli/reference/commands/upload). Если позже вы правите файлы в локальном PO-редакторе, [`npx gt save-local`](/docs/cli/reference/commands/save-local) сохранит эти правки на платформе перед очередной генерацией. Но General Translation не ограничивается заполнением `msgstr` — он предоставляет весь остальной стек. Glossary и пользовательские промпты в [контекстной группе](/docs/platform/dashboard/guides/defining-context-for-translations) обеспечивают единообразие терминологии и тона во всех PO-файлах и любых других областях взаимодействия с пользователем, которые вы переводите. Рецензенты могут [проверять и редактировать](/docs/platform/dashboard/guides/reviewing-translations) каждую запись PO — с учётом форм множественного числа языка перевода — в панели управления, а CLI работает в CI, так что каждый релиз выходит с актуальными каталогами. Запускайте CLI для Node.js в процессе сборки, а затем компилируйте полученные PO-файлы с помощью `msgfmt`. Приложение, как и раньше, загружает скомпилированные переводы локально. ## GNU gettext и General Translation: краткое сравнение | Возможность | GNU gettext | General Translation | | ------------------------------------------------ | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | Извлечение строк из кода | Да, `xgettext` | Использует ваш существующий шаблон POT | | Создание файла для каждого языка | Да, `msginit` | Да, на основе шаблона, для каждой настроенной локали | | Создание переводов | С версии 1.0 готовит черновики с помощью локальной LLM, которые дорабатывает переводчик | Да, с помощью [`npx gt translate`](/docs/cli/reference/commands/translate) | | После изменения исходной строки | `msgmerge` помечает её как fuzzy до проверки | Переводится заново при следующем запуске; неизменённые записи используются повторно | | Формы множественного числа | `msginit` записывает заголовок; каждый слот заполняете вы | Записывает заголовок и заполняет все слоты | | Контекст для перевода | `msgctxt`, комментарии переводчика, ссылки, флаги | То же самое, а также Glossary и пользовательские промпты | | Компиляция и поиск переводов во время выполнения | Да, `msgfmt` и среда выполнения gettext | Сохраняет ваш компилятор и среду выполнения gettext | | Стоимость | Свободное ПО | [Оплата перевода по факту использования](https://generaltranslation.com/pricing) | ## Когда что использовать Используйте только gettext, если ваши PO-файлы уже заполняют переводчики или TMS, если каждый перевод должен написать человек до выпуска или если в вашей сборке нельзя запустить Node.js. Подключите General Translation, если хотите, чтобы каждый PO-файл переводился на все языки сразу после изменения шаблона — с заполненными слотами множественного числа и единообразной терминологией, — не дожидаясь очередного раунда перевода. Мигрировать ничего не нужно: General Translation сохраняет ваши вызовы `_()`, шаблон, PO-файлы и среду выполнения. Он заменяет ручной этап между `msgmerge` и `msgfmt`. (Варианты настройки для конкретных фреймворков см. в статьях [General Translation и фреймворк перевода Django](/kb/general-translation-vs-django-i18n) и [General Translation и Babel с Flask-Babel](/kb/general-translation-vs-flask-babel).) ## Основные выводы * GNU gettext извлекает, объединяет, компилирует и находит переводы, а начиная с версии 1.0 умеет готовить их черновики с помощью локальной LLM, но до конца работу не доводит. Новые и изменённые строки остаются на языке-источнике, пока кто-нибудь их не переведёт или не проверит. * CLI General Translation переводит шаблон POT в отдельный PO-файл для каждого языка. Для этого используются ключ `pot`, параметр `"transformationFormat": "PO"`, `transform` для пути выходного файла и `customMapping` для имён вроде `pt_BR`. * Для каждой записи с формами множественного числа General Translation прописывает заголовок `Plural-Forms` для языка перевода и заполняет все слоты `msgstr[n]`, используя `msgctxt` и комментарии переводчика в качестве контекста. `msgfmt` и ваша среда выполнения gettext остаются без изменений. ## Related questions - [General Translation и фреймворк переводов Django: нужны ли оба?](https://generaltranslation.com/ru/kb/general-translation-vs-django-i18n.mdx): Используйте фреймворк переводов Django вместе с General Translation. Django отвечает за извлечение сообщений, выбор языка и рендеринг. General Translation заполняет его PO-файлы, включая формы множественного числа, с учётом терминологии вашего продукта и проверки в панели управления. Ваши шаблоны и URL-шаблоны остаются прежними, а переводы обновляются вместе с кодом. - [General Translation или Babel и Flask-Babel: что выбрать?](https://generaltranslation.com/ru/kb/general-translation-vs-flask-babel.mdx): Babel форматирует даты, числа и валюты для любой локали и управляет каталогами gettext, а Flask-Babel интегрирует его с Flask, но ни один из них не переводит ваши строки. CLI General Translation заполняет PO-файлы Babel для всех языков, включая формы множественного числа, поэтому вы можете и дальше использовать Flask-Babel, но больше не переводить каталоги вручную. - [General Translation или TMS (Crowdin, Lokalise, Phrase)](https://generaltranslation.com/ru/kb/general-translation-vs-tms.mdx): Выбирайте General Translation, если разработчикам нужны генерация переводов, контекст из кода и проверка, привязанные к релизам продукта. Сохраните существующие каталоги и библиотеку рендеринга или пишите встроенный JSX без ключей перевода. TMS подходит для программ, построенных вокруг языковых поставщиков, CAT-редакторов и обмена XLIFF; её интеграции могут автоматизировать передачу файлов. - [General Translation или Weblate: что выбрать?](https://generaltranslation.com/ru/kb/general-translation-vs-weblate.mdx): Weblate — это платформа локализации на основе Git, которую можно развернуть на собственном сервере. Она создана для перевода файлов репозитория силами сообщества или команды. General Translation встраивает генерацию переводов в разработку и релизы, опираясь на размеченный JSX и общий контекст продукта. Оставьте свои файлы gettext или перейдите на написание текста непосредственно в коде — тогда отпадёт и необходимость поддерживать каталог исходных сообщений. - [Какое ПО для локализации лучше всего подходит разработчикам?](https://generaltranslation.com/ru/kb/best-localization-software.mdx): Лучшее ПО для локализации для разработчиков переводит контент прямо там, где он написан в коде, учитывает контекст вашего продукта и поддерживает все языки в актуальном состоянии. General Translation делает это с помощью библиотек с открытым исходным кодом, контекстных групп и Locadex — AI-агента, который открывает пул-реквесты. ## Previous and next questions - Previous question: [Можно ли делать i18n без файлов перевода?](https://generaltranslation.com/ru/kb/i18n-without-translation-files.mdx) - Next question: [General Translation и Rails I18n: нужны ли оба?](https://generaltranslation.com/ru/kb/general-translation-vs-rails-i18n.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/ru/kb/sitemap.md) for every article.