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

Установка Weblate

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

Обзор архитектуры

digraph architecture { graph [fontname="sans-serif", fontsize=10, newrank=true, rankdir=LR, splines=ortho ]; node [fontname="sans-serif", fontsize=10, height=0, margin=.15, shape=box ]; edge [fontname="sans-serif", fontsize=10 ]; subgraph cluster_thirdparty { graph [color=lightgrey, label="Third-party services", style=filled ]; mt [label="Machine translation", style=dotted]; sentry [label="Sentry\nError collection", style=dotted]; graylog [label="Graylog\nLog collection", style=dotted]; mail [label="E-mail server"]; auth [label="SSO\nAuthentication provider", style=dotted]; } subgraph cluster_ingress { graph [color=lightgrey, label=Ingress, style=filled ]; web [label="Web server", shape=hexagon]; } subgraph cluster_weblate { graph [color=lightgrey, label="Weblate code-base", style=filled ]; celery [fillcolor="#144d3f", fontcolor=white, label="Celery workers", style=filled]; wsgi [fillcolor="#144d3f", fontcolor=white, label="WSGI server", style=filled]; } subgraph cluster_services { graph [color=lightgrey, label=Services, style=filled ]; redis [label="Datastore\nTask queue\nCache", shape=cylinder]; db [label="PostgreSQL\nDatabase", shape=cylinder]; fs [label=Filesystem, shape=cylinder]; } web -> wsgi; web -> fs; celery -> mt [style=dotted]; celery -> sentry [style=dotted]; celery -> graylog [style=dotted]; celery -> mail; celery -> redis; celery -> db; celery -> fs; wsgi -> mt [style=dotted]; wsgi -> sentry [style=dotted]; wsgi -> graylog [style=dotted]; wsgi -> auth [style=dotted]; wsgi -> redis; wsgi -> db; wsgi -> fs; }

Веб-сервер

Обработка входящих HTTP-запросов, Обслуживание статических файлов.

Обработчики Celery

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

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

Используйте выделенный узел для масштабирования Weblate по горизонтали.

WSGI сервер

Сервер WSGI, обслуживающий веб-страницы для пользователей.

Используйте выделенный узел для масштабирования Weblate по горизонтали.

База данных

Сервер базы данных PostgreSQL для хранения всего содержимого, см. Настройка базы данных для Weblate.

Используйте выделенный узел базы данных для сайтов с сотнями миллионов слов.

Хранилище данных

Key/value datastore such as Valkey or Redis server for cache and tasks queue, see Фоновые задачи с использованием Celery.

Используйте выделенный узел для масштабирования Weblate по горизонтали.

Файловая система

Файловая система хранения репозиториев VCS и загруженных пользовательских данных. Она является общей для всех процессов.

Используйте сетевое хранилище для масштабирования Weblate по горизонтали.

Сервер электронной почты

SMTP-сервер для исходящей почты, смотрите раздел Настройка исходящей почты. Он может быть предоставлен извне.

Подсказка

Установка с помощью Docker’а includes PostgreSQL and Valkey, making the installation easier.

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

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

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

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

См. также

Обзор архитектуры описывает общую архитектуру Weblate и необходимые сервисы.

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

Weblate is written in Python and supports Python 3.12 or newer. You can install dependencies using pip or from your distribution packages, full list is available in requirements.txt.

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

Django

https://www.djangoproject.com/

Celery

https://docs.celeryq.dev/

Translate Toolkit

https://toolkit.translatehouse.org/

поисковик переводов

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

Python Social Auth

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

Среда Django REST

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

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

Необязательный спецификатор зависимости

Пакеты Python

Функция Weblate

alibaba

Alibaba

amazon

Amazon Translate

gelf

Graylog log management

gerrit

Gerrit

google

Расширенный облачный перевод Google с поддержкой словаря

ldap

Авторизация через LDAP

mercurial

Mercurial

mysql

MySQL или MariaDB, см. Настройка базы данных для Weblate

openai

OpenAI

postgres

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

saml

Авторизация через SAML

saml2idp

Интеграция SAML 2 IDP в Weblate

wlhosted

Интеграция Hosted Weblate

wllegal

Интеграция Hosted Weblate

wsgi

Сервер wsgi для Weblate

zxcvbn

Авторизация по паролю

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

uv pip install "weblate[Postgres,Amazon,SAML]"

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

uv pip install "weblate[all]"

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

uv pip install weblate

Решение проблем с pip install

ERROR: Dependency 'gobject-introspection-2.0' is required but not found.

The installed PyGobject package cannot find a matching GObject Introspection library - gobject-introspection-2.0.

Older versions are no longer supported by Weblate.

ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)

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

uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?

Это известная проблема пакета xmlsec, подробнее смотрите https://github.com/xmlsec/python-xmlsec/issues/314.

lxml & xmlsec libxml2 library version mismatch

Пакеты lxml и xmlsec должны быть собраны с одинаковой libxml2. Чтобы избежать этой проблемы, вам следует собрать их локально:

uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec

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

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

Git

https://git-scm.com/

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

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

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

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

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

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

tesseract (необходимо только в том случае, если бинарные колёса tesserocr недоступны для вашей системы)

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

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

To build some of the Зависимости Python you might need to install their dependencies. This depends on how you install them, so please consult individual packages for documentation. You won’t need those if using prebuilt Wheels while installing using pip or when you use distribution packages.

Pango и Cairo

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

Требования к оборудованию

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

  • 3 ГБ ОЗУ

  • 2-х ядерный процессор

  • 1 ГБ дискового пространства

Примечание

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

Использование памяти

Чем больше памяти, тем лучше — она используется для кэширования на всех уровнях (на уровне файловой системы, уровне базы данных и уровне Weblate). Для сотен компонентов перевода рекомендуется не менее 4 ГБ оперативной памяти.

Подсказка

Для систем с меньшим, чем рекомендуется, объёмом памяти рекомендуется использовать Однопроцессная установка для производства Celery.

Использование CPU

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

Использование хранилища

Типовое использование дискового пространства базой данной находится в районе 300MB на 1 миллион хранимых слов.

Пространство необходимое для клонирования репозиториев разнится, хотя Weblate и пытается поддерживать их размер минимальным, делая поверхностные (shallow) копии.

Узлы

For small and medium-sized sites (millions of hosted words), all Weblate components (see Обзор архитектуры) can be run on a single node.

When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Настройка базы данных для Weblate).

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

Weblate release are cryptographically signed using Sigstore signatures. The signatures are attached to the GitHub release.

The verification can be performed using sigstore package. The following example verifies signature of the 5.4 release:

sigstore verify github \
   --cert-identity https://github.com/WeblateOrg/weblate/.github/workflows/setup.yml@refs/tags/weblate-5.4 \
   --bundle Weblate-5.4-py3-none-any.whl.sigstore \
   Weblate-5.4-py3-none-any.whl

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

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

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

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

You should also take care when running Команды управления, as they should be ran under the same user as Weblate itself is running, otherwise permissions on some files might be wrong.

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

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

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

Поддерживается PostgreSQL 13 и выше. Рекомендуется PostgreSQL 15 и новее.

MySQL и MariaDB is supported, but not recommended for new installs.

Внимание

The support for MySQL and MariaDB is being considered for removal. Please see https://github.com/WeblateOrg/weblate/issues/16140 for more info.

Примечание

No other database servers are currently supported, but support for other Django supported databases should be possible to implement.

Подключения к базе данных

В конфигурации по умолчанию каждый процесс Weblate поддерживает постоянное соединение с базой данных. Постоянные соединения улучшают отзывчивость Weblate, но могут потребовать больше ресурсов для сервера базы данных. Для получения дополнительной информации обратитесь к CONN_MAX_AGE и Persistent connections.

Weblate needs at least the following number of connections:

  • \((4 \times \mathit{nCPUs}) + 2\) for Celery processes

  • \(\mathit{nCPUs} + 1\) for WSGI workers

This applies to Docker container defaults and example configurations provided in this documentation, but the numbers will change once you customize the amount of WSGI workers or adjust parallelism of Celery.

The actual limit for the number of database connections needs to be higher to account following situations:

  • Команды управления need their connection as well.

  • If case process is killed (for example by OOM killer), it might block the existing connection until timeout.

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;
CREATE EXTENSION IF NOT EXISTS btree_gin;

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

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

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Configures name of the PostgreSQL role to alter during the database migration
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
        # Persistent connections
        "CONN_MAX_AGE": None,
        "CONN_HEALTH_CHECKS": True,
    }
}

The database migration performs ALTER ROLE on the database role used by Weblate. In most cases, the name of the role matches the username. In more complex setups the role name is different from the username, and you will get an error about non-existing role during the database migration (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). This is known to happen with Azure Database for PostgreSQL, but it’s not limited to this environment. Please set ALTER_ROLE to change the name of the role Weblate should alter during the database migration.

MySQL и MariaDB

Внимание

The support for MySQL and MariaDB is being considered for removal. Please see https://github.com/WeblateOrg/weblate/issues/16140 for more info.

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

В то время как поддержка MySQL и MariaDB по-прежнему поддерживается в Weblate, наше основное внимание уделяется PostgreSQL. Рекомендуется использовать PostgreSQL для новых установок, а для переноса существующих установок в PostgreSQL см. Переход с других баз данных на PostgreSQL.

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

Weblate can be also used with MySQL or MariaDB, please see MySQL notes and MariaDB notes for caveats using Django with those. Because of the limitations it is recommended to use PostgreSQL for new installations.

Для Weblate требуется MySQL не ниже 8 или MariaDB не ниже 10.5.

Для 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.

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

Several features in Weblate rely on correct HTTP headers being passed to Weblate. When using reverse proxy, please make sure that the needed information is correctly passed.

To debug this configuration, you can look at HTTP environment in Отчёт о производительности.

IP-адрес клиента

This is needed for Ограничение частоты запросов or Журнал аудита.

Weblate parses IP address from the REMOTE_ADDR, which is set by the WSGI handler. This might be empty (when using socket for WSGI) or contain a reverse proxy address, so Weblate needs an additional HTTP header with a client IP address.

Enabling IP_BEHIND_REVERSE_PROXY should be sufficient for the most usual setups, but you might need to adjust IP_PROXY_HEADER and IP_PROXY_OFFSET as well (use WEBLATE_IP_PROXY_HEADER and WEBLATE_IP_PROXY_OFFSET in the Docker container).

Подсказка

This configuration cannot be turned on by default, because it would allow IP address spoofing on installations that don’t have a properly configured reverse proxy.

Server host name

The Host header should match to whatever is configured as SITE_DOMAIN. Additional configuration might be needed in your reverse proxy (for example use ProxyPreserveHost On for Apache or proxy_set_header Host $host; with nginx).

Подсказка

CSRF verification failed errors are often caused by a mismatch between the Host header and configured SITE_DOMAIN.

Протокол клиента

Not passing correct protocol may cause Weblate to end up in redirection loop trying to upgrade client to HTTPS. Make sure it is correctly exposed by the reverse proxy as X-Forwarded-Proto.

This header then needs to be configured in SECURE_PROXY_SSL_HEADER (settings.py) or WEBLATE_SECURE_PROXY_SSL_HEADER (Docker environment).

Важно

The header value is case-sensitive in the configuration, so WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,https and WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPS are not interchangeable.

Подсказка

If you are getting a «Too many redirects» error from the browser, this is most likely caused by mismatch between the actual protocol (HTTPS) and what is observed by Weblate.

Изменено в версии 5.13: The protocol proxy headers are automatically handled by gunicorn in the default configuration, but other WSGI servers have more secure configuration and require explicit setting of this.

Since Weblate 5.13 the Docker container is using granian and it now requires the explicit configuration of WEBLATE_SECURE_PROXY_SSL_HEADER.

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.

Contact form sends e-mail on these as well unless ADMINS_CONTACT is configured.

ALLOWED_HOSTS

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

ALLOWED_HOSTS = ["demo.weblate.org"]

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

ALLOWED_HOSTS = ["*"]

SESSION_ENGINE

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

If you are using Valkey or Redis as cache (see Configure cache) it is recommended to use it for sessions as well:

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

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

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

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

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

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

../_images/admin-wrench.webp

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

weblate check --deploy

You can also review the very same checklist at Отчёт о производительности in the Интерфейс управления.

См. также

Deployment checklist

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

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

DEBUG = False

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

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

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

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

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

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

Изменено в версии 4.2: Prior to the 4.2 release the Django sites framework was used instead, please see The “sites” framework.

Правильная настройка 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.

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

Внимание

The support for MySQL and MariaDB is being considered for removal. Please see https://github.com/WeblateOrg/weblate/issues/16140 for more info.

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

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

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

Configure cache

If possible, use Valkey or Redis from Django by adjusting the CACHES configuration variable, for example:

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",
        },
    }
}

Подсказка

In case you change settings for the cache, you might need to adjust them for Celery as well, see Фоновые задачи с использованием 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.

Подсказка

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

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

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

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

См. также

SECRET_KEY

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

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

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

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

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

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

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

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

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

Системные локали должны быть настроены на поддерживающие 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).

Подсказка

The Weblate container does not include it in the search path, you need to specify full path to execute it. For example:

docker compose exec -u root weblate /usr/sbin/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 выполняется как WSGI или fcgi (смотрите ниже примеры для различных веб-серверов).

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

weblate runserver

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

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

Подсказка

Встроенный сервер Django обслуживает статические файлы только с включённым параметром DEBUG, поскольку он предназначен только для разработки. Для использования в рабочей среде смотрите установки WSGI:

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

Изменено в версии 5.15.2: /media/ is no longer used for serving screenshots.

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

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

/static/

Предоставляет статические файлы для Weblate и интерфейса администратора (определяется STATIC_ROOT).

/favicon.ico

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

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

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

Sample configuration for NGINX and Granian

Следующая конфигурация запускает Weblate с использованием Granian под веб-сервером NGINX:

weblate/examples/weblate.nginx.granian.conf
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 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$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

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

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8888;
        proxy_read_timeout 3600;
    }
}

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

The following configuration runs Weblate using Gunicorn under the NGINX webserver (also available as weblate/examples/weblate.nginx.gunicorn.conf):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 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$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

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

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://unix:/run/gunicorn.sock;
        proxy_read_timeout 3600;
    }
}

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

To run production webserver, use the WSGI wrapper installed with Weblate (when using a Python environment it is installed as ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Don’t forget to set the Python search path to your Python environment as well (for example using virtualenv = /home/user/weblate-env in 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 Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 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$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        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 Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 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.12/site-packages/weblate/wsgi.py

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

# Path to the Python environment
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

См. также

How to use Django with uWSGI

Пример файла настроек 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 Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

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

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

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

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

</VirtualHost>

Примечание

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

Используйте соответствующую версию Python для установки Weblate.

Пример файла настроек 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 Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        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 / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

Sample configuration to start Granian

Weblate has wsgi optional dependency (see Зависимости Python) that will install everything you need to run Granian. When installing Weblate you can specify it as:

uv pip install Weblate[all,wsgi]

Once you have Granian installed, you can run it. This is usually done at the system level. The following examples show starting via systemd:

/etc/systemd/system/granian.service
[Unit]
Description=granian daemon
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
    --no-ws \
    --workers-max-rss 350 \
    --interface wsgi \
    --workers 2 \
    --backpressure 16 \
    --runtime-threads 8 \
    --runtime-mode mt \
    --port 8888 \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target
~

Sample configuration to start Gunicorn

Gunicorn has to be installed separately:

uv pip install gunicorn

Once you have Gunicorn installed, you can run it. This is usually done at the system level. The following examples show starting via systemd:

/etc/systemd/system/gunicorn.socket
[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target
/etc/systemd/system/gunicorn.service
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
    --preload \
    --timeout 3600 \
    --graceful-timeout 3600 \
    --worker-class=gthread \
    --workers=2 \
    --threads=16 \
    --bind unix:/run/gunicorn.sock \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target

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

Когда 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 Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico

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

    # Path to your Weblate Python environment
    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.12/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

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

</VirtualHost>

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

URL_PREFIX = "/weblate"

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

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

A typical setup using Valkey or Redis as a backend looks like this:

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 в качестве системного сервиса

Most likely you will want to run Celery as a daemon and that is covered by Daemonization. For the most common Linux setup using systemd, you can use the example files shipped in the examples folder listed below.

Модуль 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. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
    --queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
    --queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
    --queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
    --queues:backup=backup  --concurrency:backup=1 --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 поставляется со встроенной конфигурацией планировщика задач. Расписание задач хранится в базе данных, а задачи выполняются демоном Celery beat.

Подсказка

You can define additional tasks in settings.py, for example see Отложенные коммиты.

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

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

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

The Celery errors are by default only logged into Celery log and are not visible to user. In case you want to have overview on such failures, it is recommended to configure Сбор отчётов об ошибках и мониторинг производительности.

Однопроцессная установка для производства Celery

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

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo

An installation using Docker can be configured to use a single-process Celery setup by setting CELERY_SINGLE_PROCESS.

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

Это заметно скажется на производительности Weblate.

Мониторинг Weblate

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

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

Сбор отчётов об ошибках и мониторинг производительности

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

Эл. почта

The default Weblate configuration instruments Django to send e-mails upon server errors via django.utils.log.AdminEmailHandler. This is the least effort setup, but you should consider other options for privacy reasons, as the error e-mails might include sensitive data. You can read more on that in Security implications.

To disable this behavior, remove mail_admins from the LOGGING in Weblate settings, or disable WEBLATE_ADMIN_NOTIFY_ERROR in the Docker environment.

Sentry

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

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

Sentry также может использоваться для мониторинга производительности Weblate путем сбора трасс и профилей для определенного процента операций. Это можно настроить с помощью SENTRY_TRACES_SAMPLE_RATE и SENTRY_PROFILES_SAMPLE_RATE.

Rollbar

Weblate имеет встроенную поддержку Rollbar. Для его использования достаточно следовать инструкциям из документа Уведомления Rollbar для 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",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

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

Примечание

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

Graylog log management

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

Weblate can be configured to log using the GELF TCP protocol. This was developed for Graylog integration, but can be used with any compliant logging platform.

The configuration boilerplate is included in Пример файла настроек, for Docker this can be configured using WEBLATE_LOG_GELF_HOST.

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

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

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

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

См. также

Миграция между базами данных описана в разделе Переход с других баз данных на PostgreSQL.

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

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

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

Don’t forget to move other services Weblate might have been using like Valkey, Redis, Cron jobs or custom authentication backends.