Instalar con Docker¶

Con la implementación de Weblate para docker, puede poner en funcionamiento su instancia personal de Weblate en cuestión de segundos. Todas las dependencias de Weblate ya están incluidas. PostgreSQL está configurado como la base de datos predeterminada y Redis como backend de almacenamiento en caché.

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, Single-process Celery setup 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).

Instalación¶

Consejo

Los ejemplos siguientes presuponen que tiene un entorno Docker de trabajo, con docker-compose-plugin instalada. Consulte la documentación de Docker para obtener instrucciones.

Esto crea un servidor de implementación de Weblate a través de HTTP, por lo que debe colocarlo detrás del proxy de terminación HTTPS. También puede implementar con un proxy HTTPS, ver Certificados SSL automáticos con Let’s Encrypt. Para configuraciones mayores, ver Scaling horizontally.

Clone el repositorio weblate-docker:

git clone https://github.com/WeblateOrg/docker-compose.git weblate-docker
cd weblate-docker

Crear un archivo docker-compose.override.yml con tus configuraciones. Ver Docker environment variables para la lista completa de variables de entorno.

services:
  weblate:
    image: weblate/weblate:latest
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SERVER_EMAIL: weblate@example.com
      WEBLATE_DEFAULT_FROM_EMAIL: weblate@example.com
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for the admin user
      WEBLATE_ADMIN_EMAIL: weblate.admin@example.com
    ports:
    - 80:8080

Nota

Sí WEBLATE_ADMIN_PASSWORD no está configurado, el usuario administrador se crea con una contraseña aleatoria que se muestra en el primer inicio.

El ejemplo proporcionado hace que Weblate escuche en el puerto 80, edite la asignación de puertos en el: archivo docker-compose.override.yml para cambiarlo.

Inicie los contenedores de Weblate:
```
docker compose up
```

Disfrute de su implementación de Weblate, es accesible en el puerto 80 del contenedor weblate.

Ver también

Invocar órdenes de gestión

Elección del registro de imágenes de Docker¶

Los contenedores de Weblate se publican en los siguientes registros:

Hub Docker, consulte https://hub.docker.com/r/weblate/weblate
Registro de Paquetes GitHub, consulte https://github.com/WeblateOrg/docker/pkgs/container/weblate

Nota

Todos los ejemplos actualmente obtienen imágenes de Docker Hub, ajuste la configuración en consecuencia para usar un registro diferente.

Elija segmento de imagen de Docker¶

Elija un segmento que coincida con su entorno y esperanzas:

Nombre de segmento	Descripción	Caso de uso
`latest`	Lanzamiento estable de Weblate, coincide con el último lanzamiento etiquetado	Rolling updates in a production environment
`<MAJOR>`	Versión estable de Weblate	Rolling updates within a major version in a production environment
`<MAJOR>.<MINOR>`	Versión estable de Weblate	Rolling updates within a minor version in a production environment
`<VERSION>.<PATCH>`	Versión estable de Weblate	Well defined deploy in a production environment
`edge`	Weblate stable release with development changes in the Docker container (for example updated dependencies)	Rolling updates in a staging environment
`edge-<DATE>-<SHA>`	Weblate stable release with development changes in the Docker container (for example updated dependencies)	Well defined deploy in a staging environment
`bleeding`	Versión de desarrollo Weblate desde Git	Actualizaciones continuas para probar las próximas funciones de Weblate
`bleeding-<DATE>-<SHA>`	Versión de desarrollo Weblate desde Git	Implementación bien definida para probar las próximas funciones de Weblate

Cada imagen la prueba nuestro CI antes de que se publique, por lo que incluso la versión «desteñida» debería ser bastante segura de usar.

La lista completa de etiquetas publicadas se puede encontrar en GitHub Packages

Contenedor Docker con compatibilidad con HTTPS¶

Ver Instalación para las instrucciones de implementación genéricas, esta sección solo menciona diferencias en comparación con ella.

Proxy de terminación SSL¶

SSL se puede terminar fuera del contenedor de Weblate. Para que esto funcione bien en conjunto, es necesario pasar varios encabezados al contenedor para que conozca su entorno real. Con más detalle, estos encabezados se describen en Ejecutar en proxy reverso.

Ejemplo de configuración de proxy inverso nginx para un contenedor Docker.¶

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 3600s;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
}

Entorno de contenedor Docker para terminación SSL externa.¶

WEBLATE_ENABLE_HTTPS=1
WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR

Utilizar certificados SSL propios¶

In case you have own SSL certificate you want to use, simply place the files into the Weblate data volume (see Volúmenes de contenedores Docker):

ssl/fullchain.pem, que contiene el certificado SSL y cualquier certificado CA que se necesite
ssl/privkey.pem, que contiene la clave privada

Both of these files must be owned by the same user as the one starting the docker container and have file mask set to 600 (readable and writable only by the owning user).

Additionally, Weblate container will now accept SSL connections on port 4443, you will want to include the port forwarding for HTTPS in docker compose override:

version: '3'
services:
  weblate:
    ports:
      - 80:8080
      - 443:4443

Si ya aloja otros sitios en el mismo servidor, es probable que los puertos 80 y 443 sean utilizados por un proxy inverso, como NGINX. Para pasar la conexión HTTPS de NGINX al contenedor docker, puede usar la siguiente configuración:

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name <SITE_URL>;
    ssl_certificate /etc/letsencrypt/live/<SITE>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<SITE>/privkey.pem;

    location / {
            proxy_set_header HOST $host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_pass https://127.0.0.1:<EXPOSED_DOCKER_PORT>;
    }
}

Sustituir <SITE_URL>, <SITE> y <EXPOSED_DOCKER_PORT> con valores reales de su entorno.

Certificados SSL automáticos con Let’s Encrypt¶

En caso de que quieras usar “Let’s Encrypt <https://letsencrypt.org/>” _ certificados SSL generados automáticamente en la instalación pública, debe agregar un proxy HTTPS inverso y un contenedor Docker adicional, “ https-portal <https://hub.docker.com/r/steveltn/https-portal/>`_ se usará para eso. Esto se hace uso de en el archivo docker-compose-https.yml. Luego cree un archivo docker-compose-https.override.yml con su configuración:

version: '3'
services:
  weblate:
    environment:
      WEBLATE_EMAIL_HOST: smtp.example.com
      WEBLATE_EMAIL_HOST_USER: user
      WEBLATE_EMAIL_HOST_PASSWORD: pass
      WEBLATE_SITE_DOMAIN: weblate.example.com
      WEBLATE_ADMIN_PASSWORD: password for admin user
  https-portal:
    environment:
      DOMAINS: 'weblate.example.com -> http://weblate:8080'

Siempre que invoque docker compose debe pasarle ambos archivos y luego hacer:

docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml build
docker compose -f docker-compose-https.yml -f docker-compose-https.override.yml up

Actualizar el contenedor de Docker¶

Por lo general, es una buena idea actualizar solo el contenedor Weblate y mantener el contenedor PostgreSQL en la versión que tiene, ya que actualizar PostgreSQL es bastante molesto y, en la mayoría de los casos, no brinda muchos beneficios.

Distinto en la versión 4.17-1: Desde Weblate 4.17 - 1, el contenedor Docker usa Django 4.2, lo que requiere PostgreSQL 12 o posterior, actualícelo antes de actualizar Weblate. Ver Actualización del contenedor de PostgreSQL.

Puede hacer esto siguiendo con la composición de docker existente y simplemente extrayendo las últimas imágenes y luego reiniciando:

# Fetch latest versions of the images
docker compose pull
# Stop and destroy the containers
docker compose down
# Spawn new containers in the background
docker compose up -d
# Follow the logs during upgrade
docker compose logs -f

La base de datos de Weblate debería migrarse automáticamente la primera vez que se inicie, y no debería ser necesario realizar acciones manuales adicionales.

Nota

Weblate no admite actualizaciones entre versiones principales. Por ejemplo, si estás en la serie 3.x y quieres actualizar a la 4.x, primero actualiza a la última imagen 4.0.x-y (en el momento de escribir esto es la 4.0.4-5), que hará la migración y luego continuar actualizando a versiones más recientes.

También es posible que desee actualizar el repositorio docker-compose aunque en la mayoría de los casos no sea necesario. Ver Actualización del contenedor de PostgreSQL para actualizar el servidor PostgreSQL.

Actualización del contenedor de PostgreSQL¶

Los contenedores de PostgreSQL no admiten la actualización automática entre versiones, debe realizar la actualización manualmente. Los siguientes pasos muestran una de las opciones de actualización.

Ver también

https://github.com/docker-library/postgres/issues/37

Detener el contenedor de Weblate:
```
docker compose stop weblate cache
```

Copia de seguridad de la base de datos:

docker compose exec database pg_dumpall --clean --if-exists --username weblate > backup.sql

Detenga el contenedor de la base de datos:
```
docker compose stop database
```
Elimine el volumen PostgreSQL:
```
docker compose rm -v database
docker volume remove weblate-docker_postgres-data
```
Consejo

El nombre del volumen contiene el nombre del proyecto Docker Compose, que por defecto es el nombre del directorio que es weblate-docker en esta documentación.
Adjustar docker-compose.yml para usar la nueva versión de PostgreSQL.
Inicie el contenedor de la base de datos:
```
docker compose up -d database
```
Restaurar la base de datos a partir de la copia de seguridad:
```
cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate
```
Consejo

Verificar que el nombre de la base de datos coincida POSTGRES_DB.
(Opcional) Actualizar la contraseña del usuario de Weblate. Esto podría ser necesario al migrar a PostgreSQL 14 o 15, ya que se ha cambiado la forma de almacenar contraseñas:
```
docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"
```
Consejo

Verificar que el nombre de la base de datos coincida POSTGRES_DB.
Inicie todos los contenedores restantes:
```
docker compose up -d
```

Iniciar la sesión cómo administrador¶

Después de la configuración del contenedor, puede iniciar sesión como usuario “administrador” con la contraseña proporcionada en WEBLATE_ADMIN_PASSWORD, o una contraseña aleatoria generada en el primer inicio si no se estableció.

Para restablecer la contraseña de administrador, reiniciar el contenedor con WEBLATE_ADMIN_PASSWORD con la nueva contraseña.

Ver también

WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Número de procesos y consumo de memoria¶

El número de procesos de trabajo tanto para WSGI como para Celery se determina automáticamente en función del número de CPU. Esto funciona bien para la mayoría de las máquinas virtuales en la nube, ya que generalmente tienen pocas CPU y una buena cantidad de memoria.

En caso de que tenga muchos núcleos de CPU y se quede sin memoria, intente reducir la cantidad de trabajos:

environment:
  WEBLATE_WORKERS: 2

También puede ajustar las categorías individuales de los trabajadores:

environment:
  WEB_WORKERS: 4
  CELERY_MAIN_OPTIONS: --concurrency 2
  CELERY_NOTIFY_OPTIONS: --concurrency 1
  CELERY_TRANSLATE_OPTIONS: --concurrency 1

Memory usage can be further reduced by running only a single Celery process:

environment:
  CELERY_SINGLE_PROCESS: 1

Ver también

WEBLATE_WORKERS
CELERY_MAIN_OPTIONS
CELERY_NOTIFY_OPTIONS
CELERY_MEMORY_OPTIONS
CELERY_TRANSLATE_OPTIONS
CELERY_BACKUP_OPTIONS
CELERY_BEAT_OPTIONS
CELERY_SINGLE_PROCESS
WEB_WORKERS

Scaling horizontally¶

Added in version 4.6.

You can run multiple Weblate containers to scale the service horizontally. The /app/data volume has to be shared by all containers, it is recommended to use cluster filesystem such as GlusterFS for this. The /app/cache volume should be separate for each container.

Each Weblate container has defined role using WEBLATE_SERVICE environment variable. Please follow carefully the documentation as some of the services should be running just once in the cluster, and the order of the services matters as well.

You can find example setup in the docker-compose repo as docker-compose-split.yml.

Docker environment variables¶

Many of Weblate’s Configuración can be set in the Docker container using the environment variables described below.

Si necesita definir una configuración que no esté expuesta a través de las variables de entorno de Docker, ver Configuración más allá de las variables de entorno.

Pasando secretos¶

Added in version 5.0.

El contenedor Weblate admite pasar secretos como archivos. Para utilizar eso, agregar el sufijo _FILE a la variable de entorno y pase el archivo secreto a través de Docker.

Relacionado docker-compose.yml podría verse así:

services:
   weblate:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password
   database:
      environment:
         POSTGRES_PASSWORD_FILE: /run/secrets/db_password
      secrets:
         - db_password


secrets:
   db_password:
     file: db_password.txt

Ver también

Cómo usar secretos en Docker Compose

Ajustes genéricos¶

WEBLATE_DEBUG¶

Configura el modo de depuración de Django usando DEBUG.

Ejemplo:

environment:
  WEBLATE_DEBUG: 1

Ver también

Desactivar el modo de depuración

WEBLATE_LOGLEVEL¶

Configurar la verbosidad del registro. Establecer esto en DEBUG para obtener registros más detallados.

El valor predeterminado es INFO cuando WEBLATE_DEBUG está desactivado, DEBUG se usa cuando el modo de depuración está activado.

For more silent logging use ERROR or WARNING.

WEBLATE_LOGLEVEL_DATABASE¶: Configures the logging of the database queries verbosity.

WEBLATE_LOG_GELF_HOST¶: Added in version 5.9.

Configures remote logging using GELF TCP connection. Can be used to integrate with Graylog.

WEBLATE_LOG_GELF_PORT¶: Added in version 5.9.

Use custom port for WEBLATE_LOG_GELF_HOST, defaults to 12201.

WEBLATE_SITE_TITLE¶: Modifica el título del sitio que se muestra en la cabecera de todas las páginas.

WEBLATE_SITE_DOMAIN¶

Configura el dominio del sitio. Este parámetro es obligatorio.

Include port if using a non-standard one.

Ejemplo:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

Ver también

WEBLATE_ADMIN_NAME¶

WEBLATE_ADMIN_EMAIL¶

Configures the site-admin’s name and e-mail. It is used for both ADMINS setting and creating admin user (see WEBLATE_ADMIN_PASSWORD for more info on that).

Ejemplo:

environment:
  WEBLATE_ADMIN_NAME: Weblate admin
  WEBLATE_ADMIN_EMAIL: noreply@example.com

Ver también

WEBLATE_ADMIN_PASSWORD¶

Establece la contraseña para el usuario admin.

Si no se establece y el usuario admin no existe, se crea con una contraseña aleatoria que se muestra en el primer inicio del contenedor.
Si no se establece y existe el usuario admin, no se realiza ninguna acción.
Si está configurado, el usuario admin se ajusta en cada inicio del contenedor para que coincida WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME y WEBLATE_ADMIN_EMAIL.

Advertencia

Puede ser un riesgo para la seguridad almacenar la contraseña en el archivo de configuración. Piense usar esta variable solo para la configuración inicial (o deje que Weblate genere una contraseña aleatoria en el inicio inicial) o para la recuperación de la contraseña.

Ver también

Iniciar la sesión cómo administrador
Pasando secretos
WEBLATE_ADMIN_PASSWORD
WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_NOTIFY_ERROR¶

Si se enviara un correo a los administradores en caso de error del servidor. Activado por defecto.

Es posible que desee utilizar otra recopilación de errores como Sentry o Rollbar y desactivarla.

Ver también

WEBLATE_SERVER_EMAIL¶

La dirección de correo desde la que se envían los mensajes de error.

Ver también

WEBLATE_DEFAULT_FROM_EMAIL¶

Configura la dirección de los correos electrónicos salientes.

Ver también

WEBLATE_ADMINS_CONTACT¶: Configures ADMINS_CONTACT.

WEBLATE_CONTACT_FORM¶: Configura el comportamiento del formulario de contacto, ver CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS¶

Configura los nombres de host HTTP permitidos mediante ALLOWED_HOSTS.

El valor predeterminado es *, que permite todos los nombres de anfitrión.

Ejemplo:

environment:
  WEBLATE_ALLOWED_HOSTS: weblate.example.com,example.com

Ver también

WEBLATE_REGISTRATION_OPEN¶

Configura si los registros están abiertos al alternar REGISTRATION_OPEN.

Ejemplo:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_CAPTCHA¶

Added in version 5.10.

Configura si se usa captcha para el registro y otras acciones no autenticadas, ver REGISTRATION_CAPTCHA.

Ejemplo:

environment:
  WEBLATE_REGISTRATION_CAPTCHA: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS¶

Configure qué métodos de autenticación se pueden utilizar para crear una nueva cuenta a través de REGISTRATION_ALLOW_BACKENDS.

Ejemplo:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
  WEBLATE_REGISTRATION_ALLOW_BACKENDS: azuread-oauth2,azuread-tenant-oauth2

WEBLATE_REGISTRATION_REBIND¶: Added in version 4.16.

Configura REGISTRATION_REBIND.

WEBLATE_TIME_ZONE¶

Configura el huso horario utilizado en Weblate; consulte TIME_ZONE.

Nota

Para cambiar el huso horario del contenedor Docker, utilice la variable de entorno TZ.

Ejemplo:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS¶

Hace que Weblate asuma que funciona detrás de un proxy HTTPS inverso, hace que Weblate use HTTPS en el correo electrónico y los enlaces API o establezca indicadores de seguridad en las cookies.

Consejo

Consulte la documentación de ENABLE_HTTPS para advertencias posibles.

Nota

Esto no hace que el contenedor de Weblate acepte las conexiones HTTPS; debe configurarlas también. Vea Contenedor Docker con compatibilidad con HTTPS para obtener ejemplos.

Ejemplo:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Ver también

WEBLATE_INTERLEDGER_PAYMENT_BUILTIN¶: Added in version 5.11.

Configurar INTERLEDGER_PAYMENT_BUILTIN.

WEBLATE_INTERLEDGER_PAYMENT_POINTERS¶: Added in version 4.12.1.

Permite que Weblate establezca el campo`meta[name=monetization]`en el encabezado del documento. Si se especifican varios, elija uno al azar..

Ver también

INTERLEDGER_PAYMENT_POINTERS

WEBLATE_IP_PROXY_HEADER¶

Permite que Weblate recupere la dirección IP de cualquier cabecera HTTP que se indique. Utilice esta variable si usa un «proxy» inverso ante el contenedor de Weblate.

Habilita IP_BEHIND_REVERSE_PROXY y configura IP_PROXY_HEADER.

Nota

El formato debe ajustarse a las expectativas de Django. Django transforma los nombres de los encabezados transforms raw HTTP de la siguiente manera:

convierte todas las letras en mayúsculas
sustituye cualquier guion por guiones bajos
antepone el prefijo HTTP_

Así X-Forwarded-For se asignaría a HTTP_X_FORWARDED_FOR.

Ejemplo:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_IP_PROXY_OFFSET¶: Added in version 5.0.1.

Configura IP_PROXY_OFFSET.

WEBLATE_USE_X_FORWARDED_PORT¶: Added in version 5.0.1.

Un valor booleano que especifica si se debe usar el encabezado X-Forwarded-Port con preferencia a la variable SERVER_PORT META. Esto solo debe habilitarse si se está utilizando un proxy que establece este encabezado.

Ver también

USE_X_FORWARDED_PORT

Nota

Esta es una configuración booleana (usar "true" o "false").

WEBLATE_SECURE_PROXY_SSL_HEADER¶

Una tupla que representa una combinación de encabezado/valor HTTP que significa que una solicitud es segura. Esto es necesario cuando Weblate se ejecuta detrás de un proxy inverso que realiza la terminación SSL que no pasa los encabezados HTTPS estándar.

Ejemplo:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Ver también

WEBLATE_REQUIRE_LOGIN¶

Habilita REQUIRE_LOGIN la autenticación en todo Weblate.

Ejemplo:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS¶

Agrega excepciones de URL para la autenticación requerida para toda la instalación de Weblate usando LOGIN_REQUIRED_URLS_EXCEPTIONS.

Puede sustituir toda la configuración o modificar el valor predeterminado mediante las variables ADD y REMOVE.

Para aplicar la autenticación al formulario de contacto, haga lo siguiente:

environment:
  WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$

WEBLATE_GOOGLE_ANALYTICS_ID¶: Configura el ID de Google Analytics cambiando GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE¶: Configures the default title and message for pull requests via API by changing DEFAULT_PULL_MESSAGE.

Ver también

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES¶: Configures the language simplification policy, see SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL¶: Configures the default Control de acceso for new projects, see DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT¶: Configures the default value for Acceso restringido for new components, see DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION¶: Configures the default value for Permitir propagación de traducciones for new components, see DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL¶: Configura DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME¶: Configura DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM¶: Configura DEFAULT_SHARED_TM.

WEBLATE_DEFAULT_AUTOCLEAN_TM¶: Configures DEFAULT_AUTOCLEAN_TM.

WEBLATE_AKISMET_API_KEY¶: Configura la clave de API de Akismet; consulte AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY¶: Configura la firma con GPG de las consignas; consulte WEBLATE_GPG_IDENTITY.

Ver también

Signing Git commits with GnuPG

WEBLATE_URL_PREFIX¶: Configures URL prefix where Weblate is running, see URL_PREFIX.

WEBLATE_MEDIA_URL¶: Configures URL that handles the media served from MEDIA_ROOT.

WEBLATE_STATIC_URL¶: Configures URL prefix for static files server from CACHE_DIR.

WEBLATE_SILENCED_SYSTEM_CHECKS¶: Configures checks which you do not want to be displayed, see SILENCED_SYSTEM_CHECKS.

WEBLATE_CSP_SCRIPT_SRC¶

WEBLATE_CSP_IMG_SRC¶

WEBLATE_CSP_CONNECT_SRC¶

WEBLATE_CSP_STYLE_SRC¶

WEBLATE_CSP_FONT_SRC¶

WEBLATE_CSP_FORM_SRC¶

Allows to customize Content-Security-Policy HTTP header.

Ver también

WEBLATE_LICENSE_FILTER¶: Configura LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED¶: Configures LICENSE_REQUIRED.

WEBLATE_WEBSITE_REQUIRED¶: Configures WEBSITE_REQUIRED.

WEBLATE_HIDE_VERSION¶: Configura HIDE_VERSION..

WEBLATE_BASIC_LANGUAGES¶: Configura BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH¶: Configura DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS¶

WEBLATE_RATELIMIT_LOCKOUT¶

WEBLATE_RATELIMIT_WINDOW¶

Added in version 4.6.

Configura el limitador de velocidad.

Consejo

You can set configuration for any rate limiter scopes. To do that add WEBLATE_ prefix to any of setting described in Rate limiting.

Ver también

WEBLATE_API_RATELIMIT_ANON¶

WEBLATE_API_RATELIMIT_USER¶: Added in version 4.11.

Configures API rate limiting. Defaults to 100/day for anonymous and 5000/hour for authenticated users.

Ver también

Limitación de la tasa de API

WEBLATE_ENABLE_HOOKS¶: Added in version 4.13.

Configura ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS¶: Added in version 4.6.1.

Configura ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX¶: Added in version 4.15.

Configura AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH¶: Added in version 4.9.

Configura LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS¶: Added in version 4.9.

Configura SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS¶

Added in version 4.9.

Configura BORG_EXTRA_ARGS como una lista de argumentos separados por comas.

Ejemplo:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/

WEBLATE_ENABLE_SHARING¶: Added in version 4.14.1.

Configura ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK¶: Added in version 5.5.

Configura SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD¶: Added in version 4.15.

Configura EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE¶: Added in version 4.15.

Configurar PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN¶: Added in version 4.15.

Configura PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS¶: Added in version 4.17.

Configura UNUSED_ALERT_DAYS.

WEBLATE_UPDATE_LANGUAGES¶: Added in version 4.3.2.

Configura UPDATE_LANGUAGES.

WEBLATE_CORS_ALLOWED_ORIGINS¶

Added in version 4.16.

Permitir solicitudes CORS a la API desde orígenes determinados.

Ejemplo:

environment:
  WEBLATE_CORS_ALLOWED_ORIGINS: https://example.com,https://weblate.org

WEBLATE_CORS_ALLOW_ALL_ORIGINS¶: Added in version 5.6.1: Permite solicitudes CORS a API desde todos los orígenes.

CLIENT_MAX_BODY_SIZE¶

Added in version 4.16.3.

Configura el tamaño máximo de cuerpo aceptado por el servidor web integrado.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Consejo

This variable intentionally lacks WEBLATE_ prefix as it is shared with third-party container used in Certificados SSL automáticos con Let’s Encrypt.

Credenciales de sitios de alojamiento de código¶

En el contenedor Docker, las credenciales de alojamiento de código se pueden configurar en variables separadas o usando un diccionario Python para configurarlas a la vez. Los siguientes ejemplos son para Solicitudes de incorporación de GitHub, pero se aplican a todos Integración de control de versiones con nombres de variables modificados adecuadamente.

Una configuración de ejemplo para GitHub podría verse así:

WEBLATE_GITHUB_USERNAME=api-user
WEBLATE_GITHUB_TOKEN=api-token
WEBLATE_GITHUB_HOST=api.github.com

Se utilizará como:

GITHUB_CREDENTIALS = {
    "api.github.com": {
        "username": "api-user",
        "token": "api-token",
    }
}

Alternativamente, el diccionario de Python se puede proporcionar como una cadena:

WEBLATE_GITHUB_CREDENTIALS='{ "api.github.com": { "username": "api-user", "token": "api-token", } }'

O la ruta a un archivo que contenga el diccionario Python:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

WEBLATE_GITHUB_USERNAME¶

WEBLATE_GITHUB_TOKEN¶

WEBLATE_GITHUB_HOST¶

WEBLATE_GITHUB_CREDENTIALS¶: Configurar Solicitudes de incorporación de GitHub cambiando GITHUB_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_GITLAB_USERNAME¶

WEBLATE_GITLAB_TOKEN¶

WEBLATE_GITLAB_HOST¶

WEBLATE_GITLAB_CREDENTIALS¶: Configurar Solicitudes de fusión de GitLab cambiando GITLAB_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_GITEA_USERNAME¶

WEBLATE_GITEA_TOKEN¶

WEBLATE_GITEA_HOST¶

WEBLATE_GITEA_CREDENTIALS¶: Configurar Solicitudes de incorporación de Gitea cambiando GITEA_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_PAGURE_USERNAME¶

WEBLATE_PAGURE_TOKEN¶

WEBLATE_PAGURE_HOST¶

WEBLATE_PAGURE_CREDENTIALS¶: Configurar Solicitudes de fusión de Pagure cambiando PAGURE_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_BITBUCKETSERVER_USERNAME¶

WEBLATE_BITBUCKETSERVER_TOKEN¶

WEBLATE_BITBUCKETSERVER_HOST¶

WEBLATE_BITBUCKETSERVER_CREDENTIALS¶: Configures Bitbucket Data Center pull requests by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME¶

WEBLATE_BITBUCKETCLOUD_WORKSPACE¶

WEBLATE_BITBUCKETCLOUD_TOKEN¶

WEBLATE_BITBUCKETCLOUD_HOST¶

WEBLATE_BITBUCKETCLOUD_CREDENTIALS¶: Configures Bitbucket Cloud pull requests by changing BITBUCKETCLOUD_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

WEBLATE_AZURE_DEVOPS_USERNAME¶

WEBLATE_AZURE_DEVOPS_ORGANIZATION¶

WEBLATE_AZURE_DEVOPS_TOKEN¶

WEBLATE_AZURE_DEVOPS_HOST¶

WEBLATE_AZURE_DEVOPS_CREDENTIALS¶: Configures Azure DevOps pull requests by changing AZURE_DEVOPS_CREDENTIALS.

Ver también

Configuring code hosting credentials in Docker

Configuración de las sugerencias automáticas¶

Distinto en la versión 4.13: Los servicios de sugerencias automáticas ahora están configurados en la interfaz de usuario, consulte Sugerencias automáticas.

The existing environment variables are imported during the migration to Weblate 4.13, but changing them will not have any further effect.

Configuración de autenticación¶

LDAP¶

WEBLATE_AUTH_LDAP_SERVER_URI¶

WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE¶

WEBLATE_AUTH_LDAP_USER_ATTR_MAP¶

WEBLATE_AUTH_LDAP_BIND_DN¶

WEBLATE_AUTH_LDAP_BIND_PASSWORD¶

WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS¶

WEBLATE_AUTH_LDAP_USER_SEARCH¶

WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION¶

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER¶

Configuración de la autenticación con LDAP.

Example for direct bind:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_USER_DN_TEMPLATE: uid=%(user)s,ou=People,dc=example,dc=net
  # map weblate 'full_name' to ldap 'name' and weblate 'email' attribute to 'mail' ldap attribute.
  # another example that can be used with OpenLDAP: 'full_name:cn,email:mail'
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail

Example for search and bind:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com

Example for union search and bind:

environment:
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH_UNION: ou=users,dc=example,dc=com|ou=otherusers,dc=example,dc=com

Example with search and bind against Active Directory:

environment:
  WEBLATE_AUTH_LDAP_BIND_DN: CN=ldap,CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_BIND_PASSWORD: password
  WEBLATE_AUTH_LDAP_SERVER_URI: ldap://ldap.example.org
  WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS: 0
  WEBLATE_AUTH_LDAP_USER_ATTR_MAP: full_name:name,email:mail
  WEBLATE_AUTH_LDAP_USER_SEARCH: CN=Users,DC=example,DC=com
  WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER: (sAMAccountName=%(user)s)

Ver también

GitHub¶

WEBLATE_SOCIAL_AUTH_GITHUB_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ORG_NAME¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_TEAM_ID¶: Activa la Autenticación por GitHub.

Edición GitHub Enterprise¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_KEY¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SECRET¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_API_URL¶

WEBLATE_SOCIAL_AUTH_GITHUB_ENTERPRISE_SCOPE¶: Activa Autenticación de GitHub EE.

Bitbucket¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET¶: Activa la Autenticación por Bitbucket.

Facebook¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY¶

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET¶: Activa la OAuth 2 de Facebook.

Google¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_DOMAINS¶

WEBLATE_SOCIAL_AUTH_GOOGLE_OAUTH2_WHITELISTED_EMAILS¶: Activa la Google OAuth 2.

GitLab¶

WEBLATE_SOCIAL_AUTH_GITLAB_KEY¶

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET¶

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL¶: Activa la OAuth 2 de GitLab.

Gitea¶

WEBLATE_SOCIAL_AUTH_GITEA_API_URL¶

WEBLATE_SOCIAL_AUTH_GITEA_KEY¶

WEBLATE_SOCIAL_AUTH_GITEA_SECRET¶: Habilita la autenticación Gitea.

Active Directory de Azure¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET¶: Habilita la autenticación de Azure Active Directory, ver Active Directory de Microsoft Azure.

Azure Active Directory con soporte Tenant¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET¶

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID¶: Habilita la autenticación de Azure Active Directory con soporte Tenant, ver Active Directory de Microsoft Azure.

Keycloak¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_SECRET¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_PUBLIC_KEY¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ALGORITHM¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_AUTHORIZATION_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ACCESS_TOKEN_URL¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_TITLE¶

WEBLATE_SOCIAL_AUTH_KEYCLOAK_IMAGE¶: Habilita la autenticación Keycloak, ver Keycloak - Open Source Red Hat SSO.

Proveedores de Linux¶

Puede habilitar la autenticación mediante los servicios de autenticación de proveedores de Linux estableciendo las siguientes variables en cualquier valor.

WEBLATE_SOCIAL_AUTH_FEDORA¶

WEBLATE_SOCIAL_AUTH_OPENSUSE¶

WEBLATE_SOCIAL_AUTH_OPENINFRA¶

WEBLATE_SOCIAL_AUTH_UBUNTU¶

Slack¶

WEBLATE_SOCIAL_AUTH_SLACK_KEY¶

SOCIAL_AUTH_SLACK_SECRET¶: Enables Slack authentication, see Slack.

OpenID Connect¶

Added in version 4.13-1.

WEBLATE_SOCIAL_AUTH_OIDC_OIDC_ENDPOINT¶

WEBLATE_SOCIAL_AUTH_OIDC_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_SECRET¶

WEBLATE_SOCIAL_AUTH_OIDC_USERNAME_KEY¶

WEBLATE_SOCIAL_AUTH_OIDC_TITLE¶

WEBLATE_SOCIAL_AUTH_OIDC_IMAGE¶: Configures generic OpenID Connect integration.

Ver también

OIDC (OpenID Connect)

SAML¶

Self-signed SAML keys are automatically generated on first container startup. In case you want to use own keys, place the certificate and private key in /app/data/ssl/saml.crt and /app/data/ssl/saml.key.

WEBLATE_SAML_IDP_ENTITY_ID¶

WEBLATE_SAML_IDP_URL¶

WEBLATE_SAML_IDP_X509CERT¶

WEBLATE_SAML_IDP_IMAGE¶

WEBLATE_SAML_IDP_TITLE¶: SAML Identity Provider settings, see Autenticación por SAML.

WEBLATE_SAML_ID_ATTR_NAME¶

WEBLATE_SAML_ID_ATTR_USERNAME¶

WEBLATE_SAML_ID_ATTR_EMAIL¶

WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID¶: Added in version 4.18.

SAML attributes mapping.

Otras configuraciones de autenticación¶

WEBLATE_NO_EMAIL_AUTH¶: Deshabilita la autenticación de correo electrónico cuando se establece en cualquier valor. Consulte Desactivar la autenticación por contraseña.

WEBLATE_MIN_PASSWORD_SCORE¶

Minimal password score as evaluated by the zxcvbn password strength estimator. Defaults to 3, set to 0 to disable strength checking.

Ver también

Puesta en marcha de la base de datos PostgreSQL¶

The database is created by docker-compose.yml, so these settings affect both Weblate and PostgreSQL containers.

Ver también

Configuración de base de datos para Weblate

POSTGRES_PASSWORD¶: Contraseña de PostgreSQL.

Ver también

Pasando secretos

POSTGRES_USER¶: Nombre de usuario de PostgreSQL.

POSTGRES_DB¶: Nombre de base de datos de PostgreSQL.

POSTGRES_HOST¶: Nombre de host o dirección IP del servidor PostgreSQL. Por defecto a database.

POSTGRES_PORT¶: Puerto del servidor PostgreSQL. El valor predeterminado es ninguno (usa el valor predeterminado).

POSTGRES_SSL_MODE¶: Configure cómo PostgreSQL maneja SSL en conexión con el servidor, para conocer las posibles opciones, ver “ Descripciones del modo SSL <https://www.postgresql.org/docs/11/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS>`_.

POSTGRES_ALTER_ROLE¶

Configura el nombre del rol de PostgreSQL para modificarlo durante la migración de la base de datos, ver Configurar Weblate para que utilice PostgreSQL.

Por defecto a POSTGRES_USER.

POSTGRES_CONN_MAX_AGE¶

Added in version 4.8.1.

La duración de una conexión a la base de datos, como un entero de segundos. Utilice 0 para cerrar las conexiones a la base de datos al final de cada solicitud.

Distinto en la versión 5.1: El comportamiento predeterminado es tener conexiones de base de datos persistentes ilimitadas.

Habilitar la persistencia de la conexión generalmente provocará una conexión más abierta a la base de datos. Ajuste la configuración de su base de datos antes de habilitarla.

Ejemplo de configuración:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Ver también

POSTGRES_DISABLE_SERVER_SIDE_CURSORS¶

Added in version 4.9.1.

Deshabilitar los cursores del lado del servidor en la base de datos. Esto es necesario en algunas configuraciones pgbouncer.

Ejemplo de configuración:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Ver también

WEBLATE_DATABASES¶: Added in version 5.1.

Establecer en falso para deshabilitar la configuración basada en el entorno de la conexión de la base de datos. Usar Anulación de la configuración del volumen de datos para configurar la conexión de la base de datos manualmente.

MySQL or MariaDB server¶

Neither MySQL nor MariaDB can not be configured via environment variables. See MySQL y MariaDB for info on using those with Weblate. Use WEBLATE_DATABASES to configure the database connection manually.

Configuración de copia de respaldo de la base de datos¶

Ver también

Datos volcados para las copias de respaldo

WEBLATE_DATABASE_BACKUP¶: Configures the daily database dump using DATABASE_BACKUP. Defaults to plain.

Caching server setup¶

Using Redis is strongly recommended by Weblate and you have to provide a Redis instance when running Weblate in Docker.

Ver también

Activar caché

REDIS_HOST¶: The Redis server hostname or IP address. Defaults to cache.

REDIS_PORT¶: The Redis server port. Defaults to 6379.

REDIS_DB¶: The Redis database number, defaults to 1.

REDIS_USER¶: Added in version 5.13: The Redis database user, not used by default.

REDIS_PASSWORD¶: La contraseña del servidor Redis, no utilizada de manera predeterminada.

Ver también

Pasando secretos

REDIS_TLS¶: Permite el uso de SSL para la conexión con Redis.

REDIS_VERIFY_SSL¶: Se puede utilizar para desactivar la verificación de certificados SSL para la conexión con Redis.

Puesta en funcionamiento del servidor de correo¶

Para que funcione el correo saliente, debe proporcionar un servidor de correo.

Ejemplo de configuración de TLS:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass

Ejemplo de configuración de SSL:

environment:
    WEBLATE_EMAIL_HOST: smtp.example.com
    WEBLATE_EMAIL_PORT: 465
    WEBLATE_EMAIL_HOST_USER: user
    WEBLATE_EMAIL_HOST_PASSWORD: pass
    WEBLATE_EMAIL_USE_TLS: 0
    WEBLATE_EMAIL_USE_SSL: 1

Ver también

Configurar el correo electrónico saliente

WEBLATE_EMAIL_HOST¶

Nombre de anfitrión o dirección IP del servidor de correo.

Ver también

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
WEBLATE_EMAIL_USE_TLS
EMAIL_HOST

WEBLATE_EMAIL_PORT¶: Puerto del servidor de correo, cuyo valor predeterminado es 25.

Ver también

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER¶: Usuario de autenticación del correo electrónico.

Ver también

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD¶

Contraseña de autenticación del correo electrónico.

Ver también

WEBLATE_EMAIL_USE_SSL¶

Si se debe utilizar una conexión TLS (segura) implícita al hablar con el servidor SMTP. En la mayoría de la documentación de correo electrónico, este tipo de conexión TLS se denomina SSL. Generalmente se usa en el puerto 465. Si tiene problemas, consulte la configuración explícita de TLS WEBLATE_EMAIL_USE_TLS.

Distinto en la versión 4.11: El soporte SSL/TLS se habilita automáticamente en función de la WEBLATE_EMAIL_PORT.

Ver también

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_TLS
EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS¶

Si se debe utilizar una conexión TLS (segura) al hablar con el servidor SMTP. Esto se usa para conexiones TLS explícitas, generalmente en el puerto 587 o 25. Si experimenta conexiones bloqueadas, consulte la configuración implícita de TLS WEBLATE_EMAIL_USE_SSL.

Distinto en la versión 4.11: El soporte SSL/TLS se habilita automáticamente en función de la WEBLATE_EMAIL_PORT.

Ver también

WEBLATE_EMAIL_PORT
WEBLATE_EMAIL_USE_SSL
EMAIL_USE_TLS

WEBLATE_EMAIL_BACKEND¶

Configura el dorsal Django para utilizarlo para enviar mensajes de correo electrónico.

Ver también

WEBLATE_AUTO_UPDATE¶: Configura si Weblate debe actualizar los repositorios y cómo.

Ver también

AUTO_UPDATE

Nota

Esta es una configuración booleana (use "true" o "false").

Integración del sitio¶

WEBLATE_GET_HELP_URL¶: Configura GET_HELP_URL.

WEBLATE_STATUS_URL¶: Configura STATUS_URL.

WEBLATE_LEGAL_URL¶: Configura LEGAL_URL.

WEBLATE_PRIVACY_URL¶: Configura PRIVACY_URL.

Recopilación de informes de errores y supervisión del rendimiento¶

Se recomienda recopilar sistemáticamente los errores que se producen en la instalación; consulte Recopilación de informes de errores y supervisión del rendimiento.

Para activar la compatibilidad con Rollbar, defina lo siguiente:

ROLLBAR_KEY¶: Su ficha de acceso POST al servidor de Rollbar.

ROLLBAR_ENVIRONMENT¶: Su entorno de Rollbar, cuyo valor predeterminado es production.

Para activar la compatibilidad con Sentry, defina lo siguiente:

SENTRY_DSN¶: Su DSN Centinela, ver SENTRY_DSN.

SENTRY_ENVIRONMENT¶: Su entorno de Sentry (opcional), por defecto WEBLATE_SITE_DOMAIN.

SENTRY_MONITOR_BEAT_TASKS¶: Si desea supervisar las tareas de Celery Beat con Sentry, el valor predeterminado es True.

SENTRY_TRACES_SAMPLE_RATE¶

Configures SENTRY_TRACES_SAMPLE_RATE.

Ejemplo:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5

SENTRY_PROFILES_SAMPLE_RATE¶

Configures SENTRY_PROFILES_SAMPLE_RATE.

Ejemplo:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5

SENTRY_SEND_PII¶: Configures SENTRY_SEND_PII.

CDN de regionalización¶

WEBLATE_LOCALIZE_CDN_URL¶

WEBLATE_LOCALIZE_CDN_PATH¶

Added in version 4.2.1.

Configuración para CDN de regionalización de JavaScript.

The WEBLATE_LOCALIZE_CDN_PATH is path within the container. It should be stored on the persistent volume and not in the transient storage.

One of possibilities is storing that inside the Weblate data dir:

environment:
  WEBLATE_LOCALIZE_CDN_URL: https://cdn.example.com/
  WEBLATE_LOCALIZE_CDN_PATH: /app/data/l10n-cdn

Nota

You are responsible for setting up serving of the files generated by Weblate, it only does stores the files in configured location.

Ver también

Changing enabled apps, checks, add-ons, machine translation or autofixes¶

La configuración integrada de comprobaciones, complementos o correcciones automáticas habilitadas se puede ajustar mediante las siguientes variables:

WEBLATE_ADD_APPS¶

WEBLATE_REMOVE_APPS¶

WEBLATE_ADD_CHECK¶

WEBLATE_REMOVE_CHECK¶

WEBLATE_ADD_AUTOFIX¶

WEBLATE_REMOVE_AUTOFIX¶

WEBLATE_ADD_ADDONS¶

WEBLATE_REMOVE_ADDONS¶

WEBLATE_ADD_MACHINERY¶: Added in version 5.6.1.

WEBLATE_REMOVE_MACHINERY¶: Added in version 5.6.1.

Ejemplo:

environment:
  WEBLATE_REMOVE_AUTOFIX: weblate.trans.autofixes.whitespace.SameBookendingWhitespace
  WEBLATE_ADD_ADDONS: customize.addons.MyAddon,customize.addons.OtherAddon

Ver también

Configuración de contenedor¶

WEBLATE_WORKERS¶

Added in version 4.6.1.

Base number of worker processes running in the container. When not set it is determined automatically on container startup based on number of CPU cores available.

Se utiliza para determinar CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, y WEB_WORKERS. Puedes utilizar estas opciones para realizar ajustes.

CELERY_MAIN_OPTIONS¶

CELERY_NOTIFY_OPTIONS¶

CELERY_MEMORY_OPTIONS¶

CELERY_TRANSLATE_OPTIONS¶

CELERY_BACKUP_OPTIONS¶

CELERY_BEAT_OPTIONS¶

Estas variables permiten ajustar las opciones de trabajo de Celery. Puede ser útil ajustar la concurrencia (--concurrency 16) o usar una implementación de pool diferente (--pool=gevent).

De forma predeterminada, el número de trabajos simultáneos se basa en WEBLATE_WORKERS.

Ejemplo:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Ver también

CELERY_SINGLE_PROCESS¶

Added in version 5.7.1: Esta variable se puede establecer en 1 para ejecutar solo un proceso de celery. Esto reduce el uso de memoria, pero puede afectar el rendimiento de Weblate.

environment:
  CELERY_SINGLE_PROCESS: 1

Ver también

Single-process Celery setup

WEB_WORKERS¶

Configurar cuántos trabajos WSGI se deben ejecutar.

It defaults to half of WEBLATE_WORKERS, but is always at least 2.

Ejemplo:
environment:
  WEB_WORKERS: 4

Distinto en la versión 5.13: WEB_WORKERS configures how many worker processes will used by granian.

WEBLATE_SERVICE¶

Define qué servicios deben ejecutarse dentro del contenedor. Usa esto para Scaling horizontally.

Se definen los siguientes servicios:

celery-beat: Programador de tareas de Celery, solo se debe ejecutar una instancia. Este contenedor también es responsable de las migraciones de la estructura de la base de datos y debe iniciarse antes que otros.
celery-backup: Trabajo de Celery para las copias de seguridad, solo se debe ejecutar una instancia.
celery-celery: Trabajo genérico de Celery.
celery-memory: Memoria de traducción para programadores en Celery.
celery-notify: Notificaciones para programadores de Celery.
celery-translate: Traducción automática para programadored en Celey.
web: Servidor web.

Ver también

Background tasks internals

WEBLATE_ANUBIS_URL¶

Added in version 5.11.4.

URL of Anubis server to handle subrequest authentication. This can be useful to filter incoming HTTP requests using proof-of-work to stop AI crawlers. You need to configure Anubis for Subrequest Authentication to make it work.

This can be done using docker compose, for example:

anubis:
   image: ghcr.io/techarohq/anubis:latest
   environment:
      BIND: ":8923"
      DIFFICULTY: "4"
      METRICS_BIND: ":9090"
      SERVE_ROBOTS_TXT: "false"
      TARGET: " "
      OG_PASSTHROUGH: "false"
      ED25519_PRIVATE_KEY_HEX: "$(openssl rand -hex 32)"

You can then turn on the Anubis usage in Weblate using:

environment:
   WEBLATE_ANUBIS_URL: http://anubis:8923

Volúmenes de contenedores Docker¶

There are two volumes (data and cache) exported by the Weblate container. The other service containers (PostgreSQL or Redis) have their data volumes as well, but those are not covered by this document.

The data volume is mounted as /app/data and is used to store Weblate persistent data such as cloned repositories or to customize Weblate installation. DATA_DIR describes in more detail what is stored here.

The placement of the Docker volume on host system depends on your Docker configuration, but usually it is stored in /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (the path consist of name of your docker-compose directory, container, and volume names).

The cache volume is mounted as /app/cache and is used to store static files and CACHE_DIR. Its content is recreated on container startup and the volume can be mounted using ephemeral filesystem such as tmpfs.

When creating the volumes manually, the directories should be owned by UID 1000 as that is user used inside the container.

Weblate container can also be executed with a read-only root file system. In this case, two additional tmpfs volumes should be mounted: /tmp and /run.

Ver también

Sistema de archivos raíz de solo lectura¶

Added in version 4.18.

Cuando se ejecuta el contenedor con un sistema de archivos raíz de solo lectura, se requieren dos volúmenes tmpfs adicionales - /tmp y /run.

Configuración más allá de las variables de entorno¶

Docker environment variables están destinados a exponer la mayoría configuration settings de relevancia para las instalaciones de Weblate.

Si encuentra una configuración que no está expuesta como variable de entorno, y cree que debería estarlo, siéntase libre de hacerlo ask for it to be exposed in a future version of Weblate.

Si necesita modificar una configuración que no está expuesta como variable de entorno de Docker, aún puede hacerlo, ya sea from the data volume o extending the Docker image.

Ver también

Personalizar Weblate

Anulación de la configuración del volumen de datos¶

Puede crear un archivo en /app/data/settings-override.py, es decir, en la raíz de data volume, para extender o anular la configuración definida a través de variables de entorno.

Anular la configuración extendiendo la imagen de Docker¶

To override settings at the Docker image level instead of from the data volume:

Create a custom Python package.
Add a module to your package that imports all settings from weblate.settings_docker.

For example, within the example package structure defined at Crear un módulo de Python, you could create a file at weblate_customization/weblate_customization/settings.py with the following initial code:
```
from weblate.settings_docker import *
```

Create a custom Dockerfile that inherits from the official Weblate Docker image, and then installs your package and points the DJANGO_SETTINGS_MODULE environment variable to your settings module:

FROM weblate/weblate

USER root

COPY weblate_customization /usr/src/weblate_customization
RUN source /app/venv/bin/activate && uv pip install --no-cache-dir /usr/src/weblate_customization
ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings

USER 1000

Instead of using the official Weblate Docker image, build a custom image from this Dockerfile file.

There is no clean way to do this with docker-compose.override.yml. You could add build: . to the weblate node in that file, but then your custom image will be tagged as weblate/weblate in your system, which could be problematic.

So, instead of using the docker-compose.yml straight from the official repository, unmodified, and extending it through docker-compose.override.yml, you may want to make a copy of the official docker-compose.yml file, and edit your copy to replace image: weblate/weblate with build: ..

See the Compose file build reference for details on building images from source when using docker-compose.
Ampliar el módulo de configuración personalizada para definir o redefinir la configuración.

Se puede definir la configuración antes o después de la instrucción de importación anterior para determinar qué configuración tiene prioridad. Las variables de entorno y las anulaciones de configuración definidas en el volumen de datos pueden anular la configuración definida antes de la instrucción de importación. La configuración definida después de la instrucción de importación no se puede anular.

También puedes ir más allá. Por ejemplo, puede reproducir algunas de las cosas que weblate.docker_settings does, como exponer la configuración como variables de entorno o permitir anular la configuración de los archivos Python en el volumen de datos.

Reemplazo de logotipos y otros archivos estáticos¶

Los archivos estáticos que vienen con Weblate se pueden anular colocando en /app/data/python/customize/static (ver Volúmenes de contenedores Docker). Por ejemplo creando /app/data/python/customize/static/favicon.ico reemplazará el favicon.

Consejo

Los archivos se copian en la ubicación correspondiente al iniciar el contenedor, por lo que es necesario reiniciar Weblate después de cambiar el contenido del volumen.

Este enfoque también se puede utilizar para anular las plantillas de Weblate. Por ejemplo los documentos Legal module se pueden colocar en /app/data/python/customize/templates/legal/documents.

Alternativamente, también puede incluir un módulo propio (ver Personalizar Weblate) y agréguelo como volumen separado al contenedor Docker, por ejemplo:

weblate:
  volumes:
    - weblate-data:/app/data
    - ./weblate_customization/weblate_customization:/app/data/python/weblate_customization
  environment:
    WEBLATE_ADD_APPS: weblate_customization

Personalización del código¶

Nota

La API interna de Weblate puede variar significativamente entre versiones y no pretende ser estable. Revise su código personalizado que interactúa con los componentes internos de Weblate en cada actualización.

Puede colocar código Python adicional en /app/data/python/customize (ver: Volúmenes de contenedores Docker). Ya está instalado como una aplicación Django dentro de Weblate (esto se usa para personalizar plantillas y archivos estáticos como se describió anteriormente).

This can be used to place any code (for example Escribir los propios controles) or to add custom maintenance tasks to the Celery task scheduler.

An example of custom scheduled tasks in /app/data/python/customize/tasks.py.¶

"""Custom scheduled task."""

import subprocess

from celery.schedules import crontab

from weblate.utils.celery import app


@app.task
def custom_task() -> None:
    """Execute custom task code."""
    subprocess.run(["sleep", "1"], check=True)


@app.on_after_finalize.connect
def setup_periodic_tasks(sender, **kwargs) -> None:
    """Configure when periodic task is triggered."""
    sender.add_periodic_task(
        crontab(hour=1, minute=0), custom_task.s(), name="custom-task"
    )

Configuración del servidor PostgreSQL¶

The PostgreSQL container uses default PostgreSQL configuration and it won’t effectively utilize your CPU cores or memory. It is recommended to customize the configuration to improve the performance.

The configuration can be adjusted as described in Database Configuration at https://hub.docker.com/_/postgres. The configuration matching your environment can be generated using https://pgtune.leopard.in.ua/.

Container internals¶

The container is using supervisor to start individual services. In case of Scaling horizontally, it only starts single service in a container.

To check the services status use:

docker compose exec --user weblate weblate supervisorctl status

There are individual services for each Celery queue (see Tareas en segundo plano con Celery for details). You can stop processing some tasks by stopping the appropriate worker:

docker compose exec --user weblate weblate supervisorctl stop celery-translate