Инструкции по настройке

Установка Weblate

В зависимости от ваших настроек и опыта выберите подходящий для вас способ установки:

Требования к программному обеспечению

Операционная система

Weblate работает на Linux, FreeBSD и macOS. Скорее всего будет работать и на других Unix-подобных системах.

Работа Weblate под Windows не поддерживается. Тем не менее, работать под ней он всё ещё может и патчи под неё с радостью принимаются.

Другие сервисы

Для своей работы Weblate использует другие сервисы. Вам понадобятся, по крайней мере, следующие запущенные сервисы:

Зависимости Python

Weblate написан на Python’е и поддерживает Python 3.6 или более новую версию. Вы можете установить зависимости с помощью команды pip или из пакетов вашего дистрибутива, полный список зависимостей находится в файле requirements.txt.

Основные зависимости:

Django

https://www.djangoproject.com/

Celery

https://docs.celeryq.dev/

Translate Toolkit

https://toolkit.translatehouse.org/

translation-finder

https://github.com/WeblateOrg/translation-finder

Python Social Auth

https://python-social-auth.readthedocs.io/

Фреймворк Django REST

https://www.django-rest-framework.org/

Необязательные зависимости

Для работы некоторых функций Weblate необходимы следующие модули. Полный их список можно найти в файле requirements-optional.txt.

Mercurial (необязательная зависимость для поддержки репозиториев Mercurial)

https://www.mercurial-scm.org/

phply (необязательная зависимость для Строки PHP)

https://github.com/viraptor/phply

tesserocr (необязательная зависимость для поддержки оптического распознавания символов на Визуальный контекст для строк)

https://github.com/sirfz/tesserocr

python-akismet (необязательная зависимость для Защита от спама)

https://github.com/Nekmo/python-akismet

ruamel.yaml (необязательная зависимость для поддержки файлов YAML)

https://pypi.org/project/ruamel.yaml/

Zeep (необязательная зависимость для Microsoft Terminology (Терминология Майкрософт))

https://docs.python-zeep.org/

aeidon (необязательная зависимость для поддержки файлов субтитров)

https://pypi.org/project/aeidon/

fluent.syntax (необязательная зависимость для Формат Fluent)

https://projectfluent.org/

Подсказка

При установке с помощью pip вы можете напрямую указать желаемые функции при установке:

pip install "Weblate[PHP,Fluent]"

Или вы можете установить Weblate со всеми дополнительными функциями:

pip install "Weblate[all]"

Или вы можете установить Weblate без каких-либо дополнительных функций:

pip install Weblate

Зависимости серверной части базы данных

Weblate поддерживает PostgreSQL, MySQL и MariaDB, подробнее смотрите в разделе Настройка базы данных для Weblate и документации по реализации поддержки соответствующей базы данных.

Другие системные требования

В системе должны быть установлены следующие зависимости:

Git

https://git-scm.com/

Pango, Cairo и связанные заголовочные файлы, а также данные интроспекции GObject

https://cairographics.org/, https://pango.gnome.org/, смотрите раздел Pango и Cairo

git-review (необязательная зависимость для поддержки Gerrit)

https://pypi.org/project/git-review/

git-svn (необязательная зависимость для поддержки Subversion)

https://git-scm.com/docs/git-svn

tesseract и его данные (необязательная зависимость для поддержки распознавания текста со снимков экрана)

https://github.com/tesseract-ocr/tesseract

licensee (необязательная зависимость для определения лицензии при создании компонента)

https://github.com/licensee/licensee

Зависимости времени компиляции

Для сборки некоторых зависимостей Python может потребоваться установка также и их зависимостей. Это зависит от того, как именно вы их устанавливаете, так что за справкой по установке обратитесь к документации соответствующих пакетов. Вручную устанавливать зависимости зависимостей вам не понадобятся, если вы, например, устанавливаете их через pip и используете предварительно-собранные «колёса» (Wheels) или устанавливаете их через пакетный менеджер вашего дистрибутива.

Pango и Cairo

Изменено в версии 3.7.

Weblate использует Pango и Cairo для отрисовки растровых виджетов (смотрите раздел Продвижение перевода) и проверки отрисовки текста (смотрите раздел Управление шрифтами). Для правильной установки привязок Python сначала нужно установить системные библиотеки — вам нужны и Cairo, и Pango, которым, в свою очередь, нужна GLib. Все они должны быть установлены с файлами для разработки и данными интроспекции GObject.

Проверка подписей выпусков

Выпуски Weblate подписываются криптографической подписью выпускающего разработчика. В настоящее время им является Михал Чигарж. Отпечаток его PGP-ключа:

63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D

а дополнительную идентификационную информацию вы можете получить по адресу <https://keybase.io/nijel>.

Вы должны удостовериться, что подпись соответствует скачанному вами архиву. Таким образом, вы сможете быть уверены, что используете тот же код, который был выпущен. Также вы должны проверить дату подписания, чтобы удостовериться, что вы скачали последнюю версию.

Каждый архив сопровождается файлами .asc, содержащими его PGP-подпись. После того, как вы разместите оба файла в одном каталоге, вы сможете проверить подпись:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Can't check signature: public key not found

Как видите, GPG жалуется на то, что он не знает открытого ключа. На данный момент вы должны сделать одно из следующего:

  • Использовать wkd для скачивания ключа:

$ gpg --auto-key-locate wkd --locate-keys michal@cihar.com
pub   rsa4096 2009-06-17 [SC]
      63CB1DF1EF12CF2AC0EE5A329C27B31342B7511D
uid           [ultimate] Michal Čihař <michal@cihar.com>
uid           [ultimate] Michal Čihař <nijel@debian.org>
uid           [ultimate] [jpeg image of size 8848]
uid           [ultimate] Michal Čihař (Braiins) <michal.cihar@braiins.cz>
sub   rsa4096 2009-06-17 [E]
sub   rsa4096 2015-09-09 [S]
$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm
  • Скачать и импортировать ключ с одного из серверов ключей:

$ gpg --keyserver hkp://pgp.mit.edu --recv-keys 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: key 9C27B31342B7511D: "Michal Čihař <michal@cihar.com>" imported
gpg: Total number processed: 1
gpg:              unchanged: 1

Это немного улучшит ситуацию — на данный момент вы можете проверить правильность подписи с данного ключа, но всё равно не можете доверять используемому в ключе имени:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 63CB 1DF1 EF12 CF2A C0EE  5A32 9C27 B313 42B7 511D

Проблема в том, что выдать ключ с таким именем может кто угодно. Вам нужно убедиться, что ключ действительно принадлежит указанному лицу. Руководство GNU по обеспечению конфиденциальности раскрывает эту тему в главе Проверка достоверности ключей. Самый надёжный метод — лично встретиться с разработчиком и обменяться отпечатками ключей, однако вы также можете положиться на сеть доверия. Таким образом, вы можете транзитивно доверять ключу через подписи других людей, которые встречались с разработчиком лично.

Когда достоверность ключа будет установлена, предупреждение больше появляться не будет:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]

В случае недействительной подписи (архив был изменен), вы получите явную ошибку, независимо от того, доверяете ли вы ключу или нет:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: BAD signature from "Michal Čihař <michal@cihar.com>" [ultimate]

Права доступа к файлам

Процесс Weblate должен мочь читать и писать в каталог, в котором он хранит свои данные — DATA_DIR. Все файлы в этом каталоге должны принадлежать и иметь разрешение на запись для пользователей, от имени которых работают все процессы Weblate (в частности WSGI и Celery, смотреть раздел Запуск сервера и Фоновые задачи с использованием Celery).

В конфигурации по умолчанию они расположены в том же дереве, что и исходный код Weblate, однако вы можете предпочесть переместить их в более подходящее место, например, в /var/lib/weblate.

Weblate попытается автоматически создать эти каталоги, но у него ничего не получится, если у него не будет соответствующих прав доступа.

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

В контейнере Docker все файлы в томе /app/data должны принадлежать пользователю weblate внутри самого контейнера (UID 1000).

Настройка базы данных для Weblate

Рекомендуется запускать Weblate с сервером баз данных PostgreSQL.

PostgreSQL

PostgreSQL, как правило, является лучшим выбором для сайтов, написанных на Django. Это эталонная база данных, используемая для реализации слоя баз данных Django.

Примечание

Weblate использует расширение для триграмм, которое в некоторых случаях должно быть установлено отдельно. Ищите пакет postgresql-contrib или аналогичный.

См.также

PostgreSQL notes

Создание базы данных в PostgreSQL

Обычно рекомендуется запускать Weblate в отдельной базе данных и под отдельной учётной записью:

# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"

# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate

# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate

Подсказка

Если вы не хотите делать пользователя Weblate суперпользователем в PostgreSQL, вы можете пропустить этот шаг. В этом случае вам придётся выполнить некоторые шаги по миграции вручную, так как суперпользователь PostgreSQL запускает в схеме Weblate следующую команду:

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;

Настройка Weblate для использования PostgreSQL

Фрагмент настроек settings.py для PostgreSQL:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Name of role to alter to set parameters in PostgreSQL,
        # use in case role name is different than user used for authentication.
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
    }
}

При миграции базы данных выполняется ALTER ROLE той роли, которую используется Weblate. В большинстве случаев имя роли совпадает с именем пользователя. В более же сложных случаях они могут отличаться и при миграции вы можете получить ошибку о том, что такая роль не существует (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Известно, что такое случается при использовании базы данных Azure совместно с PostgreSQL, хотя это может происходить и при других обстоятельствах. Установите параметр ALTER_ROLE, чтобы задать ту роль, которую Weblate должен изменить во время миграции базы данных.

MySQL и MariaDB

Подсказка

Некоторые функции Weblate лучше работают с PostgreSQL. Среди них: поиск и память переводов, обе из которых используют функции полнотекстового поиска базы данных, а их реализация в PostgreSQL превосходит все остальные.

Weblate также можно использовать с MySQL или MariaDB, ознакомитесь с предостережениями по их использованию вместе с Django в разделах Замечания по MySQL и Замечания по MariaDB его документации. Из-за ограничений рекомендуется использовать :ref:`postgresql`при новой установке.

Weblate требует MySQL версии 5.7.8 или новее или MariaDB 10.2.7 или новее.

Для Weblate рекомендуется следующая конфигурация:

  • Используйте кодовую таблицу utf8mb4 для представления символов с более высоких плоскостей Юникода (например, эмодзи).

  • Настройте сервер на использование innodb_large_prefix для разрешения более длинных индексов для текстовых полей.

  • Установите уровень изоляции в READ COMMITTED.

  • Режим SQL должен быть установлен в STRICT_TRANS_TABLES.

MySQL 8.x, MariaDB 10.5.x или новее имеют разумную конфигурацию по умолчанию, поэтому не требуется настройка сервера, а всё необходимое можно настроить на стороне клиента.

Ниже приведён пример типового файла настроек /etc/my.cnf.d/server.cnf для сервера с 8ГБ ОЗУ. Таких настроек должно хватить для большинства установок. У MySQL и MariaDB есть и другие параметры, которые могут повысить производительность сервера, но обычно прибегать к ним нет смысла, если только вы не планируете, что достаточно большое количество пользователей будут работать с вашему сервером одновременно. В таком случае смотрите подробности по конфигурации сервера для таких задач в документации своей СУБД.

Дабы при установке Weblate не возникло проблем, абсолютно критично, чтобы параметр innodb_file_per_table был включён; а также после его изменения нужно не забыть перезапустить MySQL/MariaDB.

[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci

datadir=/var/lib/mysql

log-error=/var/log/mariadb/mariadb.log

innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES

Подсказка

Если вы получаете ошибку #1071 - Specified key was too long; max key length is 767 bytes (указанный ключ слишком длинный; максимальная длина ключа - 767 байт), то убедитесь, что в конфигурации вашего сервера включены параметры innodb, описанные выше.

Подсказка

В случае, если вы получаете ошибку #2006 - MySQL server has gone away (сервер MySQL более недоступен), то может помочь настройка параметра CONN_MAX_AGE.

Настройка Weblate для работы совместно с MySQL/MariaDB

Фрагмент файла настроек settings.py для MySQL и MariaDB:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.mysql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "127.0.0.1",
        # Set to empty string for default
        "PORT": "3306",
        # In case you wish to use additional
        # connection options
        "OPTIONS": {},
    }
}

Также прежде чем начать установку вам нужно будет создать пользователя базы данных с именем weblate. Это можно сделать с помощью следующей команды:

GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Другие настройки

Настройка исходящей почты

Weblate отправляет электронные письма по разным поводам — для активации учетной записи и по различным уведомлениям, настроенным пользователями. Для этого ему необходим доступ к SMTP-серверу.

Настройка почтового сервера производится с помощью следующих параметров: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER и EMAIL_PORT. Их имена говорят сами за себя, а более подробную информацию вы можете найти в документации Django.

Подсказка

Если вы получаете ошибку о том , что аутентификация не поддерживается (например, SMTP AUTH extension not supported by server, «расширение SMTP AUTH не поддерживается сервером»), то скорей всего это вызвано тем, что используется небезопасное соединение и из-за этого сервер отказывается производить аутентификацию. В таком случае попробуйте включить EMAIL_USE_TLS.

Работа за обратным прокси

Некоторые функции Weblate полагаются на возможность получения IP-адреса клиента. Среди этих функций Ограничение частоты запросов, Защита от спама или Журнал аудита.

В стандартной конфигурации Weblate достает IP-адрес из переменной REMOTE_ADDR, которая устанавливается обработчиком WSGI.

Если же вы используете обратный прокси, то это поле, скорее всего, будет содержать его адрес. Вам нужно настроить Weblate на доверие дополнительным HTTP-заголовкам и доставать IP-адрес из них. Эту настройку нельзя включить по умолчанию, поскольку она разрешит подмену IP-адреса для установок, не использующих обратный прокси. Для самых обычных установок будет достаточно включения параметра IP_BEHIND_REVERSE_PROXY, но вам также может понадобиться подправить параметры IP_PROXY_HEADER и IP_PROXY_OFFSET.

Ещё один момент, на который следует обратить внимание, это заголовок Host. Он должен соответствовать тому, что настроено в SITE_DOMAIN. Дополнительная настройка может потребоваться в вашем обратном прокси (например, используйте ProxyPreserveHost On для Apache или proxy_set_header Host $host; для nginx).

HTTP-прокси

Weblate запускает команды системы контроля версий, а те берут настройки прокси из переменных окружения. Для их настройки рекомендуемый подход — определить необходимые параметры прокси в файле settings.py:

import os

os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"

Изменение конфигурации под свои нужды

Скопируйте weblate/settings_example.py в weblate/settings.py и подправьте его в соответствии со своими настройками. Скорее всего, вы захотите настроить следующие параметры:

ADMINS

Список администраторов сайтов для получения уведомлений, когда что-то идет не так, например, для получения уведомлений о неудачных слияниях, или об ошибках Django.

ALLOWED_HOSTS

Вы должны установить эту настройку в список хостов, которые должен обслуживать ваш сайт. Например:

ALLOWED_HOSTS = ["demo.weblate.org"]

Или же вы можете указать символ шаблона:

ALLOWED_HOSTS = ["*"]

SESSION_ENGINE

Настраивает то, как будут храниться ваши сессии. В случае, если вы оставили механизм хранения по умолчанию — в базе данных — вы должны настроить расписание для команды weblate clearsessions, удаляющей из базы данных данные об устаревших сессиях.

Если вы используете в качестве кэша Redis (смотрите раздел Включение кэширования), рекомендуется использовать его также и для сессий:

SESSION_ENGINE = "django.contrib.sessions.backends.cache"

DATABASES

Подключение к серверу базы данных, подробнее об этой настройке читайте в документации Django.

DEBUG

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

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

DEFAULT_FROM_EMAIL

Адрес электронной почты отправителя для исходящих сообщений электронной почты, например, для писем регистрации.

См.также

DEFAULT_FROM_EMAIL

SECRET_KEY

Ключ, используемый Django для подписывания некоторой информации, сохраняемой в куках, подробнее смотрите в разделе Секретный ключ Django.

См.также

SECRET_KEY

SERVER_EMAIL

Адрес электронной почты, используемый в качестве адреса отправителя для отправки сообщений администратору, например, уведомлений о неудачных слияниях.

См.также

SERVER_EMAIL

Наполнение базы данных

После того, как ваша конфигурация будет готова, вы можете запустить weblate migrate для создания структуры базы данных. Теперь вы можете создавать проекты перевода через интерфейс администратора.

В случае, если вы хотите запустить установку не в интерактивном режиме, вы можете использовать weblate migrate --noinput, а затем создать пользователя-администратора при помощи команды createadmin.

После того, как вы закончите, вам также стоит проверить Отчёт о производительности в интерфейсе администратора. Информация оттуда может дать вам подсказки по исправлению потенциально не оптимальной конфигурации вашего сайта.

Рабочая среда

Для установки в рабочую среду необходимо провести корректировки, описанные в следующих разделах. Наиболее критичные настройки вызовут предупреждение, которое обозначается восклицательным знаком в верхней панели, если вы вошли в систему под суперпользователем:

../_images/admin-wrench.png

Также рекомендуется изучить все проверки, произведённые Django (хотя, возможно, исправлять их все нет необходимости):

weblate check --deploy

Вы можете просмотреть этот же список из интерфейса управления.

Отключение отладочного режима

Отключите отладочный режим Django (DEBUG), установив:

DEBUG = False

При включенном отладочном режиме Django сохраняет все выполненные запросы и при возникновении ошибок показывает пользователям обратную трассировку стека, что в рабочей среде не желательно.

Правильная настройка администраторов

Укажите в настройке ADMINS правильные адреса администраторов, чтобы определить, кто будет получать электронную почту в случае, если на сервере что-то пойдёт не так, например:

ADMINS = (("Your Name", "your_email@example.com"),)

Установка правильного домена сайта

Поправьте имя сайта и домен в интерфейсе администратора, иначе ссылки в RSS или регистрационные письма не будут работать. Эта настройка осуществляется с помощью параметра SITE_DOMAIN, который должен содержать доменное имя сайта.

Изменено в версии 4.2: До выхода версии 4.2 вместо него использовался фреймворк «сайтов» Django, смотрите раздел Фреймворк «сайтов».

Правильная настройка HTTPS

Настоятельно рекомендуется запускать Weblate с использованием шифрующего протокола HTTPS. После его включения в настройках необходимо установить параметр ENABLE_HTTPS:

ENABLE_HTTPS = True

Подсказка

Возможно, вы также захотите настроить HSTS, для получения более подробной информации смотрите документ SSL/HTTPS.

Установка правильного значения SECURE_HSTS_SECONDS

Если ваш сайт обслуживается по SSL, вам необходимо рассмотреть возможность установки значения параметра SECURE_HSTS_SECONDS в файле settings.py, включающего HTTP Strict Transport Security. По умолчанию его значение установлено в 0, как показано ниже.

SECURE_HSTS_SECONDS = 0

Если для него установлено ненулевое целое значение, то django.middleware.security.SecurityMiddleware устанавливает заголовок HTTP Strict Transport Security у всех ответов, которые его ещё не имеют.

Предупреждение

Неправильная настройка этого параметра может привести к необратимому (на некоторое время) выходу из строя вашего сайта. Поэтому сперва ознакомьтесь с документацией по HTTP Strict Transport Security.

Использование мощного движка базы данных

  • Пожалуйста, используйте для рабочего окружения PostgreSQL, для получения более подробной информации смотрите раздел Настройка базы данных для Weblate.

  • Используйте соседнее место для размещения сервера базы данных, иначе производительность или надёжность сети может испортить работу с Weblate.

  • Проверьте производительность сервера базы данных или настройте его конфигурацию, например, используя PGTune.

Включение кэширования

Если возможно, используйте Redis из Django, настроив переменную CACHES в файле настроек, например:

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/0",
        # If redis is running on same host as Weblate, you might
        # want to use unix sockets instead:
        # 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    }
}

Подсказка

Если вы измените настройки кеширования Redis, то вам также понадобится изменить их и в Celery, смотреть раздел Фоновые задачи с использованием Celery.

Кеширование аватаров

Помимо кэширования силами Django, Weblate выполняет кэширование аватаров. Для этой цели рекомендуется воспользоваться отдельным файловым кэшем:

CACHES = {
    "default": {
        # Default caching backend setup, see above
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "unix:///var/run/redis/redis.sock?db=0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    },
    "avatar": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
        "TIMEOUT": 604800,
        "OPTIONS": {
            "MAX_ENTRIES": 1000,
        },
    },
}

Настройка отправки электронной почты

Weblate’у по разным случаям необходимо отправлять электронные письма и эти письма должны иметь правильный адрес отправителя, поэтому настройте параметры SERVER_EMAIL и DEFAULT_FROM_EMAIL так, чтобы они соответствовали вашему окружению, например:

SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"

Примечание

Для отключения отправки писем Weblate’ом установите переменную EMAIL_BACKEND в значение django.core.mail.backends.dummy.EmailBackend.

При этом доставка сообщений электронной почты будет отключена целиком, включая сообщения для регистрации или сброса пароля.

Настройка разрешенных хостов

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

В случае, если он не настроен на соответствие вашему HTTP-серверу, вы будете получать ошибки вида Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS. (Неверный заголовок HTTP_HOST: '1.1.1.1'. Возможно, вам нужно добавить '1.1.1.1' в ALLOWED_HOSTS.)

Подсказка

Внутри контейнера Docker он доступен через переменную окружения WEBLATE_ALLOWED_HOSTS.

Секретный ключ Django

Параметр SECRET_KEY используется Django для подписания файлов кук и вы обязательно должны сгенерировать свое собственное значение, а не использовать приведенное в примере настройки.

Сгенерировать новый ключ вы можете с помощью скрипта weblate/examples/generate-secret-key, поставляемого вместе с Weblate.

См.также

SECRET_KEY

Выполнение задач технического обслуживания

Для оптимальной производительности неплохо бы в фоновом режиме выполнять некоторые задачи по техническому обслуживанию. Теперь это делается автоматически с помощью фоновых задач Celery, которые включают в себя:

  • Проверку работоспособности состояния конфигурации (ежечасно).

  • Фиксацию отложенных изменений (ежечасно), смотрите раздел Отложенные коммиты и команду commit_pending.

  • Обновление предупреждений компонента (ежедневно).

  • Обновление удалённых веток (по ночам), смотрите параметр AUTO_UPDATE.

  • Резервное копирование памяти переводов в JSON (ежедневно), смотрите команду dump_memory.

  • Задачи по обслуживанию полнотекстового индекса и базы данных (ежедневные и еженедельные задачи), смотрите команду cleanuptrans.

Изменено в версии 3.2: Начиная с версии 3.2, по умолчанию эти задачи выполняются через Celery и Weblate уже поставляется с соответствующей конфигурацией, смотрите раздел Фоновые задачи с использованием Celery.

Системные локали и кодировки

Системные локали должны быть настроены на поддерживающие UTF-8. В большинстве дистрибутивов Linux это умолчательная их настройка. В случае, если в вашей системе это не так, измените пожалуйста локали на вариант с поддержкой UTF-8.

Например, путём редактирования файла /etc/default/locale и прописывания в нём команды LANG="C.UTF-8".

В некоторых случаях отдельные сервисы имеют отдельные настройки для локалей. Это зависит от дистрибутива и веб-сервера, поэтому проверьте документацию к пакетам вашего веб-сервера.

Apache на Ubuntu использует /etc/apache2/envvars:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Apache на CentOS использует /etc/sysconfig/httpd (или /opt/rh/httpd24/root/etc/sysconfig/httpd):

LANG='en_US.UTF-8'

Использование пользовательского центра сертификации

Во время HTTP-запросов Weblate проверяет SSL-сертификаты. Если вы используете пользовательский центр сертификации, который цепочке сертификатов по умолчанию не является доверенным, вам придется добавить его сертификат в качестве доверенного.

Предпочтительный подход — сделать это на системном уровне, подробнее смотрите документацию по дистрибутиву (например, в debian это можно сделать, разместив сертификат центра сертификации в каталоге /usr/local/share/ca-certificates/ и запустив команду update-ca-certificates).

Как только это будет сделано, системные инструменты станут доверять сертификату, среди этих инструментов будет и Git.

Для кода Python вам будет необходимо настроить запросы на использование системной цепочки сертификатов вместо использования цепочки, поставляемой с Python’ом. Этого можно добиться, поместив в settings.py следующий фрагмент кода (путь указан для Debian):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

Сжатие клиентских ресурсов

Weblate поставляется с кучей файлов JavaScript и CSS. Из соображений производительности хорошей практикой будет сжимать их перед отправкой клиенту. В конфигурации по умолчанию это делается на лету ценой небольших накладных расходов. В больших же установках рекомендуется включить режим предварительного сжатия. Это можно сделать в настройках, а повторное сжатие файлов должно запускаться при каждом обновлении Weblate.

Такое переключение режима выполняется простым включением параметра django.conf.settings.COMPRESS_OFFLINE и заданием соответствующих настроек в параметре django.conf.settings.COMPRESS_OFFLINE_CONTEXT (последний уже включён в пример файла настроек):

COMPRESS_OFFLINE = True

При каждом развёртывании вам необходимо сжимать файлы, чтобы они соответствовали текущей версии:

weblate compress

Подсказка

В официальном образе Docker эта функция уже включена.

Запуск сервера

Подсказка

Если у вас нет опыта работы с услугами, описанными ниже, вы можете попробовать Установка с помощью Docker’а.

Чтобы запустить Weblate, вам понадобится несколько сервисов, рекомендуемая конфигурация состоит из:

Примечание

Между некоторыми сервисами существуют зависимости, например, кэш и база данных должны быть запущены до запуска процессов Celery или uwsgi.

В большинстве случаев вы будете запускать все сервисы на одном (виртуальном) сервере, но в случае, если ваша установка испытывает тяжелые нагрузки, вы можете их разделить. Единственным ограничением является то, что серверы Celery и Wsgi должны иметь доступ к каталогу DATA_DIR.

Примечание

Процесс WSGI должен выполняться под тем же пользователем, под которым работает Celery, иначе файлы в каталоге DATA_DIR будут сохраняться с разными владельцами, что приведёт к проблемам во время выполнения.

Смотреть также раздел Права доступа к файлам и Фоновые задачи с использованием Celery.

Запуск веб-сервера

Запуск Weblate ничем не отличается от запуска любой другой программы на базе Django. Как правило, Django выполняется как uWSGI или fcgi (смотрите ниже примеры для различных веб-серверов).

В целях тестирования можно использовать встроенный в Django веб-сервер:

weblate runserver

Предупреждение

НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР В РАБОЧЕЙ СРЕДЕ. Он не проходил аудиты безопасности или тесты производительности. Также смотрите документацию Django по команде runserver.

Подсказка

Встроенный сервер Django обслуживает статические файлы только с включённым параметром DEBUG, поскольку он предназначен только для разработки. Для использования в рабочей среде смотрите установки wsgi в разделах Примеры файлов настроек NGINX и uWSGI, Пример файла настроек Apache, Пример файла настроек Apache и Gunicorn и Обслуживание статических файлов.

Обслуживание статических файлов

Изменено в версии 2.4: До версии 2.4 Weblate некорректно использовал фреймворк статических файлов Django, поэтому его настройка была более сложной.

Django необходимо собрать свои статические файлы в одном каталоге. Для этого необходимо выполнить команду weblate collectstatic --noinput. Она скопирует статические файлы в каталог, указанный в параметре STATIC_ROOT (по умолчанию это каталог static внутри каталога DATA_DIR).

Статические файлы рекомендуется раздавать непосредственно с вашего веб-сервера, это следует делать для следующих путей:

/static/

Обслуживает статические файлы для Weblate и административного интерфейса (из каталога, определенного параметром STATIC_ROOT).

/media/

Используется для загрузки пользовательских мультимедийных данных (например, снимков экрана).

/favicon.ico

Должен быть переписан, чтобы переписать правило для раздачи /static/favicon.ico.

Политика безопасности содержимого

В конфигурации Weblate по умолчанию уже включено использование промежуточного ПО weblate.middleware.SecurityMiddleware, которое устанавливает связанные с безопасностью заголовки HTTP, такие как Content-Security-Policy или X-XSS-Protection. По умолчанию они настроены для работы с Weblate и его конфигурацией, но для этого может потребоваться настройка вашего окружения.

Примеры файлов настроек NGINX и uWSGI

Для запуска рабочего веб-сервера используйте обертку wsgi, устанавливаемую вместе с Weblate (в виртуальном окружении она устанавливается в ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Не забудьте также поместить ваше виртуальное окружение в пути поиска Python’а (например, используя установку virtualenv = /home/user/weblate-env в uWSGI).

Со следующими файлами настроек Weblate будет запускаться как uWSGI-приложение под веб-сервером NGINX.

Файл настроек NGINX (этот же пример есть в weblate/examples/weblate.nginx.conf):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # DATA_DIR/static/favicon.ico
        alias /home/weblate/data/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # DATA_DIR/static/
        alias /home/weblate/data/static/;
        expires 30d;
    }

    location /media/ {
        # DATA_DIR/media/
        alias /home/weblate/data/media/;
        expires 30d;
    }

    location / {
        include uwsgi_params;
        # Needed for long running operations in admin interface
        uwsgi_read_timeout 3600;
        # Adjust based to uwsgi configuration:
        uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
        # uwsgi_pass 127.0.0.1:8080;
    }
}

Файл настроек uWSGI (этот же пример есть в weblate/examples/weblate.uwsgi.ini):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py

# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path   = /path/to/weblate

# In case you're using virtualenv uncomment this:
virtualenv = /home/weblate/weblate-env

# Needed for OAuth/OpenID
buffer-size   = 8192

# Reload when consuming too much of memory
reload-on-rss = 250

# Increase number of workers for heavily loaded sites
workers       = 8

# Enable threads for Sentry error submission
enable-threads = true

# Child processes do not need file descriptors
close-on-exec = true

# Avoid default 0000 umask
umask = 0022

# Run as weblate user
uid = weblate
gid = weblate

# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true

# Enable uWSGI stats server
# stats = :1717
# stats-http = true

# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

Пример файла настроек Apache

Когда Weblate используется с WSGI, то рекомендуется использовать модуль мультипроцессовой обработки (MPM) prefork.

Со следующим файлом настроек Weblate будет запускаться как WSGI-приложение, вам нужно включить модуль mod_wsgi (этот же пример есть в weblate/examples/apache.conf):

#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Примечание

Weblate требует Python 3, поэтому, пожалуйста, убедитесь, что вы используете вариант modwsgi, собранный с третьим Python’ом. Обычно он доступен в виде отдельного пакета, например libapache2-mod-wsgi-py3.

Пример файла настроек Apache и Gunicorn

Со следующим файлом настроек Weblate будет запускаться в Gunicorn и Apache 2.4 (этот же пример есть в weblate/examples/apache.gunicorn.conf):

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/https_cert.cert
    SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
    SSLProxyEngine On

    ProxyPass /favicon.ico !
    ProxyPass /static/ !
    ProxyPass /media/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

Запуск Weblate по определённому пути в URL

Добавлено в версии 1.3.

Когда Weblate используется с WSGI, то рекомендуется использовать модуль мультипроцессовой обработки (MPM) prefork.

Пример файла настроек Apache для предоставления доступу к Weblate по пути /weblate. Снова используя модуль mod_wsgi (этот же пример есть в weblate/examples/apache-path.conf):

#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /weblate/static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /weblate/media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Кроме того, вам нужно будет подправить weblate/settings.py:

URL_PREFIX = "/weblate"

Фоновые задачи с использованием Celery

Добавлено в версии 3.2.

Weblate использует Celery для выполнения обычных и фоновых задач. Вы должны запустить службу Celery, которая будет их выполнять. Например, он отвечает за выполнение следующих операций (этот список не является полным):

Типовая конфигурация, основанная на Redis, выглядит как-то так:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

Также вы должны запустить рабочего Celery для обработки задач и запуска запланированных задач, это можно сделать непосредственно в командной строке (что в основном полезно при отладке или разработке):

./weblate/examples/celery start
./weblate/examples/celery stop

Примечание

Процесс Celery должен выполняться под тем же пользователем, под которым работает процесс WSGI, иначе файлы в каталоге DATA_DIR будут сохраняться с разными владельцами, что приведёт к проблемам во время выполнения.

Смотреть также раздел Права доступа к файлам и Запуск сервера.

Выполнение задач Celery в wsgi с использованием режима eager mode

Примечание

Это сильно повлияет на производительность веб-интерфейса и приведёт к поломке функций, зависящих от регулярного срабатывания (например, коммитинг ожидающих изменений, уведомления о сводке или резервное копирование).

При разработке Weblate или модулей для него вы можете использовать «нетерпеливую» конфигурацию, тогда все задачи будут выполнятся непосредственно при их вызове:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

Запуск Celery в качестве системного сервиса

Скорее всего вы захотите запустить Celery в качестве демона, и как выполнить ваше желание описывается в разделе Демонизация документации Celery. Для наиболее распространённой установки Linux с использованием systemd вы можете воспользоваться примерами перечисленных ниже файлов, поставляемых в каталоге examples.

Модуль systemd, размещаемый по пути /etc/systemd/system/celery-weblate.service:

[Unit]
Description=Celery Service (Weblate)
After=network.target

[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
  --pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'

[Install]
WantedBy=multi-user.target

Файл настроек переменных окружения должен быть размещён в /etc/default/celery-weblate:

# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"

# Extra command-line arguments to the worker,
# increase concurrency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
    --queues:notify=notify --prefetch-multiplier:notify=10 \
    --queues:memory=memory --prefetch-multiplier:memory=10 \
    --queues:translate=translate --prefetch-multiplier:translate=4 \
    --concurrency:backup=1 --queues:backup=backup  --prefetch-multiplier:backup=2"

# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

Для ротации журналов Celery файл настроек logrotate должен быть размещён в /etc/logrotate.d/celery:

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

Периодические задачи при помощи Celery beat

Weblate поставляется со встроенной конфигурацией планировщика задач. Вы, однако, можете определить в settings.py дополнительные задачи, для примера смотрите раздел Отложенные коммиты.

Предполагается, что задачи будут выполняться демоном Celery beat. В случае, если он не работает должным образом, он может быть не запущен или его база данных была повреждена. В этом случае проверьте журналы запуска Celery, чтобы выяснить первопричину проблемы.

Мониторинг состояния Celery

Текущую длину очередей задач Celery можно узнать в Интерфейс управления или использовать celery_queues в командной строке. В случае если очередь будет слишком длинной, вы также получите ошибку конфигурации в интерфейсе администратора.

Предупреждение

Ошибки Celery по умолчанию записываются только в журнал Celery и пользователю не видны. В случае, если вы хотите видеть сводку по таким ошибкам, рекомендуется настроить сбор отчетов об ошибках.

Мониторинг Weblate

Weblate предоставляет URL-адрес /healthz/, который можно использоваться для простой проверки его работоспособности, например, при использовании Kubernetes. Docker container имеет встроенную проверку работоспособности с помощью этого URL-адреса.

Для мониторинга метрик Weblate’а вы можете использовать конечную точку API GET /api/metrics/.

Сбор отчетов об ошибках

Weblate, как и любое другое программное обеспечение, может дать сбой. Для сбора полезной информации о сбоях мы рекомендуем использовать услуги сторонних сервисов. Особенно они полезны в случае сбоя в задачах Celery, которые в противном случае просто записали бы ошибку в журнал, и вы не получили о ней никакого уведомления. Weblate поддерживает следующие сервисы:

Sentry

В Weblate встроена поддержка Sentry. Для его использования достаточно установить параметр SENTRY_DSN в settings.py:

SENTRY_DSN = "https://id@your.sentry.example.com/"

Rollbar

Weblate имеет встроенную поддержку Rollbar. Для его использования достаточно следовать инструкциям из документа`Уведомления Rollbar для Python’а <https://docs.rollbar.com/docs/python/>`_.

Вкратце, вам необходимо дописать в settings.py:

# Add rollbar as last middleware:
MIDDLEWARE = [
    # … other middleware classes …
    "rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]

# Configure client access
ROLLBAR = {
    "access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
    "client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

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

Перенос Weblate на другой сервер

Перенос Weblate на другой сервер должен быть достаточно простой операцией, однако он хранит данные в нескольких местах, переносить которые следует с некоторой осторожностью. Лучше всего для переноса на время остановить Weblate.

Перенос базы данных

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

Наилучшим подходом будет использование родных инструментов для работы с базами данных, так как они обычно наиболее эффективны (например, mysqldump или pg_dump). Если вы выполнить перенос между разными базами данных, то единственным вариантом может оказаться использование команд управления Django для создания дампа и импорта базы данных:

# Export current data
weblate dumpdata > /tmp/weblate.dump
# Import dump
weblate loaddata /tmp/weblate.dump

Перенос репозиториев системы контроля версий

Также необходимо перенести репозитории системы контроля версий, хранящиеся в каталоге DATA_DIR. Вы можете просто скопировать их, либо воспользоваться командой rsync для более эффективного выполнения переноса.

Прочие заметки

Не забудьте переместить и другие сервисы, которые Weblate мог использовать, например, Redis, задачи Cron или модули пользовательской аутентификации.