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ă:

Architecture overview

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

Web server

Handling incoming HTTP requests, Servirea fișierelor statice.

Celery workers

Sarcini de fundal folosind Celery are executed here.

Depending on your workload, you might want to customize the number of workers.

Use dedicated node when scaling Weblate horizontally.

WSGI server

A WSGI server serving web pages to users.

Use dedicated node when scaling Weblate horizontally.

Baza de date

PostgreSQL database server for storing all the content, see Configurarea bazei de date pentru Weblate.

Use dedicated database node for sites with hundreds of millions of hosted words.

Redis

Server Redis pentru cache și coada de sarcini, vezi Sarcini de fundal folosind Celery.

Use dedicated node when scaling Weblate horizontally.

File system

File system storage for storing VCS repositories and uploaded user data. This is shared by all the processes.

Use networked storage when scaling Weblate horizontally.

E-mail server

SMTP server for outgoing e-mail, see Configurarea e-mailului de ieșire. It can be provided externally.

Sugestie

Instalarea folosind Docker includes PostgreSQL and Redis, making the installation easier.

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.

Vezi și

Architecture overview describes overall Weblate architecture and required services.

Dependențe Python

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

Cele mai notabile dependențe:

Django

https://www.djangoproject.com/

Celery

https://docs.celeryq.dev/

Traducere Toolkit

https://toolkit.translatehouse.org/

traducător-detector

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

Python Social Auth

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

Cadrul Django REST

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

Atunci când instalați folosind pip, puteți specifica direct caracteristicile dorite la instalare:

pip install "Weblate[Postgres,Amazon,SAML]"

Sau puteți instala Weblate cu toate funcțiile opționale:

pip install "Weblate[all]"

Sau puteți instala Weblate fără nicio funcție opțională:

pip install Weblate

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 GObject

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 (needed only if tesserocr binary wheels are not available for your system)

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

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.

Cerințe hardware

Weblate should run on any contemporary hardware without problems, the following is the minimal configuration required to run Weblate on a single host (Weblate, database and web server):

  • 3 GB of RAM

  • 2 nuclee CPU

  • 1 GB de spațiu de stocare

Notă

Cerințele reale pentru instalarea Weblate variază foarte mult în funcție de dimensiunea traducerilor gestionate în cadrul acesteia.

Memory usage

The more memory the better - it is used for caching on all levels (file system, database and Weblate). For hundreds of translation components, at least 4 GB of RAM is recommended.

Sugestie

For systems with less memory than recommended, Single-process Celery setup is recommended.

CPU usage

Many concurrent users increase the amount of needed CPU cores.

Storage usage

The typical database storage usage is around 300 MB per 1 million hosted words.

Storage space needed for cloned repositories varies, but Weblate tries to keep their size minimal by doing shallow clones.

Nodes

For small and medium-sized sites (millions of hosted words), all Weblate components (see Architecture overview) can be run on a single node.

When you grow to hundreds of millions of hosted words, it is recommended to have a dedicated node for database (see Configurarea bazei de date pentru Weblate).

Verificarea semnăturilor de eliberare

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

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

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

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 12 and higher is supported. PostgreSQL 15 or newer is recommended.

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

Notă

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

Database connections

In the default configuration, each Weblate process keeps a persistent connection to the database. Persistent connections improve Weblate responsiveness, but might require more resources for the database server. Please consult CONN_MAX_AGE and Persistent connections for more info.

Weblate needs at least the following number of connections:

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

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

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

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

  • Comenzi de gestionare need their connection as well.

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

PostgreSQL

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

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": "",
        # Persistent connections
        "CONN_MAX_AGE": None,
        "CONN_HEALTH_CHECKS": True,
    }
}

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

Atenționare

While MySQL and MariaDB support is still maintained in Weblate, our primary focus is PostgreSQL. It is recommended to use PostgreSQL for new installs, and to migrate existing installs to PostgreSQL, see Migrarea de la alte baze de date la PostgreSQL.

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 requires MySQL at least 8 or MariaDB at least 10.4.

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.

Un alt lucru de care trebuie să aveți grijă este antetul Host. Acesta ar trebui să corespundă cu ceea ce este configurat ca SITE_DOMAIN. Ar putea fi necesară o configurare suplimentară în proxy-ul invers (de exemplu, utilizați ProxyPreserveHost On pentru Apache sau proxy_set_header Host $host; cu nginx).

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.

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

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

After your configuration is ready, you can run migrate to create the database structure. Now you should be able to create translation projects using the admin interface.

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.webp

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

You can also review the very same checklist at Raport de performanță in the 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-generate-secret-key livrat cu Weblate.

Executarea sarcinilor de întreținere

For optimal performance, it is good idea to run some maintenance tasks in the background. This is automatically done by Sarcini de fundal folosind Celery and covers following tasks:

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

  • Committing pending changes (hourly), see Angajări leneșe and commit_pending.

  • Actualizarea alertelor privind componentele (zilnic).

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

  • Translation memory backup to JSON (daily), see dump_memory.

  • Fulltext and database maintenance tasks (daily and weekly tasks), see cleanuptrans.

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

The Django built-in server serves static files only with DEBUG enabled as it is intended for development only. For production use, please see WSGI setups in Exemplu de configurare pentru NGINX și uWSGI, Exemplu de configurare pentru Apache, Exemplu de configurare pentru Apache și Gunicorn, and Servirea fișierelor statice.

Servirea fișierelor statice

Django needs to collect its static files in a single directory. To do so, execute weblate collectstatic --noinput. This will copy the static files into a directory specified by the STATIC_ROOT setting (this defaults to a static directory inside CACHE_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/`

Serves static files for Weblate and the admin interface (from defined by 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

To run production webserver, use the WSGI wrapper installed with Weblate (in virtual env case it is installed as ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py). Don’t forget to set the Python search path to your virtualenv as well (for example using virtualenv = /home/user/weblate-env in 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):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

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

    location /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):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py

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

# 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
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

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

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

    # 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 request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

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

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

</VirtualHost>

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.

Use matching Python version to install Weblate.

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
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

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

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

    # 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

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):

# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later

#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

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

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

    # 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 request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

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

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

</VirtualHost>

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

URL_PREFIX = "/weblate"

Sarcini de fundal folosind Celery

Weblate utilizează Celery pentru a executa sarcini regulate și de fundal. Se presupune că trebuie să rulați un serviciu Celery care să le execute. De exemplu, acesta este responsabil pentru gestionarea următoarelor operațiuni (această listă nu este completă):

O configurație tipică care utilizează Redis ca backend arată astfel:

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ă

Acest lucru va avea un impact sever asupra performanțelor interfeței web și va întrerupe caracteristicile care depind de declanșarea regulată (de exemplu, comiterea modificărilor în așteptare, notificările Digest sau copiile de rezervă).

Pentru dezvoltare, este posibil să doriți să utilizați configurația eager, care procesează toate sarcinile pe loc:

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 concurrency 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:

# Copyright © Michal Čihař <michal@weblate.org>
#
# SPDX-License-Identifier: GPL-3.0-or-later

/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

You can find current length of the Celery task queues in the Interfața de gestionare or you can use celery_queues on the command-line. In case the queue will get too long, you will also get configuration error in the admin interface.

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 Collecting error reports and monitoring performance.

Single-process Celery setup

In case you have very limited memory, you might want to reduce number of Weblate processes. All Celery tasks can be executed in a single process using:

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

Atenționare

This will have a noticeable performance impact on Weblate.

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/.

Collecting error reports and monitoring performance

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:

Sentry

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/"

Sentry can be also used to monitor performance of Weblate by collecting traces and profiles for defined percentage of operations. This can be configured using SENTRY_TRACES_SAMPLE_RATE and SENTRY_PROFILES_SAMPLE_RATE.

Rollbar

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.

Notă

Error logging also includes exceptions that were gracefully handled, but might indicate a problem - such as failed parsing of an uploaded file.

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

Depending on your database backend, you might have several options to migrate the database. The most straightforward approach is to use database native tools, as they are usually the most effective (e.g. mysqldump or pg_dump). Alternatively you can use replication in case your database supports it.

Vezi și

Migrating between databases described in Migrarea de la alte baze de date la PostgreSQL.

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.