Настанови з налаштовування¶
Установлення Weblate¶
Залежно від налаштувань та вашого досвіду, виберіть для себе відповідний спосіб встановлення:
Установлення за допомогою Docker, рекомендовано для промислових налаштувань.
Установлення у віртуальному середовищі, рекомендовано для промислових конфігурацій:
Установлення з початкового коду, рекомендовано для розробки.
Огляд архітектури¶
- Вебсервер
Обробка вхідних HTTP-запитів, Обслуговування статичних файлів.
- Робітники Celery
Фонові завдання з використанням Celery виконались тут.
Залежно від вашого робочого навантаження, ви можете налаштувати кількість працівників.
Використовуйте спеціальний вузол для масштабування Weblate по горизонталі.
- WSGI сервер
Сервер WSGI, що обслуговує вебсторінки для користувачів.
Використовуйте спеціальний вузол для масштабування Weblate по горизонталі.
- База даних
Сервер бази даних PostgreSQL для зберігання всього контенту, див. Налаштування бази даних для Weblate.
Використовуйте виділений вузол бази даних для сайтів з сотнями мільйонів розміщених слів.
- Сховище даних
Сховище даних ключ/значення, таке як сервер Valkey або Redis для кешу та черги завдань, див. Фонові завдання з використанням Celery.
Використовуйте спеціальний вузол для масштабування Weblate по горизонталі.
- Файлова система
Файлова система для зберігання репозиторіїв VCS та завантажених користувацьких даних. Це спільне для всіх процесів.
Використовуйте мережеве сховище при горизонтальному масштабуванні Weblate.
- Сервер електронної пошти
SMTP-сервер для вихідної електронної пошти, див. Налаштовування вихідної електронної пошти. Він може бути наданий ззовні.
Підказка
Установлення за допомогою Docker містить PostgreSQL та Valkey, що спрощує встановлення.
Вимоги для програмного забезпечення¶
Операційна система¶
Відомо, що Weblate працює у Linux, FreeBSD і macOS. Ймовірно, Weblate працює на більшості інших Unix-подібних системах.
Підтримки Weblate у Windows не передбачено. Втім, Weblate може там працювати — будемо раді вашим латкам, які реалізуватимуть підтримку.
Дивись також
Огляд архітектури описує загальну архітектуру Weblate та необхідні сервіси.
Залежності Python¶
Weblate написано на Python та підтримує Python 3.12 або новішу версію. Ви можете встановити залежності за допомогою pip або з ваших дистрибутивних пакетів, повний список доступний у requirements.txt.
Основні залежності:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Бібліотеки REST Django
Необов’язковий специфікатор залежності |
Пакунки Python |
Функція Weblate |
|---|---|---|
|
||
|
||
|
||
|
Розширений хмарний перекладач Google з підтримкою глосарію |
|
|
||
|
||
|
PostgreSQL, див. Налаштування бази даних для Weblate |
|
|
||
|
||
|
Інтеграція SAML 2 IDP у Weblate |
|
|
Потрібно для Оновити файл POT (Sphinx) |
|
|
Інтеграція розміщеної Weblate |
|
|
сервер wsgi для Weblate |
|
|
При встановленні за допомогою 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.Встановлений пакет
PyGobjectне може знайти відповідну бібліотеку GObject Introspection —gobject-introspection-2.0.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- Pango, Cairo та пов’язані файли заголовків, а також дані інтроспекції GObject
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, see Pango і Cairo
git-review(необов’язкова, призначено для підтримки Gerrit)git-svn(необов’язкова, призначено для підтримки Subversion)tesseract(потрібно лише якщо бінарні колеса tesserocr недоступні для вашої системи)
Залежності для збирання¶
Для збирання Залежності Python може виникнути потреба у встановленні відповідних залежностей. Список залежить від способу встановлення, тому ознайомтеся із документацією до окремих пакунків. Можливо, встановлення не знадобиться, якщо ви користуєтеся попередньо зібраним Wheels під час встановлення за допомогою pip або пакунками з вашого дистрибутива.
Pango і Cairo¶
Weblate використовує Pango і Cairo для обробки растрових віджетів (див. Розбудова спільноти перекладачів) і перевірки обробки перекладених рядків в інтерфейсі (див. Керування шрифтами). Для належного встановлення прив’язок Python для цих складників вам слід встановити спочатку загальносистемні бібліотеки — вам потрібні і Cairo, і Pango, які, очевидно, залежать від GLib. Усі ці пакунки слід встановити разом із пакунками для розробки та даними інтроспекції GObject.
Вимоги щодо обладнання¶
Weblate повинен без проблем працювати на будь-якому сучасному обладнанні, нижче наведено мінімальну конфігурацію, необхідну для запуску Weblate на одному хості (Weblate, база даних і веб-сервер):
3 ГБ оперативної пам’яті
2 ядра процесора
1 ГБ вільного місця на диску
Примітка
Реальні вимоги до встановленого вами Weblate значно залежать від розміру перекладів, які ним керуються.
Використання пам’яті¶
Чим більше пам’яті, тим краще - вона використовується для кешування на всіх рівнях (файлова система, база даних і Weblate). Для сотень компонентів перекладу рекомендується щонайменше 4 ГБ оперативної пам’яті.
Підказка
Для систем з меншим обсягом пам’яті, ніж рекомендовано, рекомендується використовувати Налаштування однопроцесорного Celery.
Використання CPU¶
Багато одночасних користувачів збільшують кількість необхідних ядер процесора.
Використання сховища¶
Типове використання сховища бази даних становить близько 300 МБ на 1 мільйон розміщених слів.
Обсяг пам’яті, необхідний для клонованих репозиторіїв варіюється, але Weblate намагається тримати його мінімальним, роблячи неглибокі клони.
Вузли¶
Для малих сайтів та сайтів середнього розміру (мільйони розміщених слів), усі складники Weblate (див. Огляд архітектури) можна запустити на одному вузлі.
Якщо кількість розміщених рядків зросте до сотень мільйонів, рекомендуємо розмістити базу даних на окремому вузлі (див. Налаштування бази даних для Weblate).
Перевірка підписів випуску¶
Випуск Weblate криптографічно підписано з використанням підписів Sigstore. Підписи долучено до випуску на GitHub.
Перевірку можна виконати за допомогою пакунка sigstore. У наведеному нижче прикладі виконано перевірку підпису випуску 5.4:
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 намагається створити каталоги автоматично, але це неможливо зробити, якщо для цього немає прав доступу.
The configured CACHE_DIR also has to be writable by the Weblate
process and has to allow executing generated helper files. Do not mount
CACHE_DIR with the noexec option.
Вам також слід бути обережним із запуском Команди керування, оскільки програму слід запускати від імені того самого користувача, що і користувач, від імені якого запущено Weblate, інакше права доступу до деяких файлів можуть виявитися не тими, які потрібні для працездатності системи.
У контейнері Docker усі файли в томі /app/data мають належати користувачеві weblate всередині контейнера (UID 1000).
Дивись також
Налаштування бази даних для Weblate¶
Рекомендуємо користуватися Weblate у поєднанні із сервером баз даних PostgreSQL.
Підтримується PostgreSQL 13 і вище. Рекомендується PostgreSQL 15 або новіша версія.
Дивись також
З’єднання із базою даних¶
За типових налаштувань кожен процес Weblate підтримує постійне з’єднання із базою даних. Постійні з’єднання покращують швидкість відгуку Weblate, але можуть вимагати більше ресурсів для сервера бази даних. Будь ласка, зверніться до CONN_MAX_AGE та Persistent connections для отримання додаткової інформації.
Weblate потрібна принаймні така кількість з’єднань:
\((4 \times \mathit{nCPUs}) + 2\) для процесів Celery
\(\mathit{nCPUs} + 1\) для обробників WSGI
Це стосується типових параметрів контейнера Docker та прикладу налаштувань, який наведено у цій документації, але зміняться числа, щойно ви почнете налаштовувати кількість обробників WSGI або коригувати паралельну обробку у Celery.
Справжнє обмеження на кількість з’єднань із базою даних має бути вищим з метою врахування таких речей:
Команди керування потребують власного з’єднання.
Якщо процес примусово завершується (наприклад засобом знищення процесів OOM), наявне з’єднання може бути заблоковано до завершення часу очікування.
PostgreSQL¶
PostgreSQL, зазвичай є найкращим вибором для заснованих на Django сайтів. Це еталонна база даних, яка використовується для реалізації шару бази даних Django.
Примітка
Weblate використовує розширення обробки триграм, яке можна встановити у деяких випадках. Пошукайте postgresql-contrib або пакунок із подібною назвою.
Дивись також
Створення бази даних у 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,
}
}
Під час перенесення бази даних виконується ALTER ROLE щодо ролі у базі даних, яку використовує Weblate. У більшості випадків назва ролі збігається із іменем користувача. У складніших випадках назва ролі відрізняється від імені користувача, і ви побачите повідомлення про помилку щодо ролі, якої не існує, під час перенесення бази даних (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Таке, як відомо, трапляється із базою даних Azure для PostgreSQL, але проблеми не обмежено лише цим середовищем. Будь ласка, встановіть значення ALTER_ROLE, щоб змінити назву ролі, яку Weblate має поміняти під час перенесення бази даних.
Дивись також
Інші налаштування¶
Налаштовування вихідної електронної пошти¶
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), Найімовірніше, це спричинено використанням незахищеного з’єднання, і сервер відмовляється автентифікуватися цим способом. Спробуйте ввімкнути EMAIL_USE_TLS у такому випадку.
Робота за реверсивним проксі-сервером¶
Кілька функцій Weblate залежать від правильного передавання HTTP-заголовків до Weblate. Під час використання зворотного проксі-сервера переконайтеся, що необхідну інформацію передається правильно.
Щоб налагодити цю конфігурацію, ви можете переглянути HTTP environment у Звіт щодо швидкодії.
- IP-адреса клієнта
Це потрібно для Обмеження частоти або Часопис перевірок.
Weblate аналізує IP-адресу з
REMOTE_ADDR, яка встановлюється обробником WSGI. Вона може бути порожньою (при використанні сокета для WSGI) або містити зворотну проксі-адресу, тому Weblate потребує додаткового HTTP-заголовка з IP-адресою клієнта.Увімкнення
IP_BEHIND_REVERSE_PROXYмає бути достатньо для найпоширеніших налаштувань, але вам може знадобитися налаштуватиIP_PROXY_HEADERіIP_PROXY_OFFSETа також (використовуйтеWEBLATE_IP_PROXY_HEADERіWEBLATE_IP_PROXY_OFFSETу контейнері Docker).Підказка
Цю конфігурацію не можна ввімкнути за замовчуванням, оскільки вона дозволить підробку IP-адреси в інсталяціях, які не мають належним чином налаштованого зворотного проксі-сервера.
- Ім’я хоста сервера
Заголовок Host має відповідати налаштуванням
SITE_DOMAIN. Можливо, знадобиться додаткове налаштування вашого зворотного проксі-сервера (наприклад, використанняProxyPreserveHost Onдля Apache абоproxy_set_header Host $host;з nginx).Підказка
Помилки невдалої перевірки CSRF часто спричинені невідповідністю між заголовком Host та налаштованим
SITE_DOMAIN.- Протокол клієнта
Неправильне передавання протоколу може призвести до того, що Weblate потрапить у цикл перенаправлення, намагаючись оновити клієнта до HTTPS. Переконайтеся, що зворотний проксі-сервер правильно надає його як X-Forwarded-Proto.
Потім цей заголовок потрібно налаштувати в
SECURE_PROXY_SSL_HEADER(settings.py) абоWEBLATE_SECURE_PROXY_SSL_HEADER(середовище Docker).Важливо
Значення заголовка в конфігурації чутливе до регістру, тому
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsтаWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSне є взаємозамінними.Підказка
Якщо ви отримуєте помилку «Забагато перенаправлень» від браузера, це, найімовірніше, спричинено невідповідністю між фактичним протоколом (HTTPS) та тим, що спостерігає Weblate.
Змінено в версії 5.13: За замовчуванням проксі-заголовки протоколу автоматично обробляються gunicorn, але інші сервери WSGI мають безпечнішу конфігурацію та вимагають явного налаштування цього.
Починаючи з версії Weblate 5.13, контейнер Docker використовує granian і тепер вимагає явного налаштування
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.
Форма зв’язку надсилає повідомлення електронної пошти і на ці адреси, якщо не налаштовано
ADMINS_CONTACT.
ALLOWED_HOSTS
Вам слід встановити для цього параметра значення списку вузлів, які має обслуговувати ваш сайт. Приклад:
ALLOWED_HOSTS = ["demo.weblate.org"]Крім того, ви можете включити символ-замінник:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Налаштування способу збереження ваших сеансів. Якщо ви збережете типовий рушій обробника бази даних, вам слід запланувати weblate clearsessions для вилучення застарілих даних сеансу з бази даних.
Якщо ви використовуєте Valkey або Redis як кеш (див. Налаштувати кеш), рекомендується використовувати його також для сесій:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"Дивись також
DATABASES
Можливість з’єднання із сервером бази даних. Будь ласка, ознайомтеся із документацією до Django, щоб дізнатися більше.
Дивись також
DEBUG
Вимкніть цю можливість для будь-яких промислових серверів. Якщо діагностичний режим увімкнено, Django показуватиме користувачам дані зворотного трасування при помилці. Якщо ви вимкнете її, помилки буде надіслано електронною поштою до
ADMINS(див. вище).Режим діагностики також уповільнює роботу Weblate, оскільки у такому режимі Django на внутрішньому рівні зберігає набагато більше даних.
Дивись також
DEFAULT_FROM_EMAIL
Адреса електронної пошти відправника для вихідної електронної пошти, наприклад, повідомлень електронної пошти щодо реєстрації.
Дивись також
SECRET_KEY
Ключ, який використовується Django для підписування даних у куках. Див. Секретний ключ Django, щоб дізнатися більше.
Дивись також
SERVER_EMAIL
Адреса електронної пошти, яку буде використано для надсилання повідомлень електронної пошти адміністратору, наприклад, для сповіщень щодо помилок під час об’єднання змін.
Дивись також
Заповнення бази даних¶
Коли ваші налаштування буде готово, ви можете запустити migrate для створення структури бази даних. Після цього ви зможете створювати проєкти перекладу за допомогою інтерфейсу адміністратора.
Щойно потрібні дії буде виконано, вам слід також ознайомитися зі Звітом щодо швидкодії в інтерфейсі адміністратора, там ви зможете знайти підказки щодо потенційних недоліків у налаштуваннях на вашому сайті.
Дивись також
Промислові налаштування¶
Для налаштовування промислового сервера вам слід виконати коригування, які описано у наступних розділах. Для найкритичніших параметрів буде показано попередження, вказівкою на яке є знак оклику на верхній панелі, який буде показано, якщо ви увійдете на сервер як супер користувач:
Також рекомендуємо вам звернути увагу на підсумки перевірок, які буде започатковано Django (хоча вам і не треба виправляти усі причини показаних попереджень):
weblate check --deploy
Ви також можете скористатися списком дій у Звіт щодо швидкодії з розділу Інтерфейс керування.
Дивись також
Вимкнути режим діагностики¶
Вимикання режиму діагностики Django (DEBUG):
DEBUG = False
З увімкненим режимом діагностики Django зберігає усі виконані запити та показує користувачеві зворотні трасування помилок. Такі надмірні дані є небажаними у промисловій конфігурації.
Дивись також
Належне налаштовування записів адміністраторів¶
Установіть належні адреси адміністраторів за допомогою параметра ADMINS для визначення того, хто отримуватиме повідомлення електронної пошти у випадку, якщо щось на сервері піде не так. Приклад:
ADMINS = ("Your Name <your_email@example.com>",)
Дивись також
Установіть належний домен сайта¶
Скоригуйте назву сайта і домен у інтерфейсі адміністратора, інакше посилання у RSS або у повідомленнях електронної пошти щодо реєстрації не працюватимуть. Налаштувати ці параметри можна за допомогою параметра SITE_DOMAIN, який має містити назву домену сайта.
Змінено в версії 4.2: До випуску 4.2 замість цього використовувалася бібліотека sites Django. Будь ласка, див. 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.
Використання потужного рушія бази даних¶
Будь ласка, скористайтеся PostgreSQL для промислових середовищ. Див. Налаштування бази даних для Weblate, щоб дізнатися більше.
Застосовуйте суміжне розташування для запуску сервера бази даних, інакше швидкодія або надійність мережі можуть зіпсувати роботу Weblate.
Перевірте швидкодію сервера бази даних або налаштуйте його конфігурацію, наприклад, застосувавши PGTune.
Налаштувати кеш¶
Якщо можливо, використовуйте Valkey або 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",
},
}
}
Підказка
Якщо ви зміните налаштування кешу, вам може знадобитися налаштувати їх також і для Celery, див. Фонові завдання з використанням Celery.
Дивись також
Кешування аватару¶
На додачу до кешування даних Django, Weblate виконує кешування аватарів. Рекомендуємо для виконання цього завдання скористатися окремим файловим кешем:
CACHES = {
"default": {
# Default caching backend setup, see above
"BACKEND": "django_redis.cache.RedisCache",
"LOCATION": "unix:///var/run/redis/redis.sock?db=0",
"OPTIONS": {
"CLIENT_CLASS": "django_redis.client.DefaultClient",
"PARSER_CLASS": "redis.connection.HiredisParser",
},
},
"avatar": {
"BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
"LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
"TIMEOUT": 604800,
"OPTIONS": {
"MAX_ENTRIES": 1000,
},
},
}
Налаштовування надсилання електронної пошти¶
Weblate має надсилати повідомлення електронної пошти у декількох випадках. Ці повідомлення повинні мати правильну адресу відправника. Будь ласка, налаштуйте SERVER_EMAIL і DEFAULT_FROM_EMAIL так, щоб значення змінних відповідали вашому середовищу. Приклад:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Примітка
Щоб вимкнути надсилання повідомлень електронної пошти з Weblate, встановіть EMAIL_BACKEND у значення django.core.mail.backends.dummy.EmailBackend.
У результаті буде вимкнено надсилання усіх повідомлень електронної пошти, зокрема повідомлень щодо реєстрації та повідомлень щодо скидання паролів.
Налаштовування дозволених вузлів¶
Django потрібно, щоб у змінній ALLOWED_HOSTS містився список назв доменів, які може обслуговувати ваш сайт. Якщо ця змінна міститиме порожнє значення, будь-які запити буде заблоковано.
Якщо для змінної вказано значення, яке не відповідає вашому серверу HTTP, ви отримаєте повідомлення про помилки, подібні до Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Підказка
У контейнері Docker доступ до відповідної можливості здійснюється за допомогою змінної WEBLATE_ALLOWED_HOSTS.
Секретний ключ Django¶
Значення параметра SECRET_KEY використовується Django для підписування кук. Вам слід створити ваше власне значення і не користуватися значенням з прикладу налаштувань.
Створити новий ключ можна за допомогою програми weblate-generate-secret-key, яка постачається разом із Weblate.
Дивись також
Запуск завдань щодо супроводу¶
Для забезпечення оптимальної швидкодії варто запускати деякі завдання з супроводу працездатності сервера у фоновому режимі. У нових версіях це автоматично виконується за допомогою Фонові завдання з використанням 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'
Стиснення клієнтських даних¶
Weblate постачається із набором файлів JavaScript і CSS. З міркувань забезпечення оптимальної швидкодії варто стиснути їх до надсилання клієнту. У типовій конфігурації результат досягається пакуванням «на льоту» із певною зайвою витратою ресурсів. На серверах із значним навантаженням рекомендуємо увімкнути режим попереднього стискання. Зробити це слід у налаштуваннях, а стискання слід започатковувати після кожного оновлення Weblate.
Перемикання у налаштуваннях є простим — увімкніть django.conf.settings.COMPRESS_OFFLINE і налаштуйте django.conf.settings.COMPRESS_OFFLINE_CONTEXT (останній вже включено у приклад налаштувань):
COMPRESS_OFFLINE = True
При кожному розгортанні вам слід стискати файли відповідно до поточної версії:
weblate compress
Підказка
У офіційному образі для Docker цю можливість вже увімкнено.
Запуск сервера¶
Підказка
Якщо у вас немає досвіду з послугами, описаними далі, ви можете спробувати Установлення за допомогою Docker.
Для роботи Weblate слід мати запущеними декілька служб. Рекомендований набір складається з таких служб:
Сервер бази даних (див. Налаштування бази даних для Weblate)
Сервер кешу (див. Налаштувати кеш)
Сервер-обгортка для статичних файлів і переривання SSL (див. Обслуговування статичних файлів)
Сервер WSGI для динамічних даних (див. Зразок налаштувань для NGINX і uWSGI)
Celery для виконання фонових завдань (див. Фонові завдання з використанням Celery)
Примітка
Між службами є деякі залежності. Наприклад, служби кешування та бази даних має бути запущено до запуску процесів Celery або uwsgi.
У більшості випадків усі служби працюють на одному (віртуальному) сервері, але якщо ваш екземпляр є високонавантаженим, ви можете розділити служби. Єдиним обмеженням щодо цього є те, що сервери Celery і Wsgi повинні мати доступу до DATA_DIR.
Примітка
Процес WSGI має бути запущено від імені того ж користувача, що й Celery, інакше файли в DATA_DIR буде збережено від імені різних власників, що призведе до проблем під час роботи сервера.
Див. також Права доступу у файловій системі і Фонові завдання з використанням Celery.
Запуск вебсервера¶
Запуск Weblate не відрізняється від запуску будь-якої іншої програми на основі Django. Django зазвичай виконується як WSGI або fcgi (див. приклади для різних веб-серверів нижче).
Примітка
The sample configuration files shown below are maintained in the Weblate
source tree under weblate/examples/. They are included in source
distributions and in this documentation, but Python wheels only install
runtime files. When installing Weblate from PyPI, get the matching source
distribution or source checkout before copying these examples.
Для тестування ви можете скористатися вбудованим до Django сервером:
weblate runserver
Попередження
НЕ КОРИСТУЙТЕСЯ ЦИМ СЕРВЕРОМ У ПРОМИСЛОВОМУ СЕРЕДОВИЩІ. Він не проходив перевірки захисту або швидкодії. Також ознайомтеся із документацією до Django щодо runserver.
Підказка
Вбудований сервер Django обслуговує статичні файли лише з увімкненим DEBUG, оскільки він призначений лише для розробки. Для використання у виробничому середовищі, будь ласка, дивіться налаштування WSGI:
Обслуговування статичних файлів¶
Змінено в версії 5.15.2: /media/ більше не використовується для показу скріншотів.
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 та його конфігурацією, але це може потребувати налаштування для вашого середовища.
Приклад конфігурації для NGINX та Granian¶
Наступна конфігурація запускає Weblate з використанням Granian, вебсервера NGINX:
#
# 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
(weblate/examples/weblate.nginx.gunicorn.conf in the source tree):
#
# 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¶
Щоб запустити веб-сервер у виробничому середовищі, скористайтеся обгорткою WSGI, встановленою разом із Weblate (у середовищі Python вона встановлюється за адресою ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Не забудьте також налаштувати шлях пошуку Python на ваше середовище Python (наприклад, використовуючи virtualenv = /home/user/weblate-env в uWSGI).
Наведені нижче налаштування призначено для запуску Weblate як uWSGI із сервером NGINX.
Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):
#
# 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;
}
}
Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):
#
# 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
Дивись також
Зразок налаштувань для Apache¶
Рекомендовано скористатися попереднім відгалуженням MPM при використанні WSGI разом із Weblate.
The following configuration runs Weblate as WSGI, you need to have enabled
mod_wsgi (weblate/examples/apache.conf in the source tree):
#
# 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¶
The following configuration runs Weblate in Gunicorn and Apache 2.4
(weblate/examples/apache.gunicorn.conf in the source tree):
#
# 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>
Зразок конфігурації для запуску Granian¶
Weblate має додаткову залежність wsgi (див. Залежності Python), яка встановить усе необхідне для запуску Granian. Під час встановлення Weblate ви можете вказати це як:
uv pip install Weblate[all,wsgi]
Після встановлення Granian ви можете його запустити. Зазвичай це робиться на системному рівні. Наведені нижче приклади показують запуск через systemd:
[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
~
Приклад конфігурації для запуску Gunicorn¶
Gunicorn потрібно встановити окремо:
uv pip install gunicorn
Після встановлення Gunicorn ви можете запустити його. Зазвичай це робиться на рівні системи. У наступних прикладах показано запуск через systemd:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
[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 у певному каталозі¶
Рекомендовано скористатися попереднім відгалуженням MPM при використанні WSGI разом із Weblate.
A sample Apache configuration to serve Weblate under /weblate. Again using
mod_wsgi (weblate/examples/apache-path.conf in the source tree):
#
# 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, яка запускатиме ці завдання. Наприклад, ця служба відповідає за обробку таких дій (цей список не є повним):
Отримання вебскриптів від зовнішніх служб (див. Обробники сповіщень).
Виконання завдань регулярного супроводу, зокрема резервного копіювання, чищення, щоденного запуску додатків або оновлень (див. Резервне копіювання і пересування Weblate,
BACKGROUND_TASKS, Додатки).Запуск Автоматичний переклад.
Надсилання сповіщення-резюме.
Розвантаження процесу WSGI від витратних обчислювальних дій.
Надсилання змін з черги (див. «Ліниві» внески).
Типова схема з використанням Valkey або Redis як бекенду виглядає так:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Дивись також
You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup
Примітка
Процес Celery має бути запущено від імені того ж користувача, що й процес WSGI, інакше файли в DATA_DIR буде збережено від імені різних власників, що призведе до проблем під час роботи сервера.
Див. також Права доступу у файловій системі і Запуск сервера.
Виконання завдань Celery у WSGI з використанням «жадібного» режиму¶
Примітка
Це матиме значний негативний вплив на швидкодію вебінтерфейсу і зашкодить роботі можливостей, залежно від частоти запуску (наприклад, для надсилання змін з черги, сповіщень дайджесту або резервного копіювання).
Для розробки варто скористатися інтенсивнішими налаштуваннями, за яких обробка усіх завдань відбувається на місці:
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, adapt the example files listed below. These examples are maintained in
the Weblate source tree under weblate/examples/; Python wheels do not
install these deployment samples.
Модуль 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¶
Weblate має вбудовані налаштування для запланованих завдань. Розклад завдань зберігається в базі даних, і завдання виконуються демоном Celery beat.
Підказка
Ви можете визначити додаткові завдання в settings.py, наприклад див. «Ліниві» внески.
Спостереження за станом Celery¶
Знайти поточну довжину черг завдань Celery у Інтерфейс керування. Ви також можете скористатися celery_queues у командному рядку. У випадку значного зростання довжини черги ви також побачите повідомлення про помилку налаштувань у адміністративному інтерфейсі.
Попередження
Повідомлення про помилки Celery, типово, записуються лише до журналу Celery і є невидимими для користувача. Якщо ви хочете бачити огляд помилок подібного типу, рекомендуємо вам налаштувати Збирання звітів щодо помилок та стеження за швидкодією.
Налаштування однопроцесорного Celery¶
Якщо у вас дуже мало оперативної пам’яті, можливо, варто зменшити кількість процесів Weblate. За допомогою цього можна виконати всі завдання Celery в одному процесі:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Встановлення за допомогою Docker можна налаштувати на використання однопроцесного налаштування Celery за допомогою параметра CELERY_SINGLE_PROCESS.
Попередження
Це матиме помітний вплив на швидкодію Weblate.
Спостереження за Weblate¶
У Weblate передбачено адресу /healthz/ для простих перевірок працездатності, наприклад, за допомогою Kubernetes. У контейнера Docker є вбудована перевірка працездатності з використанням цієї адреси.
Для спостереження за метрикою Weblate ви можете скористатися кінцевою точкою програмного інтерфейсу GET /api/metrics/.
Збирання звітів щодо помилок та стеження за швидкодією¶
Weblate, як і будь-яке інше програмне забезпечення, може містити помилки. Для збирання корисних даних щодо критичних помилок ми рекомендуємо користуватися сторонніми службами, які можуть збирати такі дані. Це особливо корисно у випадку помилок, які пов’язано із завданнями Celery. Якщо не користуватися сторонніми засобами, від таких помилок лишається лише запис у журналі — ви не побачите сповіщення щодо них. У Weblate передбачено підтримку таких служб:
Електронна пошта¶
Стандартна конфігурація Weblate використовує Django для надсилання електронних листів про помилки сервера через django.utils.log.AdminEmailHandler. Це найменш складне налаштування, але вам слід розглянути інші варіанти з міркувань конфіденційності, оскільки електронні листи про помилки можуть містити конфіденційні дані. Ви можете дізнатися більше про це в Security implications.
Щоб вимкнути цю поведінку, видаліть mail_admins з LOGGING у налаштуваннях Weblate або вимкніть WEBLATE_ADMIN_NOTIFY_ERROR у середовищі Docker.
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¶
Added in version 5.9.
Weblate можна налаштувати для входу за допомогою протоколу GELF TCP. Це було розроблено для інтеграції Graylog, але його можна використовувати з будь-якою сумісною платформою журналювання.
Шаблон конфігурації включено в Зразок налаштувань, для Docker це можна налаштувати за допомогою WEBLATE_LOG_GELF_HOST.
Перенесення Weblate на інший сервер¶
Перенесення Weblate на інший сервер має бути доволі простою процедурою. Втім, Weblate зберігає дані у декількох місцях, і ці дані слід перенести належним чином. Найкращим підходом є зупинення Weblate для перенесення даних.
Перенесення бази даних¶
Найпростіший спосіб — скористатися вбудованими інструментами бази даних, оскільки вони, як правило, є найефективнішими (наприклад, pg_dump). Крім того, ви можете скористатися реплікацією, якщо ваша база даних її підтримує.
Дивись також
Перенесення даних між базами даних описано у розділі Перенесення даних з інших баз даних до PostgreSQL.
Перенесення сховищ системи керування версіями¶
Сховища коду систем керування версіями, які зберігаються у DATA_DIR, слід також перенести. Ви можете просто скопіювати їх або скористатися командою rsync для виконання завдання з перенесення у ефективніший спосіб.
Інші нотатки¶
Не забудьте перенести інші служби, які Weblate міг використовувати, такі як Valkey, Redis, завдання Cron або власні сервери автентифікації.