Настанови з налаштовування

Встановлення Weblate

Залежно від налаштувань та вашого досвіду, виберіть для себе відповідний спосіб встановлення:

Вимоги для програмного забезпечення

Операційна система

Відомо, що Weblate працює у Linux, FreeBSD і macOS. Ймовірно, Weblate працює на більшості інших Unix-подібних системах.

Підтримки Weblate у Windows не передбачено. Втім, Weblate може там працювати — будемо раді вашим латкам, які реалізуватимуть підтримку.

Інші служби

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/

Бібліотеки REST Django

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 (необов’язковий, для Служба термінології Microsoft)

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/, see Pango і Cairo

git-review (необов’язкова, призначено для підтримки Gerrit)

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

git-svn (необов’язкова, призначено для підтримки Subversion)

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

tesseract і його дані (необов’язкова, для оптичного розпізнавання тексту на знімках вікон)

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

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

https://github.com/licensee/licensee

Залежності для збирання

Для збирання Залежності Python може виникнути потреба у встановленні відповідних залежностей. Список залежить від способу встановлення, тому ознайомтеся із документацією до окремих пакунків. Можливо, встановлення не знадобиться, якщо ви користуєтеся попередньо зібраним Wheels під час встановлення за допомогою pip або пакунками з вашого дистрибутива.

Pango і Cairo

Змінено в версії 3.7.

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

Перевірка підписів випуску

Випуск Weblate має криптографічний підпис розробника, відповідального за випуск. У поточній версії цим розробником є Міхал Чихарж (Michal Čihař). Відбиток його ключа 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 цю тему висвітлено у розділі Validating other keys on your public keyring. Найнадійнішим способом встановлення автентичності ключа є особиста зустріч із розробником і обмін відбитками ключів. Втім, ви також можете покластися на мережу довіри. У такій мережі ви можете довіритися ключ опосередковано — через підписи інших осіб, які зустрічалися із розробником особисто.

Щойно ключ стане довіреним, має бути показано попередження:

$ 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, інакше права доступу до деяких файлів можуть виявитися не тими, які потрібні для працездатності системи.

У контейнері Docker усі файли в томі /app/data мають належати користувачеві вебсервера всередині контейнера (UID 1000).

Налаштування бази даних для Weblate

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

PostgreSQL

PostgreSQL, зазвичай є найкращим вибором для заснованих на Django сайтів. Це еталонна база даних, яка використовується для реалізації шару бази даних Django.

Примітка

Weblate використовує розширення обробки триграм, яке можна встановити у деяких випадках. Пошукайте postgresql-contrib або пакунок із подібною назвою.

Дивись також

PostgreSQL notes

Створення бази даних у PostgreSQL

Зазвичай, варто зробити так, щоб Weblate працював із окремою базою даних і окремим обліковим записом користувача:

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

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

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

Підказка

Якщо ви не хочете робити користувача Weblate суперкористувачем у PostgreSQL, ви можете пропустити це. У такому випадку вам доведеться виконати деякі з кроків з перенесення вручну від імені суперкористувача PostgreSQL у схемі, яку використовуватиме Weblate:

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;

Налаштовування Weblate на використання PostgreSQL

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

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

У коді перенесення даних зроблено припущення, що назва ролі збігається з вказаним під час розпізнавання іменем користувача. Якщо це не так, встановіть ALTER_ROLE. Якщо цього не зробити, ви отримаєте повідомлення про помилку від PostgreSQL про те, що ролі не існує, під час перенесення бази даних (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist).

MySQL і MariaDB

Weblate можна також користуватися із MySQL або MariaDB. Будь ласка, ознайомтеся із розділами MySQL notes і MariaDB notes, щоб дізнатися більше про можливі проблеми із використанням Django разом із цими серверами баз даних.

Підказка

Деякі можливості Weblate працюватимуть краще з використанням PostgreSQL. Це стосується пошуку і пам’яті перекладів — можливостей, у яких використовується повнотекстова обробка у базі даних — реалізація у PostgreSQL є найкращою.

Через це, ми рекомендуємо використовувати для нових встановлених екземплярів PostgreSQL.

Рекомендовано такі налаштування для Weblate:

  • Скористайтеся набором символів utf8mb4, щоб уможливити обробку вищих блоків Unicode (зокрема емодзі).

  • Налаштуйте сервер за допомогою 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-адреси. Серед цих можливостей Обмеження частоти, Захист від спаму та Часопис перевірок.

За типових налаштувань 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

Дивись також

Deployment checklist

Вимкнути режим діагностики

Вимикання режиму діагностики 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 у :file`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, щоб дізнатися більше.

Увімкніть кешування

Якщо можна, скористайтеся 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'. Тоді вам потрібно додати '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')

Примітка

У Linux та інших системах UNIX шлях до домашнього каталогу користувача визначається у /etc/passwd. У багатьох дистрибутивах типовим є непридатний до запису каталог для користувачів, записи яких призначено для обслуговування інтернет-даних (зокрема apache, www-data або wwwrun). Тому вам слід або запускати Weblate від імені іншого користувача, або змінити значення цього параметра.

Дивись також

Доступ до сховищ

Завантаження шаблонів

Рекомендуємо скористатися засобом завантаження кешованих шаблонів для 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',
                ]),
            ],
        },
    },
]

Дивись також

django.template.loaders.cached.Loader

Запуск завдань щодо супроводу

Для забезпечення оптимальної швидкодії варто запускати деякі завдання із супроводу працездатності сервера у фоновому режимі. У нових версіях це автоматично виконується за допомогою Фонові завдання з використанням Celery і стосується таких завдань:

  • Перевірки коректності налаштувань (щогодинно).

  • Надсилання змін з черги (щогодини), див. «Ліниві» внески і commit_pending.

  • Оновлення нагадувань щодо складників (щоденно).

  • Оновлення віддалених гілок (щодня), див. AUTO_UPDATE.

  • Резервного копіювання пам’яті перекладів до JSON (щодня), див. dump_memory.

  • Завдань із супроводу обробки усього тексту та бази даних (щоденних і щотижневих завдань), див. cleanuptrans.

Змінено в версії 3.2: Починаючи з версії 3.2, типовим способом виконання цих завдань є використання Celery, а Weblate постачається уже налаштованим відповідним чином, див. Фонові завдання з використанням Celery.

Локалі і кодування системи

Для локалі системи слід вибрати якусь із локалей UTF-8. У більшості дистрибутивів Linux такий вибір є типовим. Якщо у вашій системі вибрано якусь іншу локаль, будь ласка, змініть локаль на один з варіантів UTF-8.

Зробити це можна, наприклад, редагуванням /etc/default/locale зі встановленням LANG="C.UTF-8".

У деяких випадках окремі служби мають окремі налаштування для локалей. Наприклад, при використанні Apache вам, можливо, слід встановити їх у файлі /etc/apache2/envvars:

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

Використання нетипових уповноважень за сертифікатом

Weblate не виконує перевірку сертифікатів SSL під час обробки запитів HTTP. Якщо ви використовуєте нетипову службу сертифікації, яка не є довіреною у типових пакетах, вам слід додати її сертифікат як довірений.

Бажаним підходом для цього є додавання на загальносистемному рівні. Щоб дізнатися більше про способи додавання, будь ласка, ознайомтеся із документацією до дистрибутива (наприклад, у Debian досягти потрібного результату можна записом сертифіката служби сертифікації до /usr/local/share/ca-certificates/ із наступним виконанням команди update-ca-certificates).

Щойно сертифікат буде додано, загальносистемні інструменти зареєструють довіру до сертифіката. Це стосується і Git.

У коді мовою 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

Має бути перезаписано для перезапису правила обслуговування /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

Дивись також

How to use Django with uWSGI

Зразок налаштувань для 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 потрібен Python 3, тому вам слід переконатися, що ви працюєте із версією modwsgi для Python 3. Зазвичай, ця версія встановлюється з окремого пакунка, наприклад 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>

Дивись також

How to use Django with Gunicorn

Запуск 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 як фонової служби. Опис відповідних налаштувань можна знайти у розділі Daemonization. Для найпоширенішої конфігурації Linux із використанням systemd ви можете скористатися файлами прикладів, які постачаються у теці examples. Список цих файлів наведено нижче.

Модуль systemd, який слід зберегти як /etc/systemd/system/celery-weblate.service:

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

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

[Install]
WantedBy=multi-user.target

Налаштування середовища, які слід зберегти як /etc/default/celery-weblate:

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

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

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

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

# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/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"

Налаштування logrotate, які слід зберегти як /etc/logrotate.d/celery:

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

Примітка

Процес Celery має бути запущено від імені того самого користувача, що і Weblate і процес WSGI, інакше файли у DATA_DIR буде збережено від імені різних власників, що призведе до проблем під час роботи сервера.

Регулярні завдання з використанням тактів Celery

Weblate постачається із вбудованою конфігурацією для запланованих завдань. Втім, ви можете визначити додаткові завдання у файлі settings.py. Приклад наведено у розділі «Ліниві» внески.

Виконання завдань має забезпечувати фонова служба регулярних подій Celery. Якщо ця служба не працює належним чином, її могло бути не запущено або її базу даних могло бути пошкоджено. Якщо виникають проблеми, ознайомтеся із журналом запуску Celery, щоб визначити причину.

Спостереження за станом Celery

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

Попередження

Повідомлення про помилки Celery, типово, записуються лише до журналу Celery і є невидимими для користувача. Якщо ви хочете бачити огляд помилок подібного типу, рекомендуємо вам налаштувати Збирання звітів щодо помилок.

Спостереження за Weblate

У Weblate передбачено адресу /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.

Якщо коротко, вам слід скоригувати 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 зберігає дані у декількох місцях, і ці дані слід перенести належним чином. Найкращим підходом є зупинення 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 і нетипові модулі розпізнавання.