Instruccions de configuració¶
Installing Weblate¶
En funció de la vostra configuració i experiència, trieu un mètode d’instal·lació adequat per a vosaltres:
Instal·lació mitjançant Docker, recomanat per a configuracions de producció.
Instal·lació de Virtualenv, recomanada per a configuracions de producció:
Instal·lació des de fonts, recomanat per al desenvolupament.
Architecture overview¶
- Servidor web
Gestionar les sol·licituds HTTP entrants, Donant arxius estàtics.
- Celery workers
Tasques de fons amb api are executed here.
Depenent de la vostra càrrega de treball, és possible que vulgueu personalitzar el nombre de treballadors.
Utilitzeu el node dedicat quan escaleu Weblate horitzontalment.
- Application server
A WSGI or ASGI server serving web pages to users.
Utilitzeu el node dedicat quan escaleu Weblate horitzontalment.
- Database
Servidor de bases de dades PostgreSQL per emmagatzemar tot el contingut, vegeu Configuració de la base de dades per a Weblate.
Utilitzeu un node de base de dades dedicat per a llocs amb centenars de milions de paraules allotjades.
- Datastore
Magatzem de dades de clau/valor, com ara el servidor Valkey o Redis per a la memòria cau i la cua de tasques, vegeu Tasques de fons amb api.
Utilitzeu el node dedicat quan escaleu Weblate horitzontalment.
- File system
Emmagatzematge del sistema de fitxers per emmagatzemar repositoris VCS i dades d’usuari carregades. Això és compartit per tots els processos.
Utilitzeu l’emmagatzematge en xarxa quan escaleu Weblate horitzontalment.
- E-mail server
Servidor SMTP per a correu electrònic de sortida, vegeu Configuració del correu electrònic de sortida. Es pot proporcionar externament.
Suggeriment
Instal·lació mitjançant Docker inclou PostgreSQL i Valkey, la qual cosa facilita la instal·lació.
Requisits de programari¶
Sistema operatiu¶
Se sap que Weblate funciona a Linux, FreeBSD i macOS. Molt probablement també funcionaran altres sistemes com Unix.
Weblate no és compatible amb Windows. Però encara pot funcionar i els pegats són acceptats amb molt de gust.
Vegeu també
Architecture overview describes overall Weblate architecture and required services.
Dependències de Python¶
Weblate està escrit en Python i és compatible amb Python 3.12 o posterior. Podeu instal·lar dependències mitjançant pip o des dels vostres paquets de distribució, la llista completa està disponible a requirements.txt.
Dependències més destacades:
- Django
- Celery
- Translate Toolkit
- translation-finder
- Python Social Auth
- Marc Django REST
Especificador de dependència opcional |
Python packages |
Weblate feature |
|---|---|---|
|
||
|
ASGI server for Weblate |
|
|
||
|
||
|
Google Cloud Translation Advanced with glossary support |
|
|
||
|
||
|
||
|
PostgreSQL, see Configuració de la base de dades per a Weblate |
|
|
||
|
||
|
Integrating SAML 2 IDP into Weblate |
|
|
Necessari per a Actualitza el fitxer POT (Sphinx) |
|
|
Hosted Weblate integration |
|
|
WSGI server for Weblate |
|
|
Quan instal·leu amb pip, podeu especificar directament les funcions desitjades quan instal·leu:
uv pip install "weblate[Postgres,Amazon,SAML]"
O podeu instal·lar Weblate amb totes les funcions opcionals:
uv pip install "weblate[all]"
O podeu instal·lar Weblate sense cap funció opcional:
uv pip install weblate
Resolució de problemes d’instal·lació de pip¶
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)Això és causat per la incompatibilitat dels paquets binaris distribuïts mitjançant PyPI amb la distribució. Per solucionar-ho, heu de reconstruir el paquet al vostre sistema:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?Aquest és un problema conegut del paquet xmlsec, consulteu https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchEls paquets
lxmlixmlsecs’han de construir contra unlibxml2. Hauríeu de crear-los localment per evitar aquest problema:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
Altres requisits del sistema¶
S’han d’instal·lar les dependències següents al sistema:
Gitgit-review(opcional per al suport de Gerrit)git-svn(opcional per al suport de Subversion)tesseract(només es necessita si les rodes binàries tesserocr no estan disponibles per al vostre sistema)
Dependències en temps de construcció¶
Per crear alguns dels Dependències de Python, potser haureu d’instal·lar les seves dependències. Això depèn de com els instal·leu, per tant, consulteu els paquets individuals per obtenir la documentació. No els necessitareu si feu servir Rodes preconstruïts mentre instal·leu amb pip o quan feu servir paquets de distribució.
Requisits de maquinari¶
Weblate s’ha d’executar en qualsevol maquinari contemporani sense problemes, la següent és la configuració mínima necessària per executar Weblate en un sol host (Weblate, base de dades i servidor web):
3 GB de RAM
2 nuclis de CPU
1 GB d’espai d’emmagatzematge
Nota
Els requisits reals per a la vostra instal·lació de Weblate varien molt en funció de la mida de les traduccions que hi gestionen.
Memory usage¶
Com més memòria millor: s’utilitza per a la memòria cau a tots els nivells (sistema de fitxers, base de dades i Weblate). Per a centenars de components de traducció, es recomana almenys 4 GB de RAM.
Suggeriment
Per als sistemes amb menys memòria de la recomanada, es recomana Configuració d’api d’un sol procés.
Ús de la CPU¶
Molts usuaris concurrents augmenten la quantitat de nuclis de CPU necessaris.
Storage usage¶
L’ús típic d’emmagatzematge de bases de dades és d’uns 300 MB per cada milió de paraules allotjades.
L’espai d’emmagatzematge necessari per als dipòsits clonats varia, però Weblate intenta mantenir la seva mida mínima fent clons poc profunds.
Nodes¶
For small and medium-sized sites (millions of hosted words), all Weblate components (see Architecture overview) can be run on a single node.
Quan arribeu a centenars de milions de paraules allotjades, es recomana tenir un node dedicat per a la base de dades (vegeu Configuració de la base de dades per a Weblate).
Verifying release artifacts¶
Release archives can be verified using the signatures, attestations, and SBOMs published with GitHub release assets. See Verifying release artifacts.
Permisos del sistema de fitxers¶
El procés de Weblate ha de poder llegir i escriure al directori on guarda les dades - DATA_DIR. Tots els fitxers d’aquest directori haurien de ser propietat de l’usuari que executa tots els processos de Weblate (normalment WSGI i Celery, vegeu Servidor en execució i Tasques de fons amb api).
La configuració predeterminada els situa al mateix arbre que les fonts del Weblate, però potser preferiu moure’ls a una ubicació millor com ara: /var/lib/weblate.
Weblate intenta crear aquests directoris automàticament, però fallarà quan no tingui permisos per fer-ho.
El CACHE_DIR configurat també s’ha de poder escriure pel procés Weblate i ha de permetre l’execució dels fitxers d’ajuda generats. No munteu CACHE_DIR amb l’opció noexec.
També hauríeu de tenir cura quan executeu Ordres de gestió, ja que s’haurien d’executar amb el mateix usuari que Weblate s’està executant, en cas contrari, els permisos d’alguns fitxers podrien estar equivocats.
Al contenidor de Docker, tots els fitxers del volum /app/data han de ser propietat de l’usuari weblate dins del contenidor (UID 1000).
Vegeu també
Configuració de la base de dades per a Weblate¶
Es recomana executar Weblate amb un servidor de bases de dades PostgreSQL.
PostgreSQL 13 and higher is supported. PostgreSQL 15 or newer is recommended.
Vegeu també
Database connections¶
En la configuració predeterminada, cada procés de Weblate manté una connexió persistent a la base de dades. Les connexions persistents milloren la capacitat de resposta de Weblate, però poden requerir més recursos per al servidor de bases de dades. Si us plau, consulteu CONN_MAX_AGE i Persistent connections per obtenir més informació.
Weblate necessita almenys el nombre següent de connexions:
\((4 \times \mathit{nCPUs}) + 2\) per als processos d’api
\(\mathit{nCPUs} + 1\) per als treballadors del WSGI
Això s’aplica als valors predeterminats dels contenidors de Docker i a les configuracions d’exemple proporcionades en aquesta documentació, però els números canviaran un cop personalitzeu la quantitat de treballadors WSGI o ajusteu el paral·lelisme de Celery.
The actual limit for the number of database connections needs to be higher to account for the following situations:
Ordres de gestió també necessiten la seva connexió.
If a process is killed (for example by OOM killer), it might block the existing connection until timeout.
PostgreSQL¶
PostgreSQL sol ser la millor opció per als llocs basats en Django. És la base de dades de referència utilitzada per implementar la capa de base de dades Django.
Nota
Weblate utilitza l’extensió trigrama que s’ha d’instal·lar per separat en alguns casos. Busqueu postgresql-contrib o un paquet amb un nom semblant.
Vegeu també
Creació d’una base de dades en PostgreSQL¶
Normalment és una bona idea executar Weblate en una base de dades independent i un compte d’usuari independent:
# 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
Suggeriment
Si no voleu que l’usuari de Weblate sigui un superusuari a PostgreSQL, podeu ometre-ho. En aquest cas, haureu de realitzar alguns dels passos de migració manualment, ja que un superusuari de PostgreSQL a l’esquema utilitzarà Weblate:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
CREATE EXTENSION IF NOT EXISTS btree_gist;
Configuració de Weblate per utilitzar PostgreSQL¶
El fragment settings.py per a 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,
}
}
La migració de la base de dades realitza ALTER ROLE a la funció de base de dades utilitzada per Weblate. En la majoria dels casos, el nom del rol coincideix amb el nom d’usuari. En configuracions més complexes, el nom del rol és diferent del nom d’usuari, i obtindreu un error sobre el rol inexistent durant la migració de la base de dades (psycopg2.errors.UndefinedObject: rol "weblate@hostname" does not exist). Se sap que això passa amb Azure Database per a PostgreSQL, però no es limita a aquest entorn. Si us plau, configureu ALTER_ROLE per canviar el nom del rol que Weblate hauria d’alterar durant la migració de la base de dades.
Vegeu també
Altres configuracions¶
Configuració del correu electrònic de sortida¶
Weblate envia correus electrònics en diverses ocasions: per a l’activació del compte i en diverses notificacions configurades pels usuaris. Per a això necessita accedir a un servidor SMTP.
The mail server setup is configured using these settings:
EMAIL_HOST, EMAIL_HOST_PASSWORD,
EMAIL_USE_TLS, EMAIL_USE_SSL,
EMAIL_HOST_USER and EMAIL_PORT. Their
names are quite self-explanatory, but you can find more info in the
Django documentation.
Suggeriment
En cas que rebeu un error sobre l’autenticació no compatible (per exemple L'extensió SMTP AUTH no és compatible amb el servidor), és probable que sigui causat per l’ús d’una connexió insegura i el servidor es nega a autenticar-se d’aquesta manera. Proveu d’activar EMAIL_USE_TLS en aquest cas.
Corrent darrere del proxy invers¶
Diverses funcions de Weblate depenen de les capçaleres HTTP correctes que es transmeten a Weblate. Quan utilitzeu el proxy invers, assegureu-vos que la informació necessària s’ha passat correctament.
Per depurar aquesta configuració, podeu mirar entorn HTTP a Informe de rendiment.
- Adreça IP del client
Això és necessari per a Limitació de tarifes o Registre d’auditoria.
Weblate analitza l’adreça IP des de
REMOTE_ADDR, que és establert pel controlador WSGI. Això pot estar buit (quan s’utilitza el sòcol per a WSGI) o contenir una adreça de proxy inversa, de manera que Weblate necessita una capçalera HTTP addicional amb una adreça IP del client.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).Suggeriment
Aquesta configuració no es pot activar de manera predeterminada, perquè permetria la falsificació d’adreces IP en instal·lacions que no tenen un servidor intermediari invers configurat correctament.
- Server host name
La capçalera Host hauria de coincidir amb el que estigui configurat com a
SITE_DOMAIN. Pot ser que calgui una configuració addicional al vostre servidor intermediari invers (per exemple, utilitzeuProxyPreserveHost Onper a Apache oproxy_set_header Host $host;amb nginx).Suggeriment
Els errors de verificació de CSRF solen ser causats per una manca de coincidència entre la capçalera Host i la configuració
SITE_DOMAIN.- Client protocol
No passar el protocol correcte pot fer que Weblate acabi en un bucle de redirecció intentant actualitzar el client a HTTPS. Assegureu-vos que el servidor intermediari invers l’exposa correctament com a X-Forwarded-Proto.
Aleshores, aquesta capçalera s’ha de configurar a
SECURE_PROXY_SSL_HEADER(settings.py) oWEBLATE_SECURE_PROXY_SSL_HEADER(entorn Docker).Important
El valor de la capçalera distingeix entre majúscules i minúscules a la configuració, de manera que
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsiWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSno són intercanviables.Suggeriment
Si rebeu un error «Masses redireccions» del navegador, és probable que això sigui causat per una discrepància entre el protocol real (HTTPS) i el que observa Weblate.
Canviat a la versió 5.13: Les capçaleres de proxy de protocol són gestionades automàticament per gunicorn en la configuració predeterminada, però altres servidors WSGI tenen una configuració més segura i requereixen una configuració explícita d’aquesta.
Des del Weblate 5.13, el contenidor Docker està utilitzant granian i ara requereix la configuració explícita de
WEBLATE_SECURE_PROXY_SSL_HEADER.
Vegeu també
Proxy HTTP¶
Weblate supports per-protocol HTTP proxy configuration for outbound HTTP
requests and Git repositories. Define the proxy environment variables in
settings.py:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["https_proxy"] = "http://proxy.example.com:8080"
Only http_proxy and https_proxy are supported. Generic and bypass
variables such as all_proxy and no_proxy, operating-system proxy
configuration, and VCS-specific proxy configuration are not supported.
Vegeu també
Ajust de configuració¶
Vegeu també
Copieu weblate/settings_example.py a weblate/settings.py i ajusteu-lo perquè coincideixi amb la vostra configuració. Probablement voldreu ajustar les opcions següents:
ADMINS
Llista d’administradors del lloc per rebre notificacions quan alguna cosa va malament, per exemple, notificacions sobre fusions fallides o errors de Django.
El formulari de contacte també envia correu electrònic sobre aquests, tret que
ADMINS_CONTACTestigui configurat.
ALLOWED_HOSTS
Heu de configurar-ho per llistar els amfitrions que se suposa que ha de servir el vostre lloc. Per exemple:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativament, podeu incloure el comodí:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Configureu com s’emmagatzemaran les vostres sessions. En cas que mantingueu el motor de fons de la base de dades predeterminat, hauríeu de programar: weblate clearsessions per eliminar les dades de sessió obsoletes de la base de dades.
Si utilitzeu Valkey o Redis com a memòria cau (vegeu Configure cache), es recomana utilitzar-lo també per a sessions:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"Vegeu també
DATABASES
Connectivitat amb el servidor de bases de dades, si us plau, consulteu la documentació de Django per obtenir més detalls.
DEBUG
Desactiveu-ho per a qualsevol servidor de producció. Amb el mode de depuració activat, Django mostrarà traces enrere en cas d’error als usuaris, quan el desactiveu, els errors s’enviaran per correu electrònic a
ADMINS(vegeu més amunt).El mode de depuració també alenteix Weblate, ja que Django emmagatzema molta més informació internament en aquest cas.
Vegeu també
DEFAULT_FROM_EMAIL
Adreça de remitent de correu electrònic per a correu electrònic de sortida, per exemple, correus electrònics de registre.
Vegeu també
SECRET_KEY
Clau utilitzada per Django per signar informació a les galetes, vegeu Clau secreta de Django per a més informació.
Vegeu també
SERVER_EMAIL
Correu electrònic utilitzat com a adreça de remitent per enviar correus electrònics a l’administrador, per exemple, notificacions sobre fusions fallides.
Vegeu també
Omplint la base de dades¶
Quan la vostra configuració estigui preparada, podeu executar migrate per crear l’estructura de la base de dades. Ara hauríeu de poder crear projectes de traducció mitjançant la interfície d’administració.
Un cop hàgiu acabat, també hauríeu de comprovar el Informe de rendiment a la interfície d’administració, que us donarà pistes de possibles configuracions no òptimes al vostre lloc.
Vegeu també
Configuració de producció¶
Per a una configuració de producció, hauríeu de realitzar els ajustos descrits a les seccions següents. La configuració més crítica activarà un avís, que s’indica amb un signe d’exclamació a la barra superior si s’inicia la sessió com a superusuari:
També es recomana inspeccionar les comprovacions activades per Django (tot i que potser no haureu de solucionar-les totes):
weblate check --deploy
També podeu revisar la mateixa llista de verificació a Informe de rendiment a la Interfície de gestió.
Vegeu també
Desactiva el mode de depuració¶
Desactiveu el mode de depuració de Django (DEBUG) per:
DEBUG = False
Amb el mode de depuració activat, Django emmagatzema totes les consultes executades i mostra als usuaris rastres d’errors, cosa que no es desitja en una configuració de producció.
Vegeu també
Configurar correctament els administradors¶
Set the correct admin addresses to the ADMINS setting to define who will receive
e-mails in case something goes wrong on the server, for example:
ADMINS = ("Your Name <your_email@example.com>",)
Vegeu també
Establiu el domini del lloc correcte¶
Ajusteu el nom i el domini del lloc a la interfície d’administració, en cas contrari, els enllaços en RSS o correus electrònics de registre no funcionaran. Això es configura mitjançant SITE_DOMAIN que hauria de contenir el nom de domini del lloc.
Canviat a la versió 4.2: Abans de la versió 4.2, s’utilitzava el marc de llocs de Django, si us plau, consulteu The “sites” framework.
Configura correctament HTTPS¶
És molt recomanable executar Weblate mitjançant el protocol HTTPS encriptat. Després d’habilitar-lo, hauríeu d’establir ENABLE_HTTPS a la configuració:
ENABLE_HTTPS = True
Suggeriment
És possible que també vulgueu configurar HSTS, vegeu SSL/HTTPS per a més detalls.
Estableix correctament SECURE_HSTS_SECONDS¶
Si el vostre lloc es publica mitjançant SSL, heu de considerar establir un valor per a SECURE_HSTS_SECONDS al settings.py per habilitar la seguretat del transport estricte HTTP. De manera predeterminada, està establert a 0 com es mostra a continuació.
SECURE_HSTS_SECONDS = 0
Si s’estableix en un valor enter diferent de zero, la django.middleware.security.SecurityMiddleware estableix la capçalera HTTP Strict Transport Security a totes les respostes que encara no la tenen.
Avís
Configurar-ho de manera incorrecta pot trencar el vostre lloc de manera irreversible (durant un temps). Llegiu primer la documentació de HTTP Strict Transport Security.
Utilitzeu un motor de bases de dades potent¶
Si us plau, utilitzeu PostgreSQL per a un entorn de producció, vegeu Configuració de la base de dades per a Weblate per a més informació.
Utilitzeu la ubicació adjacent per executar el servidor de bases de dades, en cas contrari, el rendiment o la fiabilitat de la xarxa podrien arruïnar la vostra experiència de Weblate.
Comproveu el rendiment del servidor de bases de dades o modifiqueu-ne la configuració, per exemple utilitzant PGTune.
Weblate deployment checks report non-finite PostgreSQL relation statistics. Run
ANALYZEon the reported relations to rebuild corrupted statistics.
Configure cache¶
Si és possible, utilitzeu Valkey o Redis de Django ajustant la variable de configuració CACHES, per exemple:
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",
},
}
}
Suggeriment
In case you change settings for the cache, you might need to adjust them for Celery as well, see Tasques de fons amb api.
Emmagatzematge a la memòria cau d’avatar¶
A més de la memòria cau de Django, Weblate realitza la memòria cau dels avatars. Es recomana utilitzar una memòria cau separada amb una còpia de seguretat de fitxers per a aquest propòsit:
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 l’enviament de correu electrònic¶
Weblate ha d’enviar correus electrònics en diverses ocasions, i aquests correus electrònics haurien de tenir una adreça de remitent correcta, configureu SERVER_EMAIL i DEFAULT_FROM_EMAIL perquè coincideixin amb el vostre entorn, per exemple:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Nota
Per desactivar l’enviament de correus electrònics per Weblate, configureu EMAIL_BACKEND a django.core.mail.backends.dummy.EmailBackend.
Això desactivarà l’enviament de tots els correus electrònics, inclosos els de registre o de restabliment de la contrasenya.
Configuració dels amfitrions permesos¶
Django requereix que ALLOWED_HOSTS contingui una llista de noms de domini que el vostre lloc pot servir, i deixar-lo buit bloquejarà qualsevol sol·licitud.
En cas que això no estigui configurat per coincidir amb el vostre servidor HTTP, obtindreu errors com Capçalera HTTP_HOST no vàlida: '1.1.1.1'. És possible que hàgiu d'afegir "1.1.1.1" a ALLOWED_HOSTS.
Suggeriment
Al contenidor Docker, això està disponible com a WEBLATE_ALLOWED_HOSTS.
Clau secreta de Django¶
Django utilitza la configuració SECRET_KEY per signar galetes, i realment hauríeu de generar el vostre propi valor en lloc d’utilitzar el de la configuració d’exemple.
Podeu generar una nova clau utilitzant weblate-generate-secret-key enviat amb Weblate.
Vegeu també
Execució de tasques de manteniment¶
Per obtenir un rendiment òptim, és bona idea executar algunes tasques de manteniment en segon pla. Això es fa automàticament per Tasques de fons amb api i cobreix les tasques següents:
Comprovació de l’estat de la configuració (horària).
Committing pending changes (hourly), see La mandrosa es compromet and
commit_pending.Actualització d’alertes de components (diàriament).
Actualitzeu les oficines remotes (notment), vegeu
AUTO_UPDATE.Còpia de seguretat de la memòria de traducció a JSON (diària), vegeu
dump_memory.Tasques de manteniment de bases de dades i text complet (tasques diàries i setmanals), vegeu
cleanuptrans.
Localitzacions i codificació del sistema¶
Les configuracions locals del sistema s’han de configurar amb les que són compatibles amb UTF-8. A la majoria de distribucions de Linux, aquesta és la configuració predeterminada. En cas que no sigui el cas al vostre sistema, canvieu la configuració regional a la variant UTF-8.
Per exemple, editant /etc/default/locale i establint-hi LANG="C.UTF-8".
En alguns casos, els serveis individuals tenen una configuració separada per a locals. Això varia entre la distribució i els servidors web, així que comproveu la documentació dels paquets dels vostres servidors web.
Apache a Ubuntu utilitza /etc/apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache a CentOS utilitza /etc/sysconfig/httpd (o /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Servidor en execució¶
Suggeriment
En cas que no tingueu experiència amb els serveis descrits a continuació, potser voldreu provar Instal·lació mitjançant Docker.
Necessitareu diversos serveis per executar Weblate, la configuració recomanada consisteix en:
Servidor de bases de dades (vegeu Configuració de la base de dades per a Weblate)
Servidor de memòria cau (vegeu Configure cache)
Servidor web frontal per a fitxers estàtics i terminació SSL (vegeu Donant arxius estàtics)
Servidor WSGI per a contingut dinàmic (vegeu Exemple de configuració per a NGINX i uWSGI)
Celery for executing background tasks (see Tasques de fons amb api)
Nota
Hi ha algunes dependències entre els serveis, per exemple, la memòria cau i la base de dades haurien d’estar executant-se quan s’inicien processos Celery o uwsgi.
En la majoria dels casos, executareu tots els serveis en un sol servidor (virtual), però en cas que la vostra instal·lació estigui carregada, podeu dividir els serveis. L’única limitació d’això és que els servidors Celery i Wsgi necessiten accés a DATA_DIR.
Nota
El procés WSGI s’ha d’executar sota el mateix usuari que el procés Celery, en cas contrari, els fitxers de DATA_DIR s’emmagatzemaran amb propietats mixtes, cosa que provocarà problemes d’execució.
Vegeu també Permisos del sistema de fitxers i Tasques de fons amb api.
Servidor web en execució¶
Executar Weblate no és diferent d’executar qualsevol altre programa basat en Django. Django s’executa normalment com a WSGI o fcgi (vegeu exemples de diferents servidors web a continuació).
Nota
Els fitxers de configuració de mostra que es mostren a continuació es mantenen a l’arbre de fonts de Weblate a weblate/examples/. S’inclouen a les distribucions d’origen i en aquesta documentació, però les rodes de Python només instal·len fitxers en temps d’execució. Quan instal·leu Weblate des de PyPI, obteniu la distribució de la font coincident o la comprovació de la font abans de copiar aquests exemples.
Amb finalitats de prova, podeu utilitzar el servidor web integrat a Django:
weblate runserver
Avís
NO UTILITZAR AQUEST SERVIDOR EN UNA CONFIGURACIÓ DE PRODUCCIÓ. No ha passat per auditories de seguretat ni proves de rendiment. Vegeu també la documentació de Django a runserver.
Suggeriment
El servidor integrat de Django només serveix fitxers estàtics amb DEBUG habilitat, ja que només està pensat per al desenvolupament. Per a l’ús de producció, consulteu les configuracions de WSGI:
Donant arxius estàtics¶
Canviat a la versió 5.15.2: /media/ ja no s’utilitza per mostrar captures de pantalla.
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). Production installations
use content hashes in collected filenames so that updated assets do not reuse
stale browser or proxy caches.
Es recomana servir fitxers estàtics directament des del vostre servidor web, hauríeu d’utilitzar-lo per als camins següents:
/static/Ofereix fitxers estàtics per a Weblate i per a la interfície d’administració (a partir del definit per
STATIC_ROOT)./favicon.icoShould be rewritten to serve
/static/favicon.ico.
Política de seguretat de continguts¶
La configuració predeterminada del Weblate activa el programari intermediari weblate.middleware.SecurityMiddleware que estableix capçaleres HTTP relacionades amb la seguretat com Content-Security-Policy o X-XSS-Protection. Aquests estan configurats de manera predeterminada per funcionar amb Weblate i la seva configuració, però això pot necessitar personalització per al vostre entorn.
Sample configuration for NGINX and Granian¶
The following configuration runs Weblate using Granian with 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;
}
}
Exemple de configuració per a NGINX i 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;
}
}
Exemple de configuració per a NGINX i uWSGI¶
Per executar el servidor web de producció, utilitzeu l’embolcall WSGI instal·lat amb Weblate (quan utilitzeu un entorn Python, s’instal·la com a ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). No oblideu establir també la ruta de cerca de Python al vostre entorn Python (per exemple, utilitzant virtualenv = /home/user/weblate-env a uWSGI).
La configuració següent executa Weblate com uWSGI al servidor web NGINX.
Configuració per a NGINX (weblate/examples/weblate.nginx.conf a l’arbre d’origen):
#
# 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;
}
}
Configuració per a uWSGI (weblate/examples/weblate.uwsgi.ini a l’arbre d’origen):
#
# 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
Vegeu també
Exemple de configuració per a Apache¶
Es recomana utilitzar prefork MPM quan utilitzeu WSGI amb Weblate.
La configuració següent executa Weblate com a WSGI, cal que hàgiu habilitat mod_wsgi (weblate/examples/apache.conf a l’arbre d’origen):
#
# 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>
Nota
Weblate requereix Python 3, així que assegureu-vos que esteu executant la variant Python 3 del modwsgi. Normalment està disponible com un paquet separat, per exemple libapache2-mod-wsgi-py3.
Use matching Python version to install Weblate.
Exemple de configuració per a 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 té una dependència opcional wsgi (vegeu Dependències de Python) que instal·larà tot el que necessiteu per executar Granian. Quan instal·leu Weblate, podeu especificar-lo com:
uv pip install Weblate[all,wsgi]
Un cop tingueu instal·lat Granian, podeu executar-lo. Això es fa normalment a nivell de sistema. Els exemples següents mostren l’inici mitjançant 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 450 \
--interface wsgi \
--workers 2 \
--blocking-threads 8 \
--backlog 128 \
--backpressure 16 \
--runtime-mode mt \
--port 8888 \
weblate.wsgi:application
[Install]
WantedBy=multi-user.target
Granian uses worker processes for parallel Python execution, blocking threads for concurrent WSGI requests, and runtime threads for network I/O. The sample uses two workers with eight blocking threads each, limits each worker to 16 concurrent connections, and leaves the runtime threads at Granian’s default. Adjust the workers and blocking threads to the available memory, CPU cores, and database connection limit. Keep the backpressure equal to or higher than the number of blocking threads.
Sample configuration to start Granian with ASGI¶
Afegit a la versió 2026.8.
ASGI deployment is available as an opt-in alternative to WSGI. Install the
asgi optional dependency:
uv pip install Weblate[all,asgi]
The following systemd unit runs the Django ASGI application:
[Unit]
Description=granian ASGI 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 450 \
--interface asginl \
--workers 2 \
--backlog 128 \
--backpressure 16 \
--runtime-mode mt \
--port 8888 \
weblate.asgi:application
[Install]
WantedBy=multi-user.target
The sample uses Granian’s ASGI interface without lifespan or WebSocket support, because Weblate currently exposes HTTP only. Weblate’s middleware supports both deployment modes and uses thread-sensitive adapters where it still relies on synchronous Django APIs. The health check is asynchronous, but most Weblate views remain synchronous, and CPU-intensive or long-running work should still be handled by Tasques de fons amb api.
WSGI remains the default deployment mode. Docker images can opt in to ASGI by
setting WEBLATE_ASGI to 1. Adjust the worker count and
backpressure to the available memory, CPU cores, and database connection limit.
Sample configuration to start Gunicorn¶
Gunicorn s’ha d’instal·lar per separat:
uv pip install gunicorn
Un cop tingueu instal·lat Gunicorn, podeu executar-lo. Això es fa normalment a nivell de sistema. Els exemples següents mostren l’inici mitjançant 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
Vegeu també
S’està executant Weblate sota el camí¶
Es recomana utilitzar prefork MPM quan utilitzeu WSGI amb Weblate.
Una configuració d’Apache de mostra per servir Weblate a /weblate. De nou, utilitzant mod_wsgi (weblate/examples/apache-path.conf a l’arbre d’origen):
#
# 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>
A més, haureu d’ajustar weblate/settings.py:
URL_PREFIX = "/weblate"
Tasques de fons amb api¶
Weblate utilitza Celery per executar tasques habituals i en segon pla. Se suposa que heu d’executar un servei d’api que els executarà. Per exemple, és responsable de gestionar les operacions següents (aquesta llista no està completa):
Recepció de webhooks de serveis externs (vegeu Punts d’inserció de notificacions).
Execució de tasques de manteniment habituals, com ara còpies de seguretat, neteja, complements diaris o actualitzacions (vegeu Còpia de seguretat i moviment de Weblate,
BACKGROUND_TASKS, Complements).Running Traducció automatitzada.
Sending digest notifications.
Descàrrega d’operacions cares del procés WSGI.
Committing pending changes (see La mandrosa es compromet).
Una configuració típica que utilitza Valkey o Redis com a backend té aquest aspecte:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Vegeu també
També hauríeu d’iniciar el treballador d’api per processar les tasques i iniciar les tasques programades. Per a la depuració o el desenvolupament, això es pot fer directament a la línia d’ordres:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup
Nota
El procés Celery s’ha d’executar amb el mateix usuari que el procés WSGI, en cas contrari, els fitxers a DATA_DIR s’emmagatzemaran amb propietats mixtes, cosa que comportarà problemes d’execució.
Vegeu també Permisos del sistema de fitxers i Servidor en execució.
Execució de tasques d’api al WSGI mitjançant el mode eager¶
Nota
Això tindrà un impacte greu en el rendiment de la interfície web i trencarà les funcions segons l’activador habitual (per exemple, cometre canvis pendents, notificacions de resum o còpies de seguretat).
Per al desenvolupament, és possible que vulgueu utilitzar una configuració amb ganes, que processa totes les tasques al seu lloc:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Execució de Celery com a servei del sistema¶
El més probable és que vulgueu executar Celery com a dimoni i això està cobert per Daemonization. Per a la configuració de Linux més habitual amb systemd, adapteu els fitxers d’exemple que s’indiquen a continuació. Aquests exemples es mantenen a l’arbre de fonts de Weblate a weblate/examples/; Les rodes de Python no instal·len aquestes mostres de desplegament.
La unitat Systemd es col·locarà com a /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
La configuració de l’entorn es col·locarà com a /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. A higher prefetch multiplier can improve throughput for
# short tasks, but reserves more tasks in each worker. Command-line values
# override CELERY_WORKER_PREFETCH_MULTIPLIER from settings.py.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=1 \
--queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=4 \
--queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=1 \
--queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=1 \
--queues:backup=backup --concurrency:backup=1 --prefetch-multiplier:backup=1"
# 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"
Configuració addicional per girar els registres d’api mitjançant logrotate per col·locar-lo com a /etc/logrotate.d/celery:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Tasques periòdiques utilitzant el batec d’api¶
Weblate inclou una configuració integrada per a les tasques programades. La programació de tasques s’emmagatzema a la base de dades i les tasques les executa el dimoni Celery beat.
Suggeriment
Podeu definir tasques addicionals a settings.py, per exemple, vegeu La mandrosa es compromet.
Monitorització de l’estat de l’api¶
Podeu trobar la longitud actual de les cues de tasques Celery a la Interfície de gestió o podeu utilitzar celery_queues a la línia d’ordres. En cas que la cua sigui massa llarga, també obtindreu un error de configuració a la interfície d’administració.
Avís
Els errors d’Api només s’inicien per defecte al registre d’Api i no són visibles per l’usuari. En cas que vulgueu tenir una visió general d’aquests errors, es recomana configurar Recollida d’informes d’errors i seguiment del rendiment.
Configuració d’api d’un sol procés¶
En cas que tingueu una memòria molt limitada, és possible que vulgueu reduir el nombre de processos de Weblate. Totes les tasques d’api es poden executar en un sol procés mitjançant:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Una instal·lació amb Docker es pot configurar per utilitzar una configuració d’Api d’un sol procés configurant CELERY_SINGLE_PROCESS.
Avís
Això tindrà un impacte notable en el rendiment de Weblate.
Monitoring Weblate¶
Weblate proporciona l’URL /healthz/ per utilitzar-lo en comprovacions de salut senzilles, per exemple, utilitzant Kubernetes. El contenidor Docker té una comprovació de salut integrada mitjançant aquest URL.
Per controlar les mètriques de Weblate, podeu utilitzar el punt final de l’API GET /api/metrics/.
Recollida d’informes d’errors i seguiment del rendiment¶
Weblate, com qualsevol altre programari, pot fallar. Per recopilar estats d’error útils, recomanem utilitzar serveis de tercers per recollir aquesta informació. Això és especialment útil en cas de fallar les tasques d’Api, que d’altra manera només informarien d’errors als registres i no rebràs notificacions sobre ells. Weblate té suport per als serveis següents:
Adreça electrònica¶
La configuració predeterminada de Weblate instrumenta Django per enviar correus electrònics en cas d’errors del servidor mitjançant django.utils.log.AdminEmailHandler. Aquesta és la configuració de menys esforç, però hauríeu de considerar altres opcions per motius de privadesa, ja que els correus electrònics d’error poden incloure dades sensibles. Podeu llegir més sobre això a Security implications.
Per desactivar aquest comportament, elimineu mail_admins de LOGGING a la configuració de Weblate, o desactiveu WEBLATE_ADMIN_NOTIFY_ERROR a l’entorn Docker.
Sentry¶
Weblate té suport integrat per a Sentry. Per utilitzar-lo, n’hi ha prou amb establir SENTRY_DSN al settings.py:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry també es pot utilitzar per supervisar el rendiment de Weblate recopilant traces i perfils per a un percentatge definit d’operacions. Això es pot configurar mitjançant SENTRY_TRACES_SAMPLE_RATE i SENTRY_PROFILES_SAMPLE_RATE.
Vegeu també
Informe d’errors de Google Cloud¶
Weblate can report handled server errors to Google Cloud Error Reporting.
Install Weblate with the google-errors extra and configure
GOOGLE_CLOUD_ERROR_REPORTING in settings.py:
GOOGLE_CLOUD_ERROR_REPORTING = {
"project": "your-google-cloud-project",
}
Weblate informa automàticament d’errors al servei weblate i utilitza la versió actual de Weblate o la revisió de Git com a versió informada. Aquests valors es poden substituir configurant service o version a GOOGLE_CLOUD_ERROR_REPORTING.
OpenTelemetry¶
Weblate pot exportar traces de backend utilitzant OpenTelemetry. Utilitza OTLP sobre HTTP i pot enviar rastres a un col·lector d’OpenTelemetry o a un punt final de proveïdor compatible.
OPENTELEMETRY_ENABLED = True
OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT = "https://collector.example.com/v1/traces"
OPENTELEMETRY_TRACES_SAMPLE_RATE = 0.1
La integració rastreja les sol·licituds de Django, les tasques de Celery, Redis, les sol·licituds HTTP sortints, les trucades a la base de dades i els intervals específics de Weblate. Configureu-lo amb OPENTELEMETRY_ENABLED, OPENTELEMETRY_EXPORTER_OTLP_ENDPOINT i OPENTELEMETRY_TRACES_SAMPLE_RATE.
Rollbar¶
Weblate té suport integrat per a Rollbar. Per utilitzar-lo, n’hi ha prou amb seguir les instruccions per a Notificador de barra de desplaçament per a Python.
En resum, cal ajustar 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",
}
Tota la resta s’integra automàticament, ara recopilareu errors tant del servidor com del client.
Nota
El registre d’errors també inclou excepcions que s’han gestionat amb gràcia, però que poden indicar un problema, com ara l’anàlisi fallida d’un fitxer penjat.
Graylog log management¶
Afegit a la versió 5.9.
Weblate es pot configurar per iniciar sessió mitjançant el protocol GELF TCP. Això es va desenvolupar per a la integració de Graylog, però es pot utilitzar amb qualsevol plataforma de registre compatible.
El boilerplate de configuració s’inclou a Exemple de configuració, per a Docker això es pot configurar mitjançant WEBLATE_LOG_GELF_HOST.
Migració de Weblate a un altre servidor¶
Migrar Weblate a un altre servidor hauria de ser bastant fàcil, però emmagatzema dades en poques ubicacions que hauríeu de migrar amb cura. El millor enfocament és aturar Weblate per a la migració.
Base de dades en migració¶
L’enfocament més senzill és utilitzar les eines natives de la base de dades, ja que solen ser les més efectives (p. ex. pg_dump). Alternativament, podeu utilitzar la replicació si la vostra base de dades ho admet.
Vegeu també
Migració entre bases de dades descrites a Migració d’altres bases de dades a PostgreSQL.
Migració de repositoris VCS¶
Els repositoris VCS emmagatzemats a DATA_DIR també s’han de migrar. Simplement podeu copiar-los o utilitzar rsync per fer la migració de manera més eficaç.
Altres notes¶
No us oblideu de moure altres serveis que Weblate podria haver fet servir, com ara treballs de Valkey, Redis, Cron o backends d’autenticació personalitzats.