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ă:
Instalarea folosind Docker, recomandat pentru configurațiile de producție.
Instalarea Virtualenv, recomandată pentru configurațiile de producție:
Instalarea din surse, recomandat pentru dezvoltare.
Architecture overview¶
- Server web
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.
- Datastore
Key/value datastore such as Valkey or Redis server for cache and tasks queue, see 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 Valkey, 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.12 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
- Țelină
- Translate Toolkit
- traducător-detector
- Python Social Auth
- Cadrul Django REST
Optional dependency specifier |
Python packages |
Weblate feature |
|---|---|---|
|
||
|
||
|
||
|
Google Cloud Translation Advanced with glossary support |
|
|
||
|
||
|
PostgreSQL, see Configurarea bazei de date pentru Weblate |
|
|
||
|
||
|
Integrating SAML 2 IDP into Weblate |
|
|
Needed for Update POT file (Sphinx) |
|
|
Hosted Weblate integration |
|
|
wsgi server for Weblate |
|
|
Atunci când instalați folosind pip, puteți specifica direct caracteristicile dorite la instalare:
uv pip install "weblate[Postgres,Amazon,SAML]"
Sau puteți instala Weblate cu toate funcțiile opționale:
uv pip install "weblate[all]"
Sau puteți instala Weblate fără nicio funcție opțională:
uv pip install weblate
Troubleshooting pip install¶
ERROR: Dependency 'gobject-introspection-2.0' is required but not found.The installed
PyGobjectpackage cannot find a matching GObject Introspection library -gobject-introspection-2.0.Older versions are no longer supported by Weblate.
ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)Acest lucru este cauzat de incompatibilitatea pachetelor binare distribuite prin PyPI cu distribuția. Pentru a rezolva acest lucru, trebuie să reconstruiți pachetul pe sistemul dumneavoastră:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?This is a known issue of the xmlsec package, please see https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchThe
lxmlandxmlsecpackages have to be built against onelibxml2. You should build them locally to avoid this issue:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
Alte cerințe de sistem¶
Următoarele dependențe trebuie să fie instalate pe sistem:
Git- Pango, Cairo și fișierele antet aferente și datele de introspecție GObject
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, see Pango și Cairo
git-review(opțional pentru suport Gerrit)git-svn(opțional pentru suport pentru Subversion)tesseract(needed only if tesserocr binary wheels are not available for your system)
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 Building the translation community) ș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.
The configured CACHE_DIR also has to be writable by the Weblate
process and has to allow executing generated helper files. Do not mount
CACHE_DIR with the noexec option.
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).
Vezi și
Configurarea bazei de date pentru Weblate¶
Se recomandă ca Weblate să ruleze cu un server de baze de date PostgreSQL.
PostgreSQL 13 and higher is supported. PostgreSQL 15 or newer is recommended.
Vezi și
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
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",
# Configures name of the PostgreSQL role to alter during the database migration
# "ALTER_ROLE": "weblate",
# Database password
"PASSWORD": "password",
# Set to empty string for localhost
"HOST": "database.example.com",
# Set to empty string for default
"PORT": "",
# Persistent connections
"CONN_MAX_AGE": None,
"CONN_HEALTH_CHECKS": True,
}
}
The database migration performs ALTER ROLE on the database role used
by Weblate. In most cases, the name of the role matches the username. In more
complex setups the role name is different from the username, and you will get an error
about non-existing role during the database migration
(psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist).
This is known to happen with Azure Database for PostgreSQL, but it’s not
limited to this environment. Please set ALTER_ROLE to change the name of the
role Weblate should alter during the database migration.
Vezi și
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
In case you get error about not supported authentication (for example
SMTP AUTH extension not supported by server), it is most likely caused
by using insecure connection and server refuses to authenticate this way.
Try enabling EMAIL_USE_TLS in such case.
Rularea în spatele unui proxy invers¶
Several features in Weblate rely on correct HTTP headers being passed to Weblate. When using reverse proxy, please make sure that the needed information is correctly passed.
To debug this configuration, you can look at HTTP environment in Raport de performanță.
- Client IP address
This is needed for Limitarea ratei or Jurnal de audit.
Weblate parses IP address from the
REMOTE_ADDR, which is set by the WSGI handler. This might be empty (when using socket for WSGI) or contain a reverse proxy address, so Weblate needs an additional HTTP header with a client IP address.Enabling
IP_BEHIND_REVERSE_PROXYshould be sufficient for the most usual setups, but you might need to adjustIP_PROXY_HEADERandIP_PROXY_OFFSETas well (useWEBLATE_IP_PROXY_HEADERandWEBLATE_IP_PROXY_OFFSETin the Docker container).Sugestie
This configuration cannot be turned on by default, because it would allow IP address spoofing on installations that don’t have a properly configured reverse proxy.
- Server host name
The Host header should match to whatever is configured as
SITE_DOMAIN. Additional configuration might be needed in your reverse proxy (for example useProxyPreserveHost Onfor Apache orproxy_set_header Host $host;with nginx).Sugestie
CSRF verification failed errors are often caused by a mismatch between the Host header and configured
SITE_DOMAIN.- Client protocol
Not passing correct protocol may cause Weblate to end up in redirection loop trying to upgrade client to HTTPS. Make sure it is correctly exposed by the reverse proxy as X-Forwarded-Proto.
This header then needs to be configured in
SECURE_PROXY_SSL_HEADER(settings.py) orWEBLATE_SECURE_PROXY_SSL_HEADER(Docker environment).Important
The header value is case-sensitive in the configuration, so
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsandWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSare not interchangeable.Sugestie
If you are getting a „Too many redirects” error from the browser, this is most likely caused by mismatch between the actual protocol (HTTPS) and what is observed by Weblate.
Schimbat în versiunea 5.13: The protocol proxy headers are automatically handled by gunicorn in the default configuration, but other WSGI servers have more secure configuration and require explicit setting of this.
Since Weblate 5.13 the Docker container is using granian and it now requires the explicit configuration of
WEBLATE_SECURE_PROXY_SSL_HEADER.
Vezi și
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"
Vezi și
Ajustarea configurației¶
Vezi și
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_CONTACTis 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.
If you are using Valkey or Redis as cache (see Configure cache) it is recommended to use it for sessions as well:
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.
Vezi și
DEFAULT_FROM_EMAIL
Adresa de e-mail a expeditorului pentru e-mailurile de ieșire, de exemplu e-mailurile de înregistrare.
Vezi și
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
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
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ă.
Vezi și
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:
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.
Vezi și
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.
Vezi și
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>",)
Vezi și
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.
Configure cache¶
If possible, use Valkey or Redis from Django by adjusting the CACHES
configuration variable, for example:
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
In case you change settings for the cache, you might need to adjust them for Celery as well, see 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'. You may need to add '1.1.1.1' to 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.
Vezi și
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/envvars:
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'
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:
Server de baze de date (vezi Configurarea bazei de date pentru Weblate)
Server cache (vezi Configure cache)
Server web frontend pentru fișiere statice și terminarea SSL (vezi Servirea fișierelor statice)
Server WSGI pentru conținut dinamic (vezi Exemplu de configurare pentru NGINX și uWSGI)
Celery pentru executarea de sarcini de fundal (vezi Sarcini de fundal folosind Celery)
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¶
Running Weblate is not different from running any other Django based program. Django is usually executed as WSGI or fcgi (see examples for different webservers below).
Notă
The sample configuration files shown below are maintained in the Weblate
source tree under weblate/examples/. They are included in source
distributions and in this documentation, but Python wheels only install
runtime files. When installing Weblate from PyPI, get the matching source
distribution or source checkout before copying these examples.
Î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:
Servirea fișierelor statice¶
Schimbat în versiunea 5.15.2: /media/ is no longer used for serving screenshots.
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:
/static/Serves static files for Weblate and the admin interface (from defined by
STATIC_ROOT)./favicon.icoAr trebui să fie rescrisă pentru a rescrie o regulă pentru a servi
/static/favicon.ico.
Vezi și
Politica de securitate a conținutului¶
The default Weblate configuration enables weblate.middleware.SecurityMiddleware
middleware which sets security related HTTP headers like Content-Security-Policy
or X-XSS-Protection. These are by default set up to work with Weblate and its
configuration, but this might need customization for your environment.
Sample configuration for NGINX and Granian¶
The following configuration runs Weblate using Granian the NGINX webserver:
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://127.0.0.1:8888;
proxy_read_timeout 3600;
}
}
Sample configuration for NGINX and Gunicorn¶
The following configuration runs Weblate using Gunicorn under the NGINX webserver
(weblate/examples/weblate.nginx.gunicorn.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_pass http://unix:/run/gunicorn.sock;
proxy_read_timeout 3600;
}
}
Exemplu de configurare pentru NGINX și uWSGI¶
To run production webserver, use the WSGI wrapper installed with Weblate (when
using a Python environment it is installed as
~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). Don’t
forget to set the Python search path to your Python environment as well (for
example using virtualenv = /home/user/weblate-env in uWSGI).
Următoarea configurație rulează Weblate ca uWSGI sub serverul web NGINX.
Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
server {
listen 80;
server_name weblate;
# Not used
root /var/www/html;
location ~ ^/favicon.ico$ {
# CACHE_DIR/static/favicon.ico
alias /home/weblate/data/cache/static/favicon.ico;
expires 30d;
}
location /static/ {
# CACHE_DIR/static/
alias /home/weblate/data/cache/static/;
expires 30d;
}
location / {
include uwsgi_params;
# Needed for long running operations in admin interface
uwsgi_read_timeout 3600;
# Adjust based to uwsgi configuration:
uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
# uwsgi_pass 127.0.0.1:8080;
}
}
Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):
#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins = python3
master = true
protocol = uwsgi
socket = 127.0.0.1:8080
wsgi-file = /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py
# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path = /path/to/weblate
# Path to the Python environment
virtualenv = /home/weblate/weblate-env
# Needed for OAuth/OpenID
buffer-size = 8192
# Reload when consuming too much of memory
reload-on-rss = 250
# Increase number of workers for heavily loaded sites
workers = 8
# Enable threads for Sentry error submission
enable-threads = true
# Child processes do not need file descriptors
close-on-exec = true
# Avoid default 0000 umask
umask = 0022
# Run as weblate user
uid = weblate
gid = weblate
# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true
# Enable uWSGI stats server
# stats = :1717
# stats-http = true
# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true
Vezi și
Exemplu de configurare pentru Apache¶
Se recomandă utilizarea prefork MPM atunci când se utilizează WSGI cu Weblate.
The following configuration runs Weblate as WSGI, you need to have enabled
mod_wsgi (weblate/examples/apache.conf in the source tree):
#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
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¶
The following configuration runs Weblate in Gunicorn and Apache 2.4
(weblate/examples/apache.gunicorn.conf in the source tree):
#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/https_cert.cert
SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
SSLProxyEngine On
ProxyPass /favicon.ico !
ProxyPass /static/ !
ProxyPass / http://localhost:8000/
ProxyPassReverse / http://localhost:8000/
ProxyPreserveHost On
</VirtualHost>
Sample configuration to start Granian¶
Weblate has wsgi optional dependency (see Dependențe Python) that will install everything you need to run Granian. When installing Weblate you can specify it as:
uv pip install Weblate[all,wsgi]
Once you have Granian installed, you can run it. This is usually done at the system level. The following examples show starting via systemd:
[Unit]
Description=granian daemon
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
--no-ws \
--workers-max-rss 350 \
--interface wsgi \
--workers 2 \
--backpressure 16 \
--runtime-threads 8 \
--runtime-mode mt \
--port 8888 \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
~
Sample configuration to start Gunicorn¶
Gunicorn has to be installed separately:
uv pip install gunicorn
Once you have Gunicorn installed, you can run it. This is usually done at the system level. The following examples show starting via systemd:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
--preload \
--timeout 3600 \
--graceful-timeout 3600 \
--worker-class=gthread \
--workers=2 \
--threads=16 \
--bind unix:/run/gunicorn.sock \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
Vezi și
Rularea Weblate sub calea de acces¶
Se recomandă utilizarea prefork MPM atunci când se utilizează WSGI cu Weblate.
A sample Apache configuration to serve Weblate under /weblate. Again using
mod_wsgi (weblate/examples/apache-path.conf in the source tree):
#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 to match Python version mod-wsgi is compiled for
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
ServerAdmin admin@weblate.example.org
ServerName weblate.example.org
# CACHE_DIR/static/favicon.ico
Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico
# CACHE_DIR/static/
Alias /weblate/static/ /home/weblate/data/cache/static/
<Directory /home/weblate/data/cache/static/>
Require all granted
</Directory>
# Path to your Weblate Python environment
WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
WSGIProcessGroup weblate
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/wsgi.py process-group=weblate
WSGIPassAuthorization On
<Directory /home/weblate/weblate-env/lib/python3.12/site-packages/weblate/>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
</VirtualHost>
Î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ă):
Primirea de webhooks de la servicii externe (a se vedea Cârlige notificare).
Executarea sarcinilor de întreținere regulate, cum ar fi copii de rezervă, curățări, adăugări zilnice sau actualizări (a se vedea Copierea de rezervă și mutarea Weblate,
BACKGROUND_TASKS, Suplimente).Rulează Traducere automată.
Trimiterea de notificări de sinteză.
Offloading expensive operations from the WSGI process.
Angajarea modificărilor în așteptare (a se vedea Angajări leneșe).
A typical setup using Valkey or Redis as a backend looks like this:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup
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¶
Most likely you will want to run Celery as a daemon and that is covered by
Daemonization. For the most common Linux setup using
systemd, adapt the example files listed below. These examples are maintained in
the Weblate source tree under weblate/examples/; Python wheels do not
install these deployment samples.
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. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
--queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
--queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
--queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
--queues:backup=backup --concurrency:backup=1 --prefetch-multiplier:backup=2"
# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
# and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"
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 comes with built-in setup for scheduled tasks. The task schedule is stored in the database and tasks are executed by the Celery beat daemon.
Sugestie
You can define additional tasks in settings.py, for example see
Angajări leneșe.
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
An installation using Docker can be configured to use a single-process Celery setup by setting CELERY_SINGLE_PROCESS.
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:
Email¶
The default Weblate configuration instruments Django to send e-mails upon
server errors via django.utils.log.AdminEmailHandler. This
is the least effort setup, but you should consider other options for privacy
reasons, as the error e-mails might include sensitive data. You can read more on
that in Security implications.
To disable this behavior, remove mail_admins from the
LOGGING in Weblate settings, or disable
WEBLATE_ADMIN_NOTIFY_ERROR in the Docker environment.
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",
"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.
Graylog log management¶
Added in version 5.9.
Weblate can be configured to log using the GELF TCP protocol. This was developed for Graylog integration, but can be used with any compliant logging platform.
The configuration boilerplate is included in Exemplu de configurare, for
Docker this can be configured using WEBLATE_LOG_GELF_HOST.
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¶
The most straightforward approach is to use database native tools, as they are usually the most effective (e.g. pg_dump). Alternatively you can use replication if 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¶
Don’t forget to move other services Weblate might have been using like Valkey, Redis, Cron jobs or custom authentication backends.