Instrucțiuni de configurare

Instalarea Weblate

În funcție de configurația și experiența dumneavoastră, alegeți o metodă de instalare adecvată pentru dumneavoastră:

Cerințe software

Sistem de operare

Se știe că Weblate funcționează pe Linux, FreeBSD și macOS. Cel mai probabil vor funcționa și alte sisteme de tip Unix.

Weblate nu este acceptat pe Windows. Dar este posibil să funcționeze în continuare, iar patch-urile sunt acceptate cu plăcere.

Alte servicii

Weblate utilizează alte servicii pentru funcționarea sa. Veți avea nevoie ca cel puțin următoarele servicii să funcționeze:

Dependențe Python

Weblate este scris în Python și suportă Python 3.6 sau o versiune mai nouă. Puteți instala dependențele folosind pip sau din pachetele de distribuție, lista completă este disponibilă în requirements.txt.

Cele mai notabile dependențe:

Django

https://www.djangoproject.com/

Celery

https://docs.celeryproject.org/

Traducere Toolkit

https://toolkit.translatehouse.org/

traducător-finder

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

Python Social Auth

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

Cadrul Django REST

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

Dependențe opționale

Următoarele module sunt necesare pentru anumite caracteristici ale Weblate. Le puteți găsi pe toate în requirements-optional.txt.

Mercurial (optional for Mercurial repositories support)

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

phply (optional for Șiruri PHP)

https://github.com/viraptor/phply

tesserocr (optional for OCR in Context vizual pentru șiruri de caractere)

https://github.com/sirfz/tesserocr

akismet (optional for Protecția împotriva spam-ului)

https://github.com/ubernostrum/akismet

ruamel.yaml (opțional pentru Fișiere YAML)

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

Zeep (opțional pentru ms-terminologie`)

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

aeidon (opțional pentru Fișiere de subtitrare)

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

fluent.syntax (optional for Format fluent)

https://projectfluent.org/

Sugestie

When installing using pip, you can directly specify desired features when installing:

pip install "Weblate[PHP,Fluent]"

Or you can install Weblate will all optional features:

pip install "Weblate[all]"

Or you can install Weblate without any optional features:

pip install Weblate

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

Weblate suportă PostgreSQL, MySQL și MariaDB, consultați Configurarea bazei de date pentru Weblate și documentația backends pentru mai multe detalii.

Alte cerințe de sistem

Următoarele dependențe trebuie să fie instalate pe sistem:

Git

https://git-scm.com/

Pango, Cairo și fișierele antet aferente și datele de introspecție gir

https://cairographics.org/, https://pango.gnome.org/, vezi Pango și Cairo

git-review (opțional pentru suport Gerrit)

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

git-svn (opțional pentru suport pentru Subversion)

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

tesseract și datele sale (opțional pentru OCR-ul capturilor de ecran)

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

licensee (opțional pentru detectarea licenței la crearea componentei)

https://github.com/licensee/licensee

Dependențe în timp de construcție

Pentru a construi unele dintre Dependențe Python, ar putea fi necesar să instalați dependențele acestora. Acest lucru depinde de modul în care le instalați, așa că vă rugăm să consultați pachetele individuale pentru documentație. Nu veți avea nevoie de acestea dacă folosiți Wheels preinstalate în timp ce instalați folosind pip sau când folosiți pachete de distribuție.

Pango și Cairo

Schimbat în versiunea 3.7.

Weblate folosește Pango și Cairo pentru redarea widget-urilor bitmap (vezi Promovarea traducerii) și pentru redarea verificărilor (vezi Gestionarea fonturilor). Pentru a instala corect legăturile Python pentru acestea, trebuie să instalați mai întâi bibliotecile de sistem - aveți nevoie atât de Cairo, cât și de Pango, care la rândul lor au nevoie de GLib. Toate acestea ar trebui să fie instalate împreună cu fișierele de dezvoltare și datele de introspecție GObject.

Verificarea semnăturilor de eliberare

Versiunile Weblate sunt semnate criptografic de către dezvoltatorul care le-a lansat. În prezent, acesta este Michal Čihař. Amprenta digitală a cheii sale PGP este:

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

și puteți obține mai multe informații de identificare de la <https://keybase.io/nijel>.

Trebuie să verificați dacă semnătura corespunde arhivei pe care ați descărcat-o. În acest fel, puteți fi sigur că utilizați același cod care a fost lansat. De asemenea, ar trebui să verificați data semnăturii pentru a vă asigura că ați descărcat cea mai recentă versiune.

Fiecare arhivă este însoțită de fișiere .asc care conțin semnătura PGP pentru aceasta. Odată ce le aveți pe amândouă în același dosar, puteți verifica semnătura:

$ 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

După cum puteți vedea, GPG se plânge că nu cunoaște cheia publică. În acest moment, trebuie să efectuați unul dintre următorii pași:

  • Utilizați wkd pentru a descărca cheia:

$ 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]
  • Descărcați keyring-ul de pe serverul Michal’s, apoi importați-l cu:

$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm
  • Descărcați și importați cheia de pe unul dintre serverele de chei:

$ 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

Acest lucru va îmbunătăți puțin situația - în acest moment puteți verifica dacă semnătura din cheia dată este corectă, dar tot nu puteți avea încredere în numele folosit în cheie:

$ 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

Problema aici este că oricine ar putea emite cheia cu acest nume. Trebuie să vă asigurați că cheia este deținută efectiv de persoana menționată. Manualul de confidențialitate GNU tratează acest subiect în capitolul Validarea altor chei de pe brelocul de chei publice. Cea mai fiabilă metodă este să vă întâlniți personal cu dezvoltatorul și să faceți schimb de amprente ale cheii, însă vă puteți baza și pe rețeaua de încredere. În acest fel, puteți avea încredere în cheie în mod tranzitoriu prin intermediul semnăturilor altor persoane, care au întâlnit dezvoltatorul în persoană.

Odată ce cheia este de încredere, avertismentul nu va mai apărea:

$ 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]

În cazul în care semnătura nu este valabilă (arhiva a fost modificată), veți primi o eroare clară, indiferent dacă cheia este de încredere sau nu:

$ 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]

Permisiunile sistemului de fișiere

Procesul Weblate trebuie să fie capabil să citească și să scrie în directorul în care păstrează datele - DATA_DIR. Toate fișierele din acest director trebuie să fie deținute și scriere de către utilizatorul care rulează toate procesele Weblate (de obicei WSGI și Celery, a se vedea Rularea serverului și Sarcini de fundal folosind Celery).

Configurația implicită le plasează în același arbore ca și sursele Weblate, însă ați putea prefera să le mutați într-o locație mai bună, cum ar fi: /var/lib/weblate.

Weblate încearcă să creeze aceste directoare în mod automat, dar nu va reuși dacă nu are permisiuni pentru a face acest lucru.

De asemenea, trebuie să aveți grijă când rulați Comenzi de gestionare, deoarece acestea ar trebui să fie rulate sub același utilizator cu cel care rulează Weblate însuși, altfel permisiunile pentru unele fișiere ar putea fi greșite.

În containerul Docker, toate fișierele din volumul /app/data trebuie să fie deținute de utilizatorul weblate din container (UID 1000).

Configurarea bazei de date pentru Weblate

Se recomandă ca Weblate să ruleze cu un server de baze de date PostgreSQL.

PostgreSQL

PostgreSQL este, de obicei, cea mai bună alegere pentru site-urile bazate pe Django. Este baza de date de referință utilizată pentru implementarea stratului de baze de date Django.

Notă

Weblate utilizează extensia Trigram, care trebuie instalată separat în unele cazuri. Căutați postgresql-contrib sau un pachet cu nume similar.

Vezi și

PostgreSQL notes

Crearea unei baze de date în PostgreSQL

De obicei, este o idee bună să executați Weblate într-o bază de date separată și într-un cont de utilizator separat:

# 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

Sugestie

Dacă nu doriți să faceți din utilizatorul Weblate un superutilizator în PostgreSQL, puteți omite acest lucru. În acest caz, va trebui să efectuați manual unele dintre etapele de migrare ca superutilizator PostgreSQL în schema pe care o va folosi Weblate:

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;

Configurarea Weblate pentru a utiliza PostgreSQL

Fragmentul settings.py pentru 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": "",
    }
}

Migrarea bazei de date efectuează ALTER ROLE pe rolul bazei de date utilizat de Weblate. În cele mai multe cazuri, numele rolului se potrivește cu numele de utilizator. În configurațiile mai complexe, numele rolului este diferit de numele de utilizator și veți primi o eroare privind inexistența rolului în timpul migrării bazei de date (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Se știe că acest lucru se întâmplă cu Azure Database pentru PostgreSQL, dar nu se limitează la acest mediu. Vă rugăm să setați ALTER_ROLE pentru a schimba numele rolului pe care Weblate ar trebui să îl modifice în timpul migrării bazei de date.

MySQL și MariaDB

Sugestie

Unele caracteristici Weblate vor funcționa mai bine cu PostgreSQL. Aceasta include căutarea și memoria de traducere, care utilizează ambele caracteristici full-text în baza de date, iar implementarea PostgreSQL este superioară.

Weblate poate fi folosit și cu MySQL sau MariaDB, vă rugăm să consultați MySQL notes și MariaDB notes pentru avertismente legate de utilizarea Django cu acestea. Din cauza limitărilor, se recomandă să folosiți PostgreSQL pentru noile instalări.

Weblate necesită MySQL cel puțin 5.7.8 sau MariaDB cel puțin 10.2.7.

Următoarea configurație este recomandată pentru Weblate:

  • Utilizați setul de caractere utf8mb4 pentru a permite reprezentarea planurilor Unicode superioare (de exemplu, emojis).

  • Configurați serverul cu innodb_large_prefix pentru a permite indici mai lungi pentru câmpurile text.

  • Setați nivelul de izolare la READ COMMITTED.

  • Modul SQL trebuie să fie setat la STRICT_TRANS_TABLES.

MySQL 8.x, MariaDB 10.5.x sau mai nou au o configurație implicită rezonabilă, astfel încât nu ar trebui să fie necesară nicio modificare a serverului și tot ceea ce este necesar poate fi configurat pe partea de client.

Mai jos este un exemplu de /etc/my.cnf.d/server.cnf pentru un server cu 8 GB de RAM. Aceste setări ar trebui să fie suficiente pentru majoritatea instalațiilor. MySQL și MariaDB au reglaje care vor crește performanțele serverului, care sunt considerate a nu fi necesare decât dacă plănuiți să aveți un număr mare de utilizatori simultani care să acceseze sistemul. Consultați documentația diferiților furnizori pentru aceste detalii.

Este absolut esențial, pentru a reduce problemele la instalare, ca setarea innodb_file_per_table să fie setată corect și MySQL/MariaDB să fie repornit înainte de a începe instalarea Weblate.

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

datadir=/var/lib/mysql

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

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

Sugestie

În cazul în care primiți eroarea #1071 - Cheia specificată a fost prea lungă; lungimea maximă a cheii este de 767 octeți, vă rugăm să vă actualizați configurația pentru a include setările innodb de mai sus și să reporniți instalarea.

Sugestie

În cazul în care primiți eroarea #2006 - MySQL server has gone away, configurarea CONN_MAX_AGE v-ar putea ajuta.

Configurarea Weblate pentru a utiliza MySQL/MariaDB

Fragmentul settings.py pentru MySQL și MariaDB:

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

De asemenea, trebuie să creați contul de utilizator weblate în MySQL sau MariaDB înainte de a începe instalarea. Utilizați comenzile de mai jos pentru a realiza acest lucru:

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

Alte configurații

Configurarea e-mailului de ieșire

Weblate trimite e-mailuri cu diferite ocazii - pentru activarea contului și la diferite notificări configurate de utilizatori. Pentru aceasta are nevoie de acces la un server SMTP.

Configurarea serverului de poștă electronică este configurată cu ajutorul acestor setări: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER și EMAIL_PORT. Numele lor sunt destul de explicite, dar puteți găsi mai multe informații în documentația Django.

Sugestie

În cazul în care primiți o eroare de autentificare neacceptată (de exemplu SMTP AUTH extension not supported by server), cel mai probabil aceasta este cauzată de utilizarea unei conexiuni nesigure și serverul refuză să se autentifice în acest mod. Încercați să activați EMAIL_USE_TLS în acest caz.

Rularea în spatele unui proxy invers

Mai multe funcții din Weblate se bazează pe posibilitatea de a obține adresa IP a clientului. Printre acestea se numără Limitarea ratei, Protecția împotriva spam-ului sau Jurnal de audit.

În configurația implicită, Weblate analizează adresa IP din REMOTE_ADDR care este setată de gestionarul WSGI.

În cazul în care utilizați un proxy invers, acest câmp va conține, cel mai probabil, adresa acestuia. Trebuie să configurați Weblate pentru a avea încredere în antetele HTTP suplimentare și să analizați adresa IP din acestea. Acest lucru nu poate fi activat în mod implicit, deoarece ar permite falsificarea adresei IP pentru instalațiile care nu utilizează un proxy invers. Activarea IP_BEHIND_REVERSE_PROXY ar putea fi suficientă pentru cele mai obișnuite configurații, dar poate fi necesar să ajustați IP_PROXY_HEADER și IP_PROXY_OFFSET.

HTTP proxy

Weblate execută comenzi VCS și acceptă configurația proxy din mediul înconjurător. Abordarea recomandată este de a defini setările proxy în settings.py:

import os

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

Ajustarea configurației

Copiați weblate/settings_example.py în weblate/settings.py și ajustați-l pentru a se potrivi cu configurația dumneavoastră. Probabil că veți dori să ajustați următoarele opțiuni:

ADMINS

Lista de administratori de site care trebuie să primească notificări atunci când ceva nu merge bine, de exemplu, notificări privind fuziunile eșuate sau erorile Django.

ALLOWED_HOSTS

Trebuie să setați acest lucru pentru a lista gazdele pe care site-ul tău trebuie să le deservească. De exemplu:

ALLOWED_HOSTS = ["demo.weblate.org"]

Alternativ, puteți include caractere wildcard:

ALLOWED_HOSTS = ["*"]

SESSION_ENGINE

Configurați modul în care vor fi stocate sesiunile dvs. În cazul în care păstrați motorul implicit al bazei de date backend, ar trebui să programați: weblate clearsessions pentru a elimina din baza de date datele vechi ale sesiunilor.

Dacă utilizați Redis ca memorie cache (a se vedea Activați memoria cache), este recomandat să o utilizați și pentru sesiuni:

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

DATABASES

Conectivitatea la serverul de baze de date, vă rugăm să consultați documentația Django pentru mai multe detalii.

DEBUG

Dezactivați acest lucru pentru orice server de producție. Cu modul de depanare activat, Django va arăta utilizatorilor backtraces în caz de eroare, când îl dezactivați, erorile vor fi trimise prin e-mail către ADMINS (vezi mai sus).

Modul de depanare încetinește, de asemenea, Weblate, deoarece Django stochează mult mai multe informații pe plan intern în acest caz.

DEFAULT_FROM_EMAIL

Adresa de e-mail a expeditorului pentru e-mailurile de ieșire, de exemplu e-mailurile de înregistrare.

SECRET_KEY

Cheia folosită de Django pentru a semna unele informații în cookie-uri, vezi Cheia secretă Django pentru mai multe informații.

Vezi și

SECRET_KEY

SERVER_EMAIL

E-mail utilizat ca adresă de expeditor pentru trimiterea de e-mailuri către administrator, de exemplu notificări privind fuziunile eșuate.

Vezi și

SERVER_EMAIL

Completarea bazei de date

După ce configurația ta este gata, poți rula weblate migrate pentru a crea structura bazei de date. Acum ar trebui să poți crea proiecte de traducere folosind interfața de administrare.

În cazul în care doriți să executați o instalare neinteractivă, puteți utiliza weblate migrate --noinput, iar apoi să creați un utilizator administrator utilizând comanda createadmin.

După ce ați terminat, ar trebui, de asemenea, să verificați Raportul de performanță din interfața de administrare, care vă va oferi indicii cu privire la o potențială configurație neoptimă a site-ului dumneavoastră.

Configurarea producției

Pentru o configurație de producție, trebuie să efectuați ajustările descrise în secțiunile următoare. Cele mai critice setări vor declanșa un avertisment, care este indicat printr-un semn de exclamare în bara de sus dacă sunteți conectat ca superutilizator:

../_images/admin-wrench.png

De asemenea, se recomandă să inspectați verificările declanșate de Django (deși s-ar putea să nu fie nevoie să le reparați pe toate):

weblate check --deploy

De asemenea, puteți examina aceeași listă de verificare din Interfața de gestionare.

Dezactivați modul de depanare

Dezactivați modul de depanare al lui Django (DEBUG) prin:

DEBUG = False

Cu modul de depanare activat, Django stochează toate interogările executate și arată utilizatorilor traseele erorilor, ceea ce nu este de dorit într-o configurație de producție.

Configurați în mod corespunzător administratorii

Setați adresele de administrator corecte în setarea ADMINS pentru a defini cine va primi e-mailuri în cazul în care ceva nu merge bine pe server, de exemplu:

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

Setați domeniul corect al site-ului

Ajustați numele site-ului și domeniul în interfața de administrare, altfel linkurile din RSS sau din e-mailurile de înregistrare nu vor funcționa. Acest lucru este configurat cu ajutorul SITE_DOMAIN care trebuie să conțină numele domeniului site-ului.

Schimbat în versiunea 4.2: Înainte de versiunea 4.2, a fost folosit în schimb cadrul Django sites, consultați The “sites” framework.

Configurați corect HTTPS

Se recomandă cu tărie să executați Weblate utilizând protocolul HTTPS criptat. După ce îl activați, trebuie să setați ENABLE_HTTPS în setări:

ENABLE_HTTPS = True

Sugestie

Este posibil să doriți să configurați și HSTS, consultați SSL/HTTPS pentru mai multe detalii.

Setați corect SECURE_HSTS_SECONDS

Dacă site-ul tău este servit prin SSL, trebuie să ai în vedere setarea unei valori pentru SECURE_HSTS_SECONDS în settings.py pentru a activa HTTP Strict Transport Security. În mod implicit, este setată la 0, așa cum se arată mai jos.

SECURE_HSTS_SECONDS = 0

Dacă este setat la o valoare întreagă diferită de zero, django.middleware.security.SecurityMiddleware setează antetul HTTP Strict Transport Security pe toate răspunsurile care nu îl au deja.

Atenționare

Setarea incorectă a acestui parametru vă poate distruge ireversibil (pentru o perioadă de timp) site-ul. Citiți mai întâi documentația HTTP Strict Transport Security.

Utilizați un motor de baze de date puternic

  • Vă rugăm să folosiți PostgreSQL pentru un mediu de producție, consultați Configurarea bazei de date pentru Weblate pentru mai multe informații.

  • Folosiți o locație adiacentă pentru a rula serverul de baze de date, în caz contrar performanța sau fiabilitatea rețelei ar putea să vă distrugă experiența Weblate.

  • Verificați performanța serverului de baze de date sau modificați configurația acestuia, de exemplu folosind PGTune.

Activați memoria cache

Dacă este posibil, utilizați Redis din Django prin ajustarea variabilei de configurare CACHES, de exemplu:

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

Sugestie

În cazul în care modificați setările Redis pentru memoria cache, este posibil să trebuiască să le ajustați și pentru Celery, consultați Sarcini de fundal folosind Celery.

Avatar în memoria cache

În plus față de memoria cache a lui Django, Weblate realizează și memoria cache a avatarelor. În acest scop, se recomandă utilizarea unui cache separat, susținut de fișiere:

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

Configurați trimiterea de e-mailuri

Weblate trebuie să trimită e-mailuri în mai multe ocazii, iar aceste e-mailuri trebuie să aibă o adresă de expeditor corectă, vă rugăm să configurați SERVER_EMAIL și DEFAULT_FROM_EMAIL pentru a se potrivi cu mediul dumneavoastră, de exemplu:

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

Notă

Pentru a dezactiva trimiterea de e-mailuri prin Weblate, setați EMAIL_BACKEND la django.core.mail.backends.dummy.EmailBackend.

Acest lucru va dezactiva toată livrarea de e-mailuri, inclusiv e-mailurile de înregistrare sau de resetare a parolei.

Configurarea gazdelor permise

Django are nevoie ca ALLOWED_HOSTS să conțină o listă de nume de domenii pe care site-ul tău are voie să le servească, dacă o lași goală va bloca orice cerere.

În cazul în care acesta nu este configurat pentru a se potrivi cu serverul dumneavoastră HTTP, veți primi erori de tipul Invalid HTTP_HOST header: '1.1.1.1.1'. Este posibil fie necesar adăugați '1.1.1.1.1' la ALLOWED_HOSTS.

Sugestie

Pe containerul Docker, acest lucru este disponibil ca WEBLATE_ALLOWED_HOSTS.

Cheia secretă Django

Setarea SECRET_KEY este folosită de Django pentru a semna cookie-urile și ar trebui să vă generați propria valoare, mai degrabă decât să o folosiți pe cea din exemplul de configurare.

Puteți genera o cheie nouă utilizând weblate/examples/generate-secret-key livrat cu Weblate.

Director acasă

Schimbat în versiunea 2.1: Acest lucru nu mai este necesar, Weblate stochează acum toate datele sale în DATA_DIR.

Directorul principal al utilizatorului care rulează Weblate trebuie să existe și să poată fi scris de către acest utilizator. Acest lucru este necesar în special dacă doriți să utilizați SSH pentru a accesa depozite private, dar este posibil ca și Git să aibă nevoie să acceseze acest director (în funcție de versiunea Git pe care o utilizați).

Puteți schimba directorul utilizat de Weblate în settings.py, de exemplu, pentru a-l seta în directorul configuration din cadrul arborelui Weblate:

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

Notă

Pe Linux și pe alte sisteme de tip UNIX, calea către directorul de domiciliu al utilizatorului este definită în /etc/passwd. Multe distribuții folosesc în mod implicit un director care nu poate fi scris pentru utilizatorii folosiți pentru a servi conținut web (cum ar fi apache, www-data sau wwwrun), așa că trebuie fie să rulați Weblate sub un alt utilizator, fie să modificați această setare.

Încărcarea șablonului

Se recomandă utilizarea unui încărcător de șabloane în cache pentru Django. Acesta pune în cache șabloanele analizate și evită necesitatea de a face analiza la fiecare cerere. Îl puteți configura folosind următorul fragment (setarea loaders este importantă aici):

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

Executarea sarcinilor de întreținere

Pentru o performanță optimă, este o idee bună să executați unele sarcini de întreținere în fundal. Acest lucru este acum făcut automat de Sarcini de fundal folosind Celery și acoperă următoarele sarcini:

  • Verificarea stării de sănătate a configurației (din oră în oră).

  • Angajarea modificărilor în așteptare (din oră în oră), a se vedea Angajări leneșe și commit_pending.

  • Actualizarea alertelor privind componentele (zilnic).

  • Actualizarea ramurilor la distanță (noaptea), vezi AUTO_UPDATE.

  • Copie de rezervă a memoriei de traducere în JSON (zilnic), a se vedea dump_memory.

  • Sarcini de întreținere a textului complet și a bazei de date (sarcini zilnice și săptămânale), a se vedea cleanuptrans.

Schimbat în versiunea 3.2: Începând cu versiunea 3.2, modalitatea implicită de executare a acestor sarcini este utilizarea Celery, iar Weblate vine deja cu o configurație corespunzătoare, vezi Sarcini de fundal folosind Celery.

Locațiile și codificarea sistemului

Locațiile de sistem trebuie configurate cu cele care acceptă UTF-8. Pe majoritatea distribuțiilor Linux, aceasta este setarea implicită. În cazul în care nu este cazul în sistemul dumneavoastră, vă rugăm să schimbați localele în varianta UTF-8.

De exemplu, prin editarea /etc/default/locale și setarea acolo LANG="C.UTF-8".

În unele cazuri, serviciile individuale au o configurație separată pentru localități. Acest lucru variază în funcție de distribuție și de serverele web, așa că verifică documentația pachetelor serverului tău web.

Apache pe Ubuntu utilizează /etc/apache2/envvvars:

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

Apache pe CentOS utilizează /etc/sysconfig/httpd (sau /opt/rh/httpd24/root/etc/sysconfig/httpd):

LANG='en_US.UTF-8'

Utilizarea autorității de certificare personalizate

Weblate verifică certificatele SSL în timpul solicitărilor HTTP. În cazul în care utilizați o autoritate de certificare personalizată care nu este de încredere în pachetele implicite, va trebui să adăugați certificatul său ca fiind de încredere.

Abordarea preferată este de a face acest lucru la nivel de sistem, vă rugăm să verificați documentația distribuției dumneavoastră pentru mai multe detalii (de exemplu, pe debian, acest lucru se poate face prin plasarea certificatului CA în /usr/local/share/ca-certificates/ și rularea update-ca-certificates).

Odată ce acest lucru este făcut, instrumentele de sistem vor avea încredere în certificat, inclusiv Git.

Pentru codul Python, va trebui să configurați cererile pentru a utiliza pachetul CA de sistem în loc de cel livrat împreună cu acesta. Acest lucru poate fi realizat prin plasarea următorului fragment în settings.py (calea este specifică Debian):

import os

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

Comprimarea activelor clienților

Weblate vine cu o mulțime de fișiere JavaScript și CSS. Din motive de performanță, este bine să le comprimați înainte de a le trimite către un client. În configurația implicită, acest lucru se face din mers, cu un mic cost suplimentar. În cazul instalațiilor mari, se recomandă activarea modului de compresie offline. Acest lucru trebuie făcut în configurație, iar compresia trebuie să fie declanșată la fiecare actualizare Weblate.

Comutarea configurației este simplă prin activarea django.conf.settings.COMPRESS_OFFLINE și prin configurarea django.conf.settings.COMPRESS_OFFLINE_CONTEXT (aceasta din urmă este deja inclusă în configurația de exemplu):

COMPRESS_OFFLINE = True

La fiecare implementare trebuie să comprimați fișierele pentru a se potrivi cu versiunea curentă:

weblate compress

Sugestie

Imaginea oficială Docker are această funcție deja activată.

Rularea serverului

Sugestie

În cazul în care nu aveți experiență cu serviciile descrise mai jos, ați putea încerca Instalarea folosind Docker.

Veți avea nevoie de mai multe servicii pentru a rula Weblate, configurația recomandată constă în:

Notă

Există unele dependențe între servicii, de exemplu, memoria cache și baza de date trebuie să ruleze la pornirea proceselor Celery sau uwsgi.

În cele mai multe cazuri, veți rula toate serviciile pe un singur server (virtual), dar în cazul în care instalația dvs. este foarte încărcată, puteți împărți serviciile. Singura limitare în acest sens este că serverele Celery și Wsgi au nevoie de acces la DATA_DIR.

Notă

Procesul WSGI trebuie să fie executat sub același utilizator ca și procesul Celery, în caz contrar fișierele din DATA_DIR vor fi stocate cu proprietate mixtă, ceea ce duce la probleme în timpul execuției.

A se vedea Permisiunile sistemului de fișiere și Sarcini de fundal folosind Celery.

Rularea serverului web

Rularea Weblate nu este diferită de rularea oricărui alt program bazat pe Django. Acesta este de obicei executat ca uWSGI sau fcgi (a se vedea mai jos exemple pentru diferite servere web).

În scopuri de testare, puteți utiliza serverul web încorporat în Django:

weblate runserver

Atenționare

NU FOLOSIȚI ACEST SERVER ÎNTR-UN MEDIU DE PRODUCȚIE. Acesta nu a fost supus unor audituri de securitate sau teste de performanță. Consultați, de asemenea, documentația Django privind runserver.

Sugestie

Serverul încorporat Django servește fișiere statice doar cu DEBUG activat, deoarece este destinat doar pentru dezvoltare. Pentru utilizarea în producție, vă rugăm să consultați configurările wsgi în Exemplu de configurare pentru NGINX și uWSGI, Exemplu de configurare pentru Apache, Exemplu de configurare pentru Apache și Gunicorn și Servirea fișierelor statice.

Servirea fișierelor statice

Schimbat în versiunea 2.4: Înainte de versiunea 2.4, Weblate nu folosea în mod corespunzător cadrul de fișiere statice Django, iar configurarea era mai complexă.

Django trebuie să adune fișierele statice într-un singur director. Pentru a face acest lucru, executați weblate collectstatic --noinput. Aceasta va copia fișierele statice într-un director specificat de setarea STATIC_ROOT (acesta este implicit un director static în interiorul DATA_DIR).

Se recomandă să serviți fișiere statice direct de pe serverul dvs. web, ar trebui să folosiți acest lucru pentru următoarele căi:

:fișier:`/static/`

Servește fișiere statice pentru Weblate și interfața de administrare (din cele definite de STATIC_ROOT).

:fișier:`/media/`

Utilizat pentru încărcarea de conținut media de către utilizator (de exemplu, capturi de ecran).

:fișier:`/favicon.ico`

Ar trebui să fie rescrisă pentru a rescrie o regulă pentru a servi /static/favicon.ico.

Politica de securitate a conținutului

Configurația implicită Weblate activează middleware-ul weblate.middleware.SecurityMiddleware care stabilește antetele HTTP legate de securitate, cum ar fi Content-Security-Policy sau X-XSS-Protection. Acestea sunt setate în mod implicit pentru a funcționa cu Weblate și cu configurația sa, dar s-ar putea să fie nevoie de o personalizare pentru mediul dumneavoastră.

Exemplu de configurare pentru NGINX și uWSGI

Pentru a rula serverul web de producție, utilizați învelișul wsgi instalat împreună cu Weblate (în cazul mediului virtual, acesta este instalat ca ~/weblate-env/lib/python3.7/site-packages/weblate/wsgi.py). Nu uitați să setați și calea de căutare Python în mediul virtual (de exemplu, folosind virtualenv = /home/user/weblate-env în uWSGI).

Următoarea configurație rulează Weblate ca uWSGI sub serverul web NGINX.

Configurație pentru NGINX (disponibilă și sub forma 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;
    }
}

Configurație pentru uWSGI (disponibilă și sub forma 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.9/site-packages/weblate/wsgi.py

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

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

# Needed for OAuth/OpenID
buffer-size   = 8192

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

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

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

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

# Avoid default 0000 umask
umask = 0022

# Run as weblate user
uid = weblate
gid = weblate

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

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

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

Exemplu de configurare pentru Apache

Se recomandă utilizarea prefork MPM atunci când se utilizează WSGI cu Weblate.

Următoarea configurație rulează Weblate ca WSGI, trebuie să aveți activat mod_wsgi (disponibil ca 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 user=weblate
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

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

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

</VirtualHost>

Notă

Weblate necesită Python 3, așa că asigurați-vă că rulați varianta Python 3 a modwsgi. De obicei, acesta este disponibil ca un pachet separat, de exemplu libapache2-mod-wsgi-py3.

Exemplu de configurare pentru Apache și Gunicorn

Următoarea configurație rulează Weblate în Gunicorn și Apache 2.4 (disponibilă ca 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>

Rularea Weblate sub calea de acces

Nou în versiunea 1.3.

Se recomandă utilizarea prefork MPM atunci când se utilizează WSGI cu Weblate.

Un exemplu de configurare Apache pentru a servi Weblate sub /weblate. Din nou, folosind mod_wsgi (disponibil și ca 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 user=weblate
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

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

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

</VirtualHost>

În plus, va trebui să ajustați weblate/settings.py:

URL_PREFIX = "/weblate"

Sarcini de fundal folosind Celery

Nou în versiunea 3.2.

Weblate uses Celery to execute regular and background tasks. You are supposed to run a Celery service that will execute these. For example, it is responsible for handling following operations (this list is not complete):

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

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

Vezi și

Configurarea brokerului Redis în Celery <celery:broker-redis-configuration>`

De asemenea, ar trebui să porniți lucrătorul Celery pentru a procesa sarcinile și pentru a porni sarcinile programate; acest lucru poate fi făcut direct din linia de comandă (ceea ce este util mai ales atunci când depanați sau dezvoltați):

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

Notă

Procesul Celery trebuie să fie executat sub același utilizator ca și procesul WSGI, în caz contrar fișierele din DATA_DIR vor fi stocate cu proprietate mixtă, ceea ce duce la probleme în timpul execuției.

A se vedea Permisiunile sistemului de fișiere și Rularea serverului.

Executing Celery tasks in the wsgi using eager mode

Notă

This will have severe performance impact on the web interface, and will break features depending on regullar trigger (for example commiting pending changes, digest notifications, or backups).

For development, you might want to use eager configuration, which does process all tasks in place:

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

Rularea Celery ca serviciu de sistem

Cel mai probabil, veți dori să rulați Celery ca demon, iar acest lucru este acoperit de Daemonization. Pentru cea mai obișnuită configurație Linux care utilizează systemd, puteți utiliza fișierele de exemplu livrate în dosarul examples listat mai jos.

Unitatea Systemd va fi plasată ca /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

Configurația de mediu care urmează să fie plasată ca /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="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

Configurație suplimentară pentru a roti jurnalele Celery folosind logrotate pentru a fi plasată ca /etc/logrotate.d/celery:

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

Sarcini periodice folosind Celery beat

Weblate vine cu o configurare integrată pentru sarcini programate. Cu toate acestea, puteți defini sarcini suplimentare în settings.py, de exemplu, consultați Angajări leneșe.

Sarcinile ar trebui să fie executate de demonul Celery beats. În cazul în care acesta nu funcționează corect, este posibil să nu fie în funcțiune sau baza sa de date a fost coruptă. În acest caz, verificați jurnalele de pornire Celery pentru a afla cauza principală.

Monitorizarea stării Celery

Puteți utiliza celery_queues pentru a vedea lungimea curentă a cozilor de sarcini Celery. În cazul în care coada de așteptare va deveni prea lungă, veți primi și o eroare de configurare în interfața de administrare.

Atenționare

În mod implicit, erorile Celery sunt înregistrate doar în jurnalul Celery și nu sunt vizibile pentru utilizator. În cazul în care doriți să aveți o imagine de ansamblu asupra acestor eșecuri, se recomandă să configurați Colectarea rapoartelor de eroare.

Monitorizarea Weblate

Weblate oferă URL-ul /healthz/ pentru a fi utilizat în verificări simple ale stării de sănătate, de exemplu, folosind Kubernetes. Containerul Docker are încorporată o verificare a stării de sănătate folosind acest URL.

Pentru monitorizarea metricilor Weblate puteți utiliza punctul final API GET /api/metrics/.

Colectarea rapoartelor de eroare

Weblate, ca orice alt software, poate da greș. Pentru a colecta stări de eșec utile, vă recomandăm să utilizați servicii terțe pentru a colecta astfel de informații. Acest lucru este util mai ales în cazul sarcinilor Celery care eșuează, care altfel ar raporta erori doar în jurnale și nu veți fi notificat cu privire la acestea. Weblate are suport pentru următoarele servicii:

Santinela

Weblate are suport încorporat pentru Sentry. Pentru a-l utiliza, este suficient să setați SENTRY_DSN în settings.py:

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

Rollabil

Weblate are suport încorporat pentru Rollbar. Pentru a-l utiliza, este suficient să urmați instrucțiunile pentru Rollbar notifier for Python.

Pe scurt, trebuie să ajustați settings.py:

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

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

Restul este integrat automat, iar acum veți colecta atât erorile de pe server, cât și cele de pe partea clientului.

Migrarea Weblate pe un alt server

Migrarea Weblate pe un alt server ar trebui să fie destul de ușoară, însă acesta stochează date în câteva locații pe care trebuie să le migrați cu atenție. Cea mai bună abordare este să opriți Weblate pentru migrare.

Migrarea bazei de date

În funcție de backend-ul bazei de date, este posibil să aveți mai multe opțiuni pentru a migra baza de date. Cea mai simplă este să descărcați baza de date de pe un server și să o importați pe cel nou. Alternativ, puteți utiliza replicarea în cazul în care baza de date o acceptă.

Cea mai bună abordare este de a utiliza instrumentele native ale bazei de date, deoarece acestea sunt de obicei cele mai eficiente (de exemplu, mysqldump sau pg_dump). Dacă doriți să migrați între baze de date diferite, singura opțiune ar putea fi să folosiți managementul Django pentru a descărca și importa baza de date:

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

Migrarea depozitelor VCS

Depozitele VCS stocate în DATA_DIR trebuie, de asemenea, să fie migrate. Puteți să le copiați pur și simplu sau să folosiți rsync pentru a face migrarea mai eficient.

Alte note

Nu uitați să mutați și alte servicii pe care Weblate le-ar fi putut folosi, cum ar fi Redis, Cron jobs sau backend-uri de autentificare personalizate.