Instrucciones de configuración¶
Instalar Weblate¶
En función de la preparación y su experiencia, elija un método de instalación apropiado para usted:
Instalar con Docker, recomendable para montajes en entornos de producción.
Instalación en entorno virtual, recomendable para montajes en entornos de producción:
Instalar desde el código fuente, recomendable para el desarrollo.
Descripción general de la arquitectura¶
- Servidor web
Manipulando respuestas HTTP entrantes, Sirviendo archivos estáticos.
- Empleados de Celery
Tareas en segundo plano con Celery son ejecutados aquí.
Dependiendo de su carga de trabajo, quizá dese personalizar el número de empleados.
Utilice nodo dedicado cuando escale horizontalmente el Weblate.
- Servidor WSGI
Un servidor WSGI sirviendo páginas web a usuarios.
Utilice nodo dedicado cuando escale horizontalmente el Weblate.
- Base de datos
Servidor de base de datos PostgreSQL para almacenar todo el contenido, véase Configuración de base de datos para Weblate.
Utiliza nodo de base de datos dedicada para sitios con cientos de millones de palabras hospedadas.
- Almacén de datos
Clave/valor de almacén de datos tal como servidor Valkey o Redis para caché y colas de tareas, consulte Tareas en segundo plano con Celery.
Utilice nodo dedicado cuando escale horizontalmente el Weblate.
- Sistema de archivo
Almacenaje del sistema de archivos para almacenar repositorios VCS y datos de usuario actualizado. Esto está compartido por todos los procesadores.
Utiliza almacenaje de red cuando escala Weblate horizontalmente.
- Servidor de correo-e
Servidor SMTP para salida de correo-e, consulte Configurar el correo electrónico saliente. Puede ser proporcionado externamente.
Consejo
Instalar con Docker incluye PostgreSQL y Valkey, haciendo la instalación más fácil.
Requisitos de software¶
Sistema operativo¶
Se sabe que Weblate funciona en Linux, FreeBSD y macOS. Es posible que funcione también en otros sistemas similares a Unix.
Weblate no es compatible con Windows. Aun así, es posible hacerlo funcionar; aceptaremos parches para este fin.
Ver también
Descripción general de la arquitectura describe la arquitectura Weblate y servicios requeridos.
Dependencias de Python¶
Weblate está escrito en Python y es compatible con Python 3.12 o posterior. Puede instalar las dependencias mediante pip o desde los paquetes de su distribución. La lista completa está disponible en requirements.txt.
Dependencias más notables:
- Django
- Apio
- Translate Toolkit
- translation-finder
- Python Social Auth
- Marco REST de Django
Dependencias opcionalmente específicas |
Paquetes de Python |
Característica de Weblate |
|---|---|---|
|
||
|
||
|
||
|
Google Cloud Translation Advanced con soporte de glosario |
|
|
||
|
||
|
PostgreSQL, consulte Configuración de base de datos para Weblate |
|
|
Recopilación de informes de errores y supervisión del rendimiento |
|
|
||
|
Integración de SAML 2 IDP en Weblate |
|
|
Necesario para Actualizar archivo POT (Sphinx) |
|
|
Integración de Weblate Hospedado |
|
|
Servidor wsgi para Weblate |
|
|
Cuando instale utilizando pip, puede especificar directamente características deseadas cuando instale:
uv pip install "weblate[Postgres,Amazon,SAML]"
O puede instalar Weblate con todas las funciones opcionales:
uv pip install "weblate[all]"
O puede instalar Weblate sin ninguna característica opcional:
uv pip install weblate
Solución de problemas al instalar pip¶
ERROR: Dependency 'gobject-introspection-2.0' is required but not found.El paquete instalado
PyGobjectno puede encontrar una biblioteca de GObject Instrospection coincidente:gobject-introspection-2.0.Las versiones más antiguas no tienen mantenimiento por más tiempo en 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)Esto lo causa incompatibilidad de paquetes binarios distribuidos por PyPI con la distribución. Para direccionar esto, necesita recompilar el paquete en su sistema:
uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?Este es una incidencia conocida del paquete xmlsec, consulte https://github.com/xmlsec/python-xmlsec/issues/314.
lxml & xmlsec libxml2 library version mismatchLos paquetes
lxmlyxmlsectienen que compilarse frente a unlibxml2. Los compilaría localmente para evitar esta incidencia:uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec
Otros requisitos de sistema¶
Deben instalarse las dependencias siguientes en el sistema:
Git- Pango, Cairo y cabecera de archivos relacionado y datos de introspección GObject
https://cairographics.org/, https://www.gtk.org/docs/architecture/pango, consulte Pango y Cairo
git-review(opcional para admitir Gerrit)git-svn(opcional para admitir Subversion)tesseract(solo necesario si tesserocr binario wheels no está disponible para su sistema)
Dependencias en tiempo de la compilación¶
Para compilar algunos de los Dependencias de Python quizá necesita instalar sus dependencias. Esto depende en somo instalarlos, por tanto consulte paquetes individual para documentación. No necesitaría esos si utiliza pre-compilación Wheeals mientras instala utilizando pid o cuando utilice paquetes de distribución.
Pango y Cairo¶
Weblate usa Pango y Cairo para representar widgets de mapa de bits (ver Construir la comunidad de traducción) y para representar casillas (consulte Gestionar tipos de letra). Para instalar correctamente los vínculos de Python para estas bibliotecas necesitas instalar primero las bibliotecas del sistema: necesitas tanto Cairo como Pango, que a su vez necesitan GLib. Todas ellas deben estar instaladas con los archivos de desarrollo y los datos de introspección de GObject.
Requisitos de hardware¶
Weblate debería funcionar en cualquier hardware contemporáneo sin problemas, la siguiente es la configuración mínima necesaria para ejecutar Weblate en un único host (Weblate, base de datos y servidor web):
3 GB de RAM
2 núcleos de CPU
1 GB de espacio de almacenamiento
Nota
Requisitos actuales para su instalación de Weblate varían pesadamente basado en el tamaño de las traducciones gestionadas dentro de esto.
Consumo de memoria¶
Cuanta más memoria tenga, mejor; ya que se utiliza para el pre-almacenaje en todos los niveles (sistema de archivos, base de datos y Weblate). Para cientos de componentes de traducción, al menos se recomiendan 4 GB de RAM.
Consejo
Para sistemas con menos memoria que la recomendada, Configuración de Celery de un solo proceso es recomendada.
Empleo de CPU¶
Muchos usuarios concurrentes incremente la cantidad de núcleos de CPU necesarios.
Uso de almacenaje¶
El almacenaje de base de datos típica es de alrededor de 300 MB por 1 millón de palabras hospedadas.
El espacio de almacén necesario para repositorios clonados varía, pero Weblate intenta mantener su tamaño mínimo haciendo clones llanos.
Nodos¶
Para sitios de tamaño medio y mínimo (millones de palabras almacenadas), todos los componentes Weblate (consulte Descripción general de la arquitectura) puede ser ejecutado en un único nodo.
Cuando crezca a cientos de millones de palabras hospedadas, es recomendado tener un nodo dedicado para base de datos (consulte Configuración de base de datos para Weblate).
Comprobar las firmas de liberación¶
La liberación Weblate están firmadas cifradamente utilizando Firmas de sigsote. Las firmas están adjuntadas a la liberación GitHub.
La verificación puede ser realizada utilizando sigstore package. El siguiente ejemplo verifica firma de la liberación 5.4:
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
Permisos del sistema de archivos¶
El proceso Weblate necesita poder leer y escribir en el directorio donde guarda los datos - DATA_DIR. Todos los archivos dentro de este directorio deben ser propiedad del usuario que ejecuta todos los procesos Weblate (normalmente WSGI y Celery, consulte Ejecutar servidor y Tareas en segundo plano con Celery).
La configuración por defecto los coloca en el mismo árbol que las fuentes de Weblate, sin embargo puede que prefieras moverlos a un lugar mejor como: /var/lib/weblate.
Weblate intenta crear estos directorios automáticamente, pero fallará cuando no tiene permisos para hacer tal.
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.
También debe tener cuidado al ejecutar Órdenes de gestión, ya que deben ejecutarse con el mismo usuario con el que se ejecuta Weblate, de lo contrario los permisos de algunos archivos podrían ser incorrectos.
En el contenedor Docker, todos los archivos en el volumen /app/data tienen que ser propiedad del usuario weblate dentro del contenedor (UID 1000).
Ver también
Configuración de base de datos para Weblate¶
Es recomendable ejecutar Weblate con un servidor de bases de datos PostgreSQL.
PostgreSQL 13 y posterior está mantenida. PostgresSQL 15 o más nueva está recomendada.
Ver también
Conexiones de base de datos¶
En la configuración por defecto, cada proceso de Weblate mantiene una conexión persistente con la base de datos. Las conexiones persistentes mejoran la capacidad de respuesta de Weblate, pero pueden requerir más recursos para el servidor de la base de datos. Por favor, consulte CONN_MAX_AGE y Persistent connections para más información.
Weblate necesita al menos el siguiente número de conexiones:
\((4 \mathit{nCPUs}) + 2\) para procesos Celery
\(\mathit{nCPUs} + 1\) para empleados WSGI
Esto aplica al contenedor Docker por defecto y configuraciones de ejemplo proporcionadas dentro de este documentación, pero los números cambiarán su personalización de cantidad de trabajadores WSGI o ajuste paralelismo de Celery.
El límite actual para el número de conexiones de base de datos necesarias para ser más alta para cuenta siguientes estas situaciones:
Órdenes de gestión necesita su conexión también.
Si el proceso case es eliminado (por ejemplo por OOM killer), puede bloquear la conexión existente hasta que se agote el tiempo de espera.
PostgreSQL¶
PostgreSQL usualmente es la mejor elección para sitios basados en Django. Es la base de datos de referencia utilizada para implementar capa de base de datos de Django.
Nota
Weblate utiliza extensión trigrama la cual tiene que ser instalada separadamente en algunos casos. Busque postgresql-contrib o un paquete nombrado similar.
Ver también
Crear una base de datos en PostgreSQL¶
Suele ser una buena idea ejecutar Weblate en su propia base de datos, en una cuenta de usuario separada:
# 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
Consejo
Si no quiere hacer el usuario Weblate un superusuario en PostgreSQL, puede omitir eso. En ese caso tendrá que realizar alguno de los pasos de migración manualmente como un superusuario PostgreSQL en esquema Weblate utilizará:
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
Configurar Weblate para que utilice PostgreSQL¶
El snippet settings.py para 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ón de la base de datos ejecuta ALTER ROLE en el rol de base de datos que utiliza Weblate. En la mayoría de los casos, el nombre del rol coincide con el apodo. En configuraciones más complejas, el nombre del rol es diferente del nombre de usuario, y se obtendrá un error sobre un rol inexistente durante la migración de la base de datos (psycopg2.errors.UndefinedObject: role "weblate@hostname" no existe). Esto es común con Azure Database for PostgreSQL, pero no se limita a este entorno. Configure ALTER_ROLE para cambiar el nombre del rol que Weblate debe modificar durante la migración de la base de datos.
Ver también
Otras configuraciones¶
Configurar el correo electrónico saliente¶
Weblate envía correos electrónicos en diversas ocasiones: para la activación de cuentas y para diversas notificaciones configuradas por los usuarios. Para ello, necesita acceso a un servidor SMTP.
La configuración del servidor de correo está configurado utilizando estos parámetros: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER y EMAIL_PORT. Sus nombres son explicativos para sí, pero puede encontrar más información en la documentación de Django.
Consejo
En caso de que reciba un error sobre autenticación no compatible (por ejemplo SMTP AUTH extension not supported by server), lo más probable es que se deba a una conexión insegura y el servidor se niega a autenticarse de esta manera. Intente habilitar EMAIL_USE_TLS en tal caso.
Ejecutar en proxy reverso¶
Varias funciones de Weblate dependen de que se transmitan correctamente los encabezados HTTP. Al usar un proxy inverso, asegúrese de que la información necesaria se transmita correctamente.
Para depurar esta configuración, puede consultar Entorno HTTP en Reporte de rendimiento.
- Dirección IP Cliente
Esto es necesario para Tipo limitante o Registro de auditoría.
Weblate analiza la dirección IP desde
REMOTE_ADDR, definida por el controlador WSGI. Esta dirección puede estar vacía (al usar un socket para WSGI) o contener una dirección de proxy inverso, por lo que Weblate necesita un encabezado HTTP adicional con la dirección IP del cliente.Habilitar
IP_BEHIND_REVERSE_PROXYsería suficiente para las configuraciones más habituales, pero es posible que también necesite ajustarIP_PROXY_HEADERyIP_PROXY_OFFSET(empleeWEBLATE_IP_PROXY_HEADERyWEBLATE_IP_PROXY_OFFSETen el contenedor Docker).Consejo
Esta configuración no se puede activar de forma predeterminada, porque permitiría la falsificación de direcciones IP en instalaciones que no tienen un proxy inverso configurado correctamente.
- Nombre de huésped del servidor
La cabecera Host debe coincidir con lo que esté configurado como
SITE_DOMAIN. Puede ser necesaria una configuración adicional en su proxy inverso (por ejemplo, utiliceProxyPreserveHost Onpara Apache oproxy_set_header Host $host;con nginx).Consejo
Verificación CSRF incorrecta con errores a menudo son causados por una coincidencia ausente entre la cabecera Host y lo configurado en
SITE_DOMAIN.- Protocolo del cliente
No pasar el protocolo correcto puede hacer que Weblate termine en un bucle de redirección intentando migrar el cliente a HTTPS. Asegúrese de que el proxy inverso lo expone correctamente como X-Forwarded-Proto.
Este encabezado debe configurarse en
SECURE_PROXY_SSL_HEADER(settings.py) oWEBLATE_SECURE_PROXY_SSL_HEADER(Entorno Docker).Importante
El valor del encabezado con distinción de capitalinas en la configuración, por tanto
WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,httpsyWEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPSno son intercambiables.Consejo
Si desde el explorador está obteniendo un error de «Demasiadas redirecciones», lo más probable es que se causó por una discrepancia entre el protocolo actual (HTTPS) y lo que observa Weblate.
Distinto en la versión 5.13: Las cabeceras del proxy del protocolo están manipuladas automáticamente por gunicorn en la configuración por defecto, pero otros servidores WSGI tienen una configuración más segura y requieren una configuración explícita de esto.
Desde Weblate 5.13 el contenedor Docker está utilizando granian y ahora requiere la configuración explícita de
WEBLATE_SECURE_PROXY_SSL_HEADER.
Ver también
Proxy HTTP¶
Weblate ejecuta comandos VCS y estos aceptan la configuración del proxy desde el entorno. Se recomienda definir la configuración del proxy en settings.py:
import os
os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"
Ver también
Ajustar configuración¶
Ver también
Copia weblate/settings_example.py a weblate/settings.py y ajústalo para que coincida con tu configuración. Probablemente quieras ajustar las siguientes opciones:
ADMINS
Lista de administradores del sitio que recibirán notificaciones cuando algo salga mal, por ejemplo, notificaciones sobre fusiones fallidas o errores de Django.
El formulario de contacto también envía correos electrónicos a estos, a menos que se configure
ADMINS_CONTACT.
ALLOWED_HOSTS
Debe configurar esto para que enumere los host a los que su sitio debe prestar servicio. Por ejemplo:
ALLOWED_HOSTS = ["demo.weblate.org"]Alternativamente puedes incluir un comodín:
ALLOWED_HOSTS = ["*"]
SESSION_ENGINE
Configure cómo se almacenarán sus sesiones. En caso de que mantenga el motor de backend de base de datos predeterminado, debe programar: weblate clearsessions para eliminar los datos de sesión obsoletos de la base de datos.
Si está utilizando Valkey o Redis como caché (consulte Configurar caché) es recomendado también utilizarlo para sesiones:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"Ver también
DATABASES
Conectividad al servidor de base de datos, por favor revise la documentación de Django para más detalles.
DEBUG
Deshabilite esto para cualquier servidor de producción. Con el modo de depuración habilitado, Django mostrará trazas inversas en caso de error a los usuarios, cuando lo deshabilite, los errores serán enviados por correo electrónico a
ADMINS(consulte a continuación).Modo depurar además ralentiza Weblate, como Django almacena mucha más información internamente en este caso.
Ver también
DEFAULT_FROM_EMAIL
Dirección de remite de correo-e para salida de correo-e, por ejemplo correos-e de registro.
Ver también
SECRET_KEY
Clave utilizada por Django para firmar alguna información en galletas, consulte Clave secreta de Django para más información.
Ver también
SERVER_EMAIL
Correo electrónico utilizado como dirección de remitente para enviar correos electrónicos al administrador, por ejemplo notificaciones sobre fusiones fallidas.
Ver también
Rellenar la base de datos¶
Una vez que su configuración esté lista, puede ejecutar migrate para crear la estructura de la base de datos. Ahora debería ser capaz de crear proyectos de traducción utilizando la interfaz administrativa.
Una vez que haya terminado, también debe comprobar el Informe de rendimiento en la interfaz administrativa, que le dará pistas de configuración no óptima potencial en su página.
Ver también
Puesta en marcha de entorno de producción¶
Para una configuración de producción debe realizar los ajustes descritos en las siguientes secciones. Los ajustes más críticos activarán una advertencia, que se indica con un signo de exclamación en la barra superior si se ha iniciado sesión como superusuario:
También se recomienda inspeccionar las comprobaciones lanzadas por Django (aunque puede que no necesites arreglarlas todas):
weblate check --deploy
También puede revisar la misma lista de verificación en Reporte de rendimiento en la Interfaz administrativa.
Ver también
Desactivar el modo de depuración¶
Ejecute esto para desactivar el modo de depuración (DEBUG) de Django:
DEBUG = False
Con el modo de depuración activado, Django almacena todas las consultas ejecutadas y muestra a los usuarios el seguimiento regresivo de los errores, lo cual no es deseable en un entorno de producción.
Ver también
Configurar correctamente los administradores¶
Establecer las direcciones de administrador correctas a la configuración ADMINS para definir quién recibirá correos electrónicos en caso de que algo salga mal en el servidor, por ejemplo:
ADMINS = ("Your Name <your_email@example.com>",)
Ver también
Establecer el dominio del sitio correcto¶
Ajuste el nombre del sitio y el dominio en la interfaz administrativa; de lo contrario, los enlaces en RSS o correos electrónicos de registro no funcionarán. Esto se configura usando SITE_DOMAIN que debe contener el nombre de dominio del sitio.
Distinto en la versión 4.2: Antes de la versión 4.2, se usaba el framework Django en su lugar, ver The «sites» framework.
Configurar HTTPS correctamente¶
Se recomienda encarecidamente ejecutar Weblate utilizando el protocolo HTTPS cifrado. Tras habilitarlo, deberá configurar ENABLE_HTTPS en los ajustes:
ENABLE_HTTPS = True
Consejo
Quizá desea configurar bien el HSTS, consulte SSL/HTTPS para obtener más detalles.
Establecer correctamente SECURE_HSTS_SECONDS¶
Si su sitio se sirve a través de SSL, debe considerar establecer un valor para SECURE_HSTS_SECONDS en el settings.py para habilitar la Seguridad Estricta de Transporte HTTP. De forma predeterminada, está configurado en 0 como se muestra a continuación.
SECURE_HSTS_SECONDS = 0
Si se establece en un valor entero distinto de cero, la django.middleware.security.SecurityMiddleware fija el encabezado HTTP Strict Transport Security en todas las respuestas que aún no lo tienen.
Advertencia
Configurar esto incorrectamente puede romper irreversiblemente (durante algún tiempo) su sitio. Lea primero la documentación HTTP Strict Transport Security.
Utilice un motor potente de base de datos¶
Utilice PostgreSQL para un entorno de producción, consulte Configuración de base de datos para Weblate para más información.
Utilice lugar adjunto para ejecutar el servidor de base de datos, en otro caso el rendimiento de la red o fiabilidad quizá arruine su experiencia de Weblate.
Compruebe el rendimiento del servidor de la base de datos o ajuste su configuración, p.ej. utilizando PGTune.
Configurar caché¶
Si es posible, utilice Valkey o Redis desde Django ajustando la variable de configuración CACHES, por ejemplo:
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",
},
}
}
Consejo
En caso que cambie parámetros para la caché, quizá necesite ajustarlos para Celery también, consulte Tareas en segundo plano con Celery.
Ver también
Caché de avatar¶
En adición a cacheo de Django, Weblate realiza cacheo de avatares. Está recomendado para utilizar un separado, caché de archivo-respaldado para este propósito:
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,
},
},
}
Configure envío de correo-e¶
Weblate necesita enviar correos electrónicos en algunas ocasiones, y estos correos electrónicos han de tener correcta una dirección de remitente, configure SERVER_EMAIL y DEFAULT_FROM_EMAIL para que coincidan con su entorno, por ejemplo:
SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"
Nota
Para desactivar el envío de correo-e por Weblate establezca EMAIL_BACKEND a django.core.mail.backends.dummy.EmailBackend.
Esto desactivará todas las entregas de correo-e incluyendo registración o correos-e de restauración de contraseña.
Configuración de huéspedes permitidos¶
Django requiere ALLOWED_HOSTS para mantener una lista de nombres de dominio que su sitio puede servir, dejarla vacía bloqueará cualquier solicitud.
Es caso que esto no esté configurado para coincidir con su servidor HTTP, obtendrá errores como Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.
Consejo
En el contenedor Docker, esto está disponible como WEBLATE_ALLOWED_HOSTS.
Clave secreta de Django¶
Django usa la configuración SECRET_KEY para firmar cookies, y realmente debería generar su propio valor en lugar de usar el de la configuración de ejemplo.
Puede generar una nueva clave usando weblate-generate-secret-key enviado con Weblate.
Ver también
Efectuar tareas de mantenimiento¶
Para un rendimiento óptimo, es una buena idea ejecutar algunas tareas de mantenimiento en segundo plano. Esto se hace automáticamente mediante Tareas en segundo plano con Celery y cubre las siguientes tareas:
Comprobación del estado de la configuración (cada hora).
Consolidar los cambios pendientes (horariamente), consulte Consolidaciones diferidas y
commit_pending.Actualizar alertas de componente (diariamente).
Actualice ramas remotas (todas las noches), consulte
AUTO_UPDATE.Respaldar memoria de traducción a JSON (diariamente), consulte
dump_memory.Tareas de mantenimiento de base de datos y texto completo (tareas diarias y semanalmente), consulte
cleanuptrans.
Sistemas locales y codificación¶
Las configuraciones regionales del sistema deben configurarse para que sean compatibles con UTF - 8. En la mayoría de las distribuciones de Linux, esta es la configuración predeterminada. En caso de que no sea el caso en su sistema, cambie las configuraciones regionales a la variante UTF-8.
Por ejemplo, editando /etc/default/locale y configurando allí LANG="C.UTF-8".
En algunos casos, los servicios individuales tienen una configuración separada para las configuraciones regionales. Esto varía entre la distribución y los servidores web, así que consulte la documentación de los paquetes de su servidor web para eso.
Apache en Ubuntu usa /etc/apache2/envvars:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Apache en CentOS usa /etc/sysconfig/httpd (o /opt/rh/httpd24/root/etc/sysconfig/httpd):
LANG='en_US.UTF-8'
Comprimir bienes cliente¶
Weblate viene con un montón de archivos JavaScript y CSS. Por razones de rendimiento, es bueno comprimirlos antes de enviarlos a un cliente. En la configuración predeterminada, esto se hace sobre la marcha a un costo de poca sobrecarga. En instalaciones grandes, se recomienda habilitar el modo de compresión sin conexión. Esto debe hacerse en la configuración y la compresión debe activarse en cada migración de Weblate.
El interruptor de configuración es simple al habilitar django.conf.settings.COMPRESS_OFFLINE y configurando django.conf.settings.COMPRESS_OFFLINE_CONTEXT (este último ya está incluido en la configuración de ejemplo):
COMPRESS_OFFLINE = True
En cada implementación, debe comprimir los archivos para que coincidan con la versión actual:
weblate compress
Consejo
La imagen oficial para Docker ya tiene activada esta funcionalidad.
Ejecutar servidor¶
Consejo
En caso de no experimentado con servicios descritos a continuación, al vez desea intentar con Instalar con Docker.
Es necesario contar con varios servicios para ejecutar Weblate. El montaje recomendado consiste de:
Servidor de base de datos (consulte Configuración de base de datos para Weblate)
Servidor de antememoria (consulte Configurar caché)
Servidor web frontend para archivos estáticos y terminación SSL (ver Sirviendo archivos estáticos)
Servidor WSGI para el contenido dinámico (consulte Muestra de configuración para NGINX y uWSGI)
Celery para ejecutar las tareas en segundo plano (consulte Tareas en segundo plano con Celery)
Nota
Hay algunas dependencias entre los servicios, p.e. caché y base de datos estarían ejecutándose cuando inicie Celery o procesos uwsgi.
En la mayoría de los casos, ejecutará todos los servicios en un solo servidor (virtual), pero en caso de que su instalación tenga una gran carga, puede dividir los servicios. La única limitación en esto es que los servidores Celery y Wsgi necesitan acceso a DATA_DIR.
Nota
El proceso WSGI tiene que ser ejecutado bajo el mismo usuario que el proceso Celery, de lo contrario los archivos en el DATA_DIR se almacenarán con propiedad mixta, dando lugar a incidencias en tiempo de ejecución.
Además consulte Permisos del sistema de archivos y Tareas en segundo plano con Celery.
Ejecutar servidor web¶
Ejecutar Weblate no es diferente de ejecutar cualquier otro programa basado en Django. Django generalmente se ejecuta como WSGI o fcgi (consulte los ejemplos de diferentes servidores web a continuación).
Nota
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.
Para fines de prueba, puede usar el servidor web incorporado en Django:
weblate runserver
Advertencia
NO USE ESTE SERVIDOR EN UN AJUSTE DE PRODUCCIÓN. No ha pasado por auditorías de seguridad ni pruebas de rendimiento. Consulte también la documentación de Django en runserver.
Consejo
El servidor incorporado de Django sirve archivos estáticos solo con DEBUG habilitado ya que está destinado solo para desarrollo. Para uso en producción, consulte configuraciones de WSGI:
Sirviendo archivos estáticos¶
Distinto en la versión 5.15.2: /media/ no es utilizado más para servir capturas de pantalla.
Django necesita recopilar sus archivos estáticos en un solo directorio. Para ello, ejecute weblate collectstatic --noinput. Esto copiará los archivos estáticos en un directorio especificado por los ajustes de STATIC_ROOT (esto por defecto es un directorio static interno a CACHE_DIR).
Se recomienda servir archivos estáticos directamente desde su servidor web, debe usarlo para las siguientes rutas:
/static/Sirve archivos estáticos para Weblate y la interfaz administrativa (definido por
STATIC_ROOT)./favicon.icoDebería reescribirse para reescribir una regla para servir
/static/favicon.ico.
Ver también
Política de seguridad de contenido¶
La configuración predeterminada de Weblate habilita weblate.middleware.SecurityMiddleware que establece encabezados HTTP relacionados con la seguridad como Content-Security-Policy o X-XSS-Protection. Estos están configurados de forma predeterminada para funcionar con Weblate y su configuración, pero es posible que deba personalizarlos para su entorno.
Configuración de muestra para NGINX y Granian¶
La siguiente configuración ejecuta Weblate usando Granian el servidor web NGINX:
#
# 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;
}
}
Configuración de muestra para NGINX y 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;
}
}
Muestra de configuración para NGINX y uWSGI¶
Para ejecutar el servidor web de producción, utilice el contenedor WSGI instalado con Weblate (cuando utiliza un entorno de Python esté instalado como ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py). No olvide establecer también la ruta de búsqueda de Python en su entorno de Python también (p.e., usando virtualenv = /home/user/weblate-env en uWSGI).
La siguiente configuración ejecuta Weblate como uWSGI en el servidor 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
Ver también
Configuración de ejemplo para Apache¶
Se recomienda usar prefork MPM cuando se usa WSGI con 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>
Nota
Weblate requiere Python 3, así que asegúrese de estar ejecutando la variante Python 3 de modwsgi. Por lo general, está disponible como un paquete separado, por ejemplo libapache2-mod-wsgi-py3.
Utilice la versión de Python coincidente para instalar Weblate.
Configuración de muestra para Apache y 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>
Configuración de muestra para iniciar Granian¶
Weblate tiene una dependencia opcional “wsgi`(ver Dependencias de Python) que instalará todo lo que necesita para ejecutar Granian. Al instalar Weblate, puede especificarlo como:
uv pip install Weblate[all,wsgi]
Una vez que haya instalado Granian, puede ejecutarlo. Esto generalmente se hace a nivel del sistema. Los siguientes ejemplos muestran cómo comenzar a través de 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
~
Configuración de muestra para iniciar Gunicorn¶
Gunicorn tiene que estar instalado por separado:
uv pip install gunicorn
Una vez que haya instalado Gunicorn, puede ejecutarlo. Esto generalmente se hace a nivel del sistema. Los siguientes ejemplos muestran cómo comenzar a través de 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
Ver también
Ejecución de Weblate en path¶
Se recomienda usar prefork MPM cuando se usa WSGI con 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>
Además, tendrá que ajustar weblate/settings.py:
URL_PREFIX = "/weblate"
Tareas en segundo plano con Celery¶
Weblate utiliza Celery para ejecutar tareas usuarios y en segundo plano. Está admitido ejecutar un servicio Celery que ejecutará estos. Por ejemplo, es responsable para manipular operaciones siguientes (este listado no es completo):
Recepción de webhooks desde servicios externos (consulte Actuadores de notificación).
Ejecutando tareas de mantenimiento regular tales como respaldos, vaciados, adjuntos diarios, o actualizacones (consulte Respaldar y trasladar Weblate,
BACKGROUND_TASKS, Complementos).Ejecutando Traducción automática.
Enviar notificaciones con el resumen.
Descarga de costosas operaciones del proceso WSGI.
Consolidar los cambios pendientes (consulte Consolidaciones diferidas).
Una configuración típica que utiliza Valkey o Redis como un backend se ve como esto:
CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL
Ver también
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
Nota
El proceso Celery tiene que ser ejecutado bajo el mismo usuario que el proceso WSGI, de lo contrario los archivos en el DATA_DIR se almacenarán con propiedad mixta, dando lugar a incidencias en tiempo de ejecución.
Consulte también Permisos del sistema de archivos y Ejecutar servidor.
Ejecución de tareas de Celery en el WSGI usando el modo automático¶
Nota
Esto tendrá un impacto claro en el rendimiento de la interfaz web y romperá las funciones según el desencadenante habitual(por ejemplo, consolidando cambios pendientes, notificaciones resumidas o copias de seguridad).
Para el desarrollo, es posible que desee utilizar una configuración fija, que procesa todas las tareas en su lugar:
CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True
Ejecutando Celery como servicio del sistema¶
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.
Unidad Systemd que se colocará como /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
Configuración del entorno que se colocará como /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"
Configuración adicional para rotar logs de Celery usando logrotate para colocarlos como /etc/logrotate.d/celery:
/var/log/celery/*.log {
weekly
missingok
rotate 12
compress
notifempty
}
Tareas periódicas usando Celery¶
Weblate viene con una configuración incorporada para tareas programadas. El programa de tareas se almacena en la base de datos y las tareas son ejecutadas por el demonio Celery.
Consejo
Puede definir tareas adicionales en settings.py, por ejemplo consulte Consolidaciones diferidas.
Monitoreo del estado de Celery¶
Puede encontrar la longitud actual de las colas de tareas de Celery en el Interfaz administrativa o puede usar celery_queues en la línea de comandos. En el caso de que la cola sea demasiado larga, también obtendrá un error de configuración en la interfaz administrativa.
Advertencia
Los errores de Celery solo se registran de forma predeterminada en el registro de Celery y no son visibles para el usuario. En caso de que desee tener una visión general de dichos fallos, se recomienda configurar Recopilación de informes de errores y supervisión del rendimiento.
Configuración de Celery de un solo proceso¶
En caso de que tenga una memoria muy limitada, es posible que desee reducir el número de procesos de Weblate. Todas las tareas de Celery se pueden ejecutar en un solo proceso usando:
celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo
Una instalación que usa Docker se puede configurar para usar una configuración de Celery de un solo proceso configurando CELERY_SINGLE_PROCESS.
Advertencia
Esto tendrá un impacto notable en el rendimiento de Weblate.
Monitorizar Weblate¶
Weblate proporciona la URL /healthz/ que se utilizará en comprobaciones de estado simples, por ejemplo, utilizando Kubernetes. El contenedor Docker tiene una verificación de estado incorporada usando esta URL.
Para monitoreo las métricas de Weblate, puede usar GET /api/metrics/ punto final del API.
Recopilación de informes de errores y supervisión del rendimiento¶
Weblate, como cualquier otro software, puede fallar. Para recopilar estados de falla útiles, recomendamos utilizar servicios de terceros para recopilar dicha información. Esto es especialmente útil en caso de fallas en las tareas de Celery, que de lo contrario solo informarían errores a los registros y no se le notificará sobre ellos. Weblate tiene soporte para los siguientes servicios:
Correo-e¶
La configuración predeterminada de Weblate implementa que Django envíe correos-e en caso de errores del servidor mediante django.utils.log.AdminEmailHandler. Esta es la configuración más sencilla, pero debería considerar otras opciones por motivos de privacidad, ya que los errores de correo-e podrían incluir datos confidenciales. Puede obtener más información en Implicaciones de seguridad.
Para inhabilitar este comportamiento, retire mail_admins de LOGGING en los ajustes de Weblate, o inhabilite WEBLATE_ADMIN_NOTIFY_ERROR en el entorno de Docker.
Sentry¶
Weblate tiene soporte incorporado para Sentry. Para usarlo, basta con configurar SENTRY_DSN en el settings.py:
SENTRY_DSN = "https://id@your.sentry.example.com/"
Sentry también se puede usar para monitorear el rendimiento de Weblate al recopilar rastros y perfiles para un porcentaje definido de operaciones. Esto se puede configurar usando SENTRY_TRACES_SAMPLE_RATE y SENTRY_PROFILES_SAMPLE_RATE.
Ver también
Revertir¶
Weblate tiene mantenimiento integrado para`Rollbar <https://rollbar.com/>`_. Para usarlo, basta con seguir las instrucciones para Notificador de barra de desplazamiento para Python.
En resumen, necesitas 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",
}
Todo lo demás se integra automáticamente, ahora recopilará errores del lado del servidor y del cliente.
Nota
El registro de errores también incluye excepciones que se manejaron correctamente, pero que podrían indicar un problema , como un análisis fallido de un archivo cargado.
Gestión de registros de Graylog¶
Added in version 5.9.
Weblate se puede configurar para iniciar sesión utilizando el protocolo GELF TCP. Esto fue desarrollado para la integración de Graylog, pero se puede usar con cualquier plataforma de registro compatible.
La placa repetitiva de configuración está incluida en Configuración de muestra, para Docker, esto se puede configurar usando WEBLATE_LOG_GELF_HOST.
Migrar Weblate a otro servidor¶
Migrar Weblate a otro servidor debería ser bastante fácil, sin embargo, almacena datos en pocos lugares que debe migrar con cuidado. El mejor enfoque es detener Weblate para la migración.
Migrar base de datos¶
El enfoque más sencillo es utilizar herramientas nativas de la base de datos, ya que suelen ser las más efectivas (p.ej. pg_dump). Alternativamente puede usar replicación si su base de datos lo admita.
Ver también
Migración entre bases de datos descrita en Migrar desde otras bases de datos a PostgreSQL.
Migrar repositorios VCS¶
Los repositorios de VCS almacenados en DATA_DIR necesita migrarse también. Simplemente puede copiarlos o usar rsync para hacer la migración de manera más efectiva.
Otras notas¶
No olvide trasladar los otros servicios que Weblate esté utilizando, como Valkey, Redis, o tareas de Cron para backend de autenticación personales.