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

Установка 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.celeryproject.org/

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

akismet (необязательная зависимость для защиты предложений от спама)

https://github.com/ubernostrum/akismet

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

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

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

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

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

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

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

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

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

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

Git

https://git-scm.com/

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

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

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

https://hub.github.com/

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

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

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

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.

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

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

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

Настройка базы данных для 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 -O weblate weblate

Подсказка

If you don’t want to make the Weblate user a superuser in PostgreSQL, you can omit that. In that case you will have to perform some of the migration steps manually as a PostgreSQL superuser in schema Weblate will use:

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',
        # Database password
        'PASSWORD': 'password',
        # Set to empty string for localhost
        'HOST': 'database.example.com',
        # Set to empty string for default
        'PORT': '',
    }
}

MySQL и MariaDB

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

Подсказка

Some Weblate features will perform better with PostgreSQL. This includes searching and translation memory, which both utilize full-text features in the database and PostgreSQL implementation is superior.

Because of this it is recommended to use PostgreSQL for new installations.

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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.

См.также

ADMINS

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 сохраняет внутри себя гораздо больше информации.

См.также

DEBUG

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

If your site is served over SSL, you have to consider setting a value for SECURE_HSTS_SECONDS in the settings.py to enable HTTP Strict Transport Security. By default it’s set to 0 as shown below.

SECURE_HSTS_SECONDS = 0

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

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

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

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

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

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

Если возможно, используйте 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',
        }
    }
}

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

Помимо кэширования силами 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

Домашний каталог

Изменено в версии 2.1: Больше он не требуется, теперь Weblate хранит все свои данные в каталоге DATA_DIR.

Домашний каталог для пользователя, запустившего Weblate, должен существовать и быть доступен для записи из под этого пользователя. Особенно он необходим, если вы хотите использовать SSH для доступа к частным репозиториям, но доступ к этому каталогу может понадобиться и Git’у (это зависит от используемой вами версии Git’а).

Изменить используемый Weblate каталог вы можете в файле settings.py, например, установив его в каталог configuration внутри дерева Weblate:

os.environ['HOME'] = os.path.join(BASE_DIR, 'configuration')

Примечание

On Linux, and other UNIX like systems, the path to user’s home directory is defined in /etc/passwd. Many distributions default to a non-writable directory for users used for serving web content (such as apache, www-data or wwwrun), so you either have to run Weblate under a different user, or change this setting.

Загрузка шаблонов

Рекомендуется использовать кэширующий загрузчик шаблонов для Django. Он кэширует обработанные шаблоны, избавляя фреймворк от необходимости разбирать их каждый запрос. Настроить его вы можете с помощью следующего фрагмента кода (самое важное здесь — это настройка loaders):

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [
            os.path.join(BASE_DIR, 'templates'),
        ],
        'OPTIONS': {
            'context_processors': [
                'django.contrib.auth.context_processors.auth',
                'django.template.context_processors.debug',
                'django.template.context_processors.i18n',
                'django.template.context_processors.request',
                'django.template.context_processors.csrf',
                'django.contrib.messages.context_processors.messages',
                'weblate.trans.context_processors.weblate_context',
            ],
            'loaders': [
                ('django.template.loaders.cached.Loader', [
                    'django.template.loaders.filesystem.Loader',
                    'django.template.loaders.app_directories.Loader',
                ]),
            ],
        },
    },
]

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

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

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

  • Фиксацию отложенных изменений (ежечасно), смотрите раздел Lazy commits и команду 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".

In some cases the individual services have separate configuration for locales. For example when using Apache you might want to set it in /etc/apache2/envvars:

export LANG='en_US.UTF-8'
export LC_ALL='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 эта функция уже включена.

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

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

Примечание

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

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

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

Запуск 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

Should be rewritten to rewrite a rule to serve /static/favicon.ico.

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

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

Пример конфигурации для NGINX и uWSGI

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

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

Конфигурация для NGINX (пример конфигурации взят из файла weblate/examples/weblate.nginx.conf):

# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
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):

# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.7/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-приложение, вам нужно включить модуль mod_wsgi (пример конфигурации взят из файла weblate/examples/apache.conf):

#
# VirtualHost for Weblate
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

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

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

</VirtualHost>

Примечание

Weblate requires Python 3, so please make sure you are running Python 3 variant of the modwsgi. Usually it is available as a separate package, for example libapache2-mod-wsgi-py3.

Пример конфигурации для Apache и Gunicorn

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

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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 по пути

Изменено в версии 1.3: Поддерживается с версии Weblate 1.3.

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

#
# VirtualHost for Weblate, running under /weblate path
#
# This example assumes Weblate is installed in virtualenv in /home/weblate/weblate-env
# and DATA_DIR is set to /home/weblate/data, please adjust paths to match your setup.
#
<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
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

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

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

</VirtualHost>

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

URL_PREFIX = '/weblate'

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

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

Для обработки фоновых задач Weblate использует 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 в качестве системного сервиса

Скорее всего вы захотите запустить 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 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 concurency if you get weblate.E019
CELERYD_OPTS="--beat:celery --concurrency:celery=4 --queues:celery=celery --prefetch-multiplier:celery=4 \
    --concurrency:notify=4 --queues:notify=notify --prefetch-multiplier:notify=10 \
    --concurrency:translate=4 --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="/var/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

# Internal Weblate variable to indicate we're running inside Celery
CELERY_WORKER_RUNNING="1"

Конфигурация ротации журналов, размещаемая по пути /etc/logrotate.d/celery:

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

Примечание

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

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

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

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

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

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

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

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

Мониторинг Weblate

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

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

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': 'master',
    '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 или модули пользовательской аутентификации.