# General Translation Knowledge Base: General Translation и фреймворк переводов Django: нужны ли оба?
URL: https://generaltranslation.com/ru/kb/general-translation-vs-django-i18n.mdx
Docs index: https://generaltranslation.com/llms.txt
Description: Используйте фреймворк переводов Django вместе с General Translation. Django отвечает за извлечение сообщений, выбор языка и рендеринг. General Translation заполняет его PO-файлы, включая формы множественного числа, с учётом терминологии вашего продукта и проверки в панели управления. Ваши шаблоны и URL-шаблоны остаются прежними, а переводы обновляются вместе с кодом.
Category: Интернационализация
Last updated: 2026-10-16
Authors: Kevin Wu, Jackie Chen
Published: 2026-10-16

В Django встроен полноценный фреймворк интернационализации (i18n): вы помечаете строки с помощью `gettext` и `{% translate %}`, `makemessages` извлекает их в PO-файл для каждого языка, `compilemessages` собирает `.mo`-файлы, которые загружает Django, а `LocaleMiddleware` выбирает язык для каждого запроса. General Translation добавляет этап перевода между извлечением и компиляцией: его CLI считывает ваш английский каталог и записывает переведённые PO-файлы, которые затем загружает Django.

## Что фреймворк перевода Django делает хорошо

* **Разметка строк в любом месте.** `gettext` и `ngettext` [покрывают код на Python](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#internationalization-in-python-code), `gettext_lazy` — строки, определяемые во время импорта, например поля моделей и метки форм, `pgettext` добавляет контекст к неоднозначным словам, а `{% translate %}` и `{% blocktranslate %}` (с `count` для форм множественного числа) покрывают шаблоны.
* **Встроенные извлечение и компиляция.** `makemessages` прогоняет `xgettext` из GNU gettext по вашим файлам Python и шаблонам и [добавляет новые строки в файл `django.po`](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#message-files) для каждого языка в `locale/<locale>/LC_MESSAGES/`. Комментарий `# Translators:` над строкой попадает в PO-файл, где его увидит переводчик.
* **Выбор языка для каждого запроса.** `LocaleMiddleware` [проверяет префикс URL](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#how-django-discovers-language-preference), добавленный `i18n_patterns`, затем языковой cookie-файл, затем заголовок `Accept-Language`, затем `LANGUAGE_CODE`. Выбираются только языки из `LANGUAGES`, а при отсутствии `de-at` используется `de`.
* **Не только строки.** Даты и числа [форматируются согласно активной локали](https://docs.djangoproject.com/en/5.2/topics/i18n/formatting/), а `JavaScriptCatalog` отдаёт браузеру отдельный каталог `djangojs`.
* **Сам Django уже переведён.** Админка и встроенные приложения [поставляются с каталогами примерно для сотни языков](https://github.com/django/django/tree/stable/5.2.x/django/contrib/admin/locale), а сам фреймворк распространяется бесплатно по лицензии BSD.

## Что Django оставляет вам

[Документация Django](https://docs.djangoproject.com/en/5.2/topics/i18n/translation/#compiling-message-files) описывает шаг, который фреймворк не берёт на себя: когда переводчики заполнят файл сообщений, его нужно скомпилировать. Вот шаблон с формами множественного числа:

```html title="shop/templates/shop/inbox.html"
{% load i18n %}
<p>{% blocktranslate count counter=count %}{{ counter }} file{% plural %}{{ counter }} files{% endblocktranslate %}</p>
```

В Django 5.2 команда `python manage.py makemessages -l ru` берёт из собственного каталога Django правило множественного числа для русского языка с четырьмя формами и копирует его в заголовок, но для самой записи создаёт лишь два пустых слота:

```text title="locale/ru/LC_MESSAGES/django.po"
"Plural-Forms: nplurals=4; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && "
"n%10<=4 && (n%100<12 || n%100>14) ? 1 : n%10==0 || (n%10>=5 && n%10<=9) || "
"(n%100>=11 && n%100<=14)? 2 : 3);\n"

#: shop/templates/shop/inbox.html:2
#, python-format
msgid "%(counter)s file"
msgid_plural "%(counter)s files"
msgstr[0] ""
msgstr[1] ""
```

В тесте после заполнения только этих двух слотов получился каталог, который `compilemessages` собрал без единой ошибки, а страница вывела &quot;1 файл&quot; и &quot;3 файла&quot;, но при количестве пять — &quot;5 files&quot; на английском, потому что слот, который правило выбирает для пяти, так и остался незаполненным. Пустой каталог ломается так же незаметно: когда в `pt_BR` ничего не было, страница `/pt-br/` целиком отображалась на английском. С каждой новой размеченной строкой этот цикл повторяется для каждого языка.

Кроме того, Django работает только со строками в коде. Для контента, хранящегося в базе данных, например названий товаров или страниц, нужен сторонний пакет: django-modeltranslation [добавляет поле для каждого языка](https://django-modeltranslation.readthedocs.io/en/latest/registration.html) в зарегистрированные модели, а django-parler хранит переводы в отдельной таблице. Оба пакета дают место для хранения переводов, но сами переводы не создаёт ни один из них.

## Перевод PO-файлов Django с помощью General Translation

CLI General Translation считывает английский каталог, который Django уже ведёт, переводит каждую запись и создаёт PO-файл для каждого языка перевода там, где Django будет его искать. Поддерживайте английский каталог в актуальном состоянии с помощью `makemessages`:

```bash
python manage.py makemessages -l en
```

Затем укажите путь к нему в `gt.config.json`. Эта конфигурация проверена на `gt` версии 2.26.5:

```json title="gt.config.json"
{
  "defaultLocale": "en",
  "locales": ["es", "pl", "pt_BR"],
  "customMapping": {
    "pt_BR": { "code": "pt-BR" }
  },
  "files": {
    "pot": {
      "include": ["locale/[locale]/LC_MESSAGES/*.po"],
      "transformationFormat": "PO"
    }
  }
}
```

Здесь важны несколько деталей; все они описаны в [справочнике по форматам PO / POT](/docs/cli/reference/formats/po-pot-files):

* **`pot` — это ключ и для PO-, и для POT-файлов.** Параметр `transformationFormat` должен иметь значение `PO`; без него на выходе останется непереведённый шаблон.
* **Каталоги локалей называются так, как принято в Django.** CLI подставляет вместо `[locale]` каждую локаль ровно в том виде, в каком вы её указали. [`customMapping`](/docs/cli/reference/config#custom-mapping) сопоставляет каталог Django `pt_BR` со стандартным кодом локали `pt-BR`.
* **`*.po` охватывает все домены**, включая `djangojs.po`, если вы также запускаете `makemessages -d djangojs -l en`.

Настроив CLI (см. [Быстрый старт CLI](/docs/cli/quickstart)), выполните [`npx gt translate`](/docs/cli/reference/commands/translate), а затем `python manage.py compilemessages`. General Translation передаёт каждую запись вместе со всем, что известно о ней из PO-файла, в качестве контекста: `msgctxt`, комментарии `# Translators:`, ссылки на исходный код и флаги вроде `python-format`. Для записи с формами множественного числа он прописывает заголовок `Plural-Forms` языка перевода, заполняет все слоты `msgstr[n]`, которых требует этот заголовок, и проверяет, что заполнители вроде `%(counter)s` сохранились без изменений. Для русского языка это стандартное правило gettext с тремя формами; Django читает правило каждого каталога отдельно, поэтому оно не конфликтует с правилом из четырёх форм в собственном русском каталоге Django.

Для неизменённых записей повторно используются прежние переводы, поэтому при следующем запуске переводятся только изменения; `--force` переводит всё заново. Если в ваших PO-файлах уже есть переводы, выполните [`npx gt upload`](/docs/cli/reference/commands/upload), прежде чем генерировать новые. Чтобы не потерять последующие локальные изменения, синхронизируйте их с помощью [`npx gt save-local`](/docs/cli/reference/commands/save-local) перед следующим запуском перевода.

Здесь и проявляются преимущества полного стека. Glossary и пользовательские промпты в [контекстной группе](/docs/platform/dashboard/guides/defining-context-for-translations) обеспечивают единую терминологию и тон во всех каталогах Django и других проектах, назначенных этой группе. Рецензенты могут [редактировать каждую запись PO](/docs/platform/dashboard/guides/reviewing-translations), включая её формы множественного числа, в панели управления. Запускайте `makemessages`, [`gt translate`](/docs/cli/reference/commands/translate) и `compilemessages` в CI, чтобы переводы обновлялись с каждым релизом.

Для содержимого базы данных и другого текста, который появляется только во время выполнения, API General Translation переводит строки по запросу ([`POST /v2/translate`](/docs/platform/openapi/reference/translation/translate-content)); результаты вы сохраняете самостоятельно, например в языковые поля django-modeltranslation.

Установите Node.js на машину, где запускается CLI. Django по-прежнему отдаёт скомпилированные каталоги через существующую среду выполнения Python.

## Фреймворк переводов Django и General Translation: краткое сравнение

| Возможность                                    | Фреймворк переводов Django                                                                                          | General Translation                                                              |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Разметка строк в коде и шаблонах               | Да: `gettext`, `{% translate %}` и другие                                                                           | Использует уже имеющиеся в коде вызовы Django для сообщений                      |
| Извлечение строк в PO-файлы                    | Да, `makemessages`                                                                                                  | Читает файлы, которые создаёт `makemessages`                                     |
| Создание переводов                             | Нет                                                                                                                 | Да, с помощью [`npx gt translate`](/docs/cli/reference/commands/translate)       |
| Формы множественного числа                     | Заголовок из каталога Django; каждую форму заполняете вы                                                            | Записывает заголовок для языка перевода и заполняет все формы                    |
| Контекст для перевода                          | Комментарии `# Translators:` и `msgctxt` в PO-файле                                                                 | То же самое, а также Glossary и пользовательские промпты                         |
| Выбор языка для каждого запроса и префиксы URL | Да, `LocaleMiddleware` и `i18n_patterns`                                                                            | Сохраняет маршрутизацию и выбор языка средствами Django                          |
| Содержимое базы данных                         | Сторонние пакеты, например django-modeltranslation                                                                  | Перевод через API во время выполнения; хранение результатов — на вашей стороне   |
| Стоимость                                      | Бесплатно, открытый исходный код ([BSD](https://docs.djangoproject.com/en/5.2/faq/general/#how-is-django-licensed)) | [Оплата перевода по факту использования](https://generaltranslation.com/pricing) |

## Когда что использовать

Используйте только встроенные средства Django, если PO-файлы уже заполняют ваши переводчики или система управления переводами, если вы выпускаете продукт на одном-двух языках и можете переводить вручную или если каждый перевод должен быть написан человеком. Подключите General Translation, если хотите, чтобы при каждом изменении все PO-файлы заполнялись для всех языков — с полным набором форм множественного числа и единообразной терминологией — без отдельного этапа перевода между слиянием и релизом.

Выбирать что-то одно не обязательно: Django отвечает за разметку, извлечение, компиляцию и выбор языка, а General Translation — за перевод. Мигрировать ничего не нужно: ваши шаблоны, промежуточное ПО и шаблоны URL остаются прежними.

## Ключевые выводы

* Фреймворк переводов Django выполняет рендеринг переводов, но не создаёт их. Если в каталоге не хватает формы множественного числа или он пуст, выводится английский текст, причём сборка проходит без ошибок.
* General Translation переводит английский каталог, созданный командой `makemessages`, в отдельный PO-файл для каждого языка. Ваши шаблоны, промежуточное ПО и шаблоны URL остаются на месте.
* Для каждой записи с множественным числом General Translation прописывает заголовок `Plural-Forms` для языка перевода и заполняет все позиции `msgstr[n]`, а `msgctxt` и комментарии для переводчиков передаёт в качестве контекста.

## Related questions

- [General Translation и GNU gettext: нужны ли оба?](https://generaltranslation.com/ru/kb/general-translation-vs-gettext.mdx): Оставьте GNU gettext для извлечения и рендеринга, а General Translation подключите для генерации и сопровождения PO-файлов. General Translation учитывает при генерации заметки для переводчиков и контекст сообщений, применяет общую терминологию и предоставляет рецензентам редактор в панели управления. Существующие вызовы gettext и скомпилированные каталоги остаются на месте.
- [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 и Rails I18n: нужны ли оба?](https://generaltranslation.com/ru/kb/general-translation-vs-rails-i18n.mdx): Rails I18n находит сообщения и форматирует даты и числа. General Translation создаёт переводы, поддерживает их в актуальном состоянии по мере изменения английского текста и предоставляет вашей команде панель управления для проверки. Используйте оба инструмента, чтобы выпускать переведённые каталоги Rails с каждым релизом.
- [Почему стоит выбрать General Translation вместо TMS (Smartling, Lokalise, Phrase, Crowdin или Transifex)?](https://generaltranslation.com/ru/kb/general-translation-vs-tms.mdx): Система управления переводами (TMS), например Smartling, Lokalise, Phrase, Crowdin или Transifex, координирует работу переводчиков, но инженерам всё равно приходится извлекать строки, отправлять их на перевод, ждать результатов и встраивать переводы обратно в продукт. General Translation переводит контент прямо в вашем коде с учётом контекста, выпускает все языки с каждым релизом и работает на библиотеках с открытым исходным кодом без привязки к поставщику.
- [General Translation против i18next, react-intl и next-intl: какую библиотеку интернационализации выбрать?](https://generaltranslation.com/ru/kb/general-translation-vs-i18n-libraries.mdx): Библиотеки с открытым исходным кодом, такие как i18next, react-intl и next-intl, ничего не переводят. Они лишь отображают переводы, которые вы сами помещаете в файл каталога для каждого языка, — их пишете вы, ваши переводчики или сторонний сервис. Библиотеки General Translation тоже имеют открытый исходный код и делают то же самое, но General Translation ещё и выполняет перевод, используя ваш код как контекст.

## Previous and next questions

- Previous question: [General Translation и Rails I18n: нужны ли оба?](https://generaltranslation.com/ru/kb/general-translation-vs-rails-i18n.mdx)
- Next question: [General Translation или Babel и Flask-Babel: что выбрать?](https://generaltranslation.com/ru/kb/general-translation-vs-flask-babel.mdx)

## Sitemap

See the [Knowledge Base sitemap](https://generaltranslation.com/ru/kb/sitemap.md) for every article.