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, 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).

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.

  1. Clone el repositorio weblate-docker:

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

  2. Crear un archivo docker-compose.override.yml con tus configuraciones. Ver Variables de entorno de Docker 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.

  3. 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:

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

Actualizaciones continuas en un entorno de producción

<MAJOR>

Versión estable de Weblate

Actualizaciones continuas dentro de una versión principal en un entorno de producción

<MAJOR>.<MINOR>

Versión estable de Weblate

Actualizaciones continuas dentro de una versión secundaria en un entorno de producción

<VERSION>.<PATCH>

Versión estable de Weblate

Implementación bien definida en un entorno de producción

edge

Versión estable de Weblate con cambios de desarrollo en el contenedor Docker (por ejemplo, dependencias actualizadas)

Rolling updates in a staging environment

edge-<DATE>-<SHA>

Versión estable de Weblate con cambios de desarrollo en el contenedor Docker (por ejemplo, dependencias actualizadas)

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

  1. Detener el contenedor de Weblate:

    docker compose stop weblate cache

  2. Copia de seguridad de la base de datos:

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

  3. Detenga el contenedor de la base de datos:

    docker compose stop database

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

  5. Adjustar docker-compose.yml para usar la nueva versión de PostgreSQL.

  6. Inicie el contenedor de la base de datos:

    docker compose up -d database

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

  8. (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.

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

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

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.

Cada contenedor de Weblate tiene un rol definido usando la variable de entorno WEBLATE_SERVICE. Seguir atentamente la documentación, ya que algunos de los servicios deberían ejecutarse solo una vez en el clúster, y el orden de los servicios también es importante.

Puede encontrar una configuración de ejemplo en el repositorio docker-compose como docker-compose-split.yml.

Variables de entorno de Docker

Muchas de las Configuración de Weblate se pueden configurar en el contenedor Docker utilizando las variables de entorno que se describen a continuación.

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.

Para un registro más silencioso, use ERROR o WARNING.

WEBLATE_LOGLEVEL_DATABASE

Configura el registro de la verbosidad de las consultas de la base de datos.

WEBLATE_LOG_GELF_HOST

Added in version 5.9.

Configura el registro remoto mediante la conexión GELF TCP. Se puede utilizar para integrarse con Graylog.

WEBLATE_LOG_GELF_PORT

Added in version 5.9.

Use un puerto personalizado para WEBLATE_LOG_GELF_HOST, valor predeterminado 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.

Incluir el puerto si se usa uno no estándar.

Ejemplo:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

Ver también

WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Configura el nombre y el correo electrónico del administrador del sitio. Se usa tanto para configuración ADMINS y creación de un usuario admin (ver WEBLATE_ADMIN_PASSWORD para más información).

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

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

Configurar 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_GPG_IDENTITY

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

Ver también

Firmando confirmaciones de Git con 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

Puede establecer la configuración para cualquier ámbito limitador de velocidad. Para hacer eso, añada el prefijo WEBLATE_ a cualquiera de los ajustes descritos en Rate limiting.

Ver también

WEBLATE_API_RATELIMIT_ANON
WEBLATE_API_RATELIMIT_USER

Added in version 4.11.

Configura la limitación de la tasa de API. El valor predeterminado es 100/day para usuarios anónimos y 5000/hour para autenticados.

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

Configurar Bitbucket Data Center pull requests cambiando BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME
WEBLATE_BITBUCKETCLOUD_WORKSPACE
WEBLATE_BITBUCKETCLOUD_TOKEN
WEBLATE_BITBUCKETCLOUD_HOST
WEBLATE_BITBUCKETCLOUD_CREDENTIALS

Configurar Bitbucket Cloud pull requests cambiando 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

Configurar Azure DevOps pull requests cambiando 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.

Las variables de entorno existentes se importan durante la migración a Weblate 4.13, pero cambiarlas no tendrá ningún efecto adicional.

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

Consejo

When Keycloak is configured to abstract third-party IDP, you will need to configure WEBLATE_CSP_FORM_SRC for the third-party IDP domain.

Example when Keycloak is passing authentication to Microsoft.
environment:
  WEBLATE_CSP_FORM_SRC: login.microsoftonline.com

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

Habilita la autenticación de Slack, ver 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

Configura la integración genérica de OpenID Connect.

Ver también

OIDC (OpenID Connect)

SAML

Las claves SAML autofirmadas se generan automáticamente en el primer inicio del contenedor. En caso de que desee utilizar claves propias, coloque el certificado y la clave privada en /app/data/ssl/saml.crt y /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

Configuración del proveedor de identidades SAML, ver Autenticación por SAML.

WEBLATE_SAML_ID_ATTR_FULL_NAME
WEBLATE_SAML_ID_ATTR_FIRST_NAME
WEBLATE_SAML_ID_ATTR_LAST_NAME
WEBLATE_SAML_ID_ATTR_USERNAME
WEBLATE_SAML_ID_ATTR_EMAIL
WEBLATE_SAML_ID_ATTR_USER_PERMANENT_ID

Added in version 4.18.

Asignación de atributos SAML.

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

Puntuación mínima de contraseñas según lo evaluado por el estimador de seguridad de contraseñas`zxcvbn <https://github.com/dwolfhub/zxcvbn-python>`_ . El valor predeterminado es 3, establecido en 0 para deshabilitar la comprobación de la fuerza.

Ver también

Puesta en marcha de la base de datos PostgreSQL

La base de datos la crea docker-compose.yml, por lo que esta configuración afecta tanto a los contenedores Weblate como PostgreSQL.

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.

Servidor MySQL o MariaDB

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

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

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

Configura SENTRY_TRACES_SAMPLE_RATE.

Ejemplo:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5
SENTRY_PROFILES_SAMPLE_RATE

Configura SENTRY_PROFILES_SAMPLE_RATE.

Ejemplo:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5
SENTRY_SEND_PII

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

El WEBLATE_LOCALIZE_CDN_PATH es la ruta dentro del contenedor. Debe almacenarse en el volumen persistente y no en el almacenamiento transitorio.

Una de las posibilidades es almacenarlo dentro del directorio de datos de Weblate:

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

Nota

Usted es responsable de configurar el servicio de los archivos generados por Weblate, solo almacena los archivos en la ubicación configurada.

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.

Número base de procesos de trabajo que se ejecutan en el contenedor. Cuando no está configurado, se determina automáticamente al iniciar el contenedor en función del número de núcleos de CPU disponibles.

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

Configuración de Celery de un solo proceso

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.

Ver también

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 data volume is also place to store Weblate customization such as Anulación de la configuración del volumen de datos, Reemplazo de logotipos y otros archivos estáticos or Personalización del código.

La ubicación del volumen Docker en el sistema host depende de la configuración de Docker, pero generalmente se almacena en /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ (la ruta consta del nombre de su directorio docker-compose, contenedor y nombres de volumen).

El volumen cache se monta como /app/cache y se usa para almacenar archivos estáticos y CACHE_DIR. Su contenido se crea de nuevo al iniciar el contenedor y el volumen se puede montar utilizando un sistema de archivos efímero como tmpfs.

Al crear los volúmenes manualmente, los directorios deben ser propiedad del UID 1000, ya que es el usuario que se usa dentro del contenedor.

El contenedor Weblate también se puede ejecutar con un sistema de archivos raíz de solo lectura. En este caso, se deben montar dos volúmenes tmpfs adicionales: /tmp y /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

Para anular la configuración a nivel de imagen de Docker en lugar de desde el volumen de datos:

  1. Create a custom Python package.

  2. Agregar un módulo al paquete que importe todas las configuraciones desde weblate.settings_docker.

    Por ejemplo, dentro de la estructura del paquete de ejemplo definida en Crear un módulo de Python, puede crear un archivo en weblate_customization/weblate_customization/settings.py con el siguiente código inicial:

    from weblate.settings_docker import *

  3. Crear un Dockerfile personalizado que herede de la imagen Docker oficial de Weblate, luego instalar su paquete y apuntar la variable de entorno DJANGO_SETTINGS_MODULE al módulo de configuración:

    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

  4. En lugar de usar la imagen oficial de Weblate Docker, crear una imagen personalizada a partir de este archivo Dockerfile.

    No hay una manera limpia para hacer esto con docker-compose.override.yml. Se podría agregar build: . al nodo weblate en ese archivo, pero luego la imagen personalizada se etiquetará como weblate/weblate en el sistema, lo que podría ser problemático.

    Entonces, en lugar de usar directamente docker-compose.yml desde el repositorio oficial, sin modificar, y extendiéndolo a través de docker-compose.override.yml, es posible que desee hacer una copia del archivo oficial docker-compose.yml, y editar su copia para sustituir image: weblate/weblate por build: ..

    Ver Compose file build reference para tener detalles sobre la creación de imágenes a partir de la fuente cuando se usa docker-compose.

  5. 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 Módulo legal 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).

Esto se puede usar para colocar cualquier código (por ejemplo Escribir los propios controles) o para agregar tareas de mantenimiento personalizadas al programador de tareas de Celery.

Un ejemplo de tareas programadas personalizadas en /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"
    )

Integrating third-party containers

The Weblate Docker setup can be extended with additional containers to provide complementary services such as machine translation, spell checking, or other tools that enhance the translation workflow. These services can be integrated into your Docker Compose configuration and work alongside Weblate.

When adding third-party containers, consider the following:

  • Network connectivity: Ensure containers can communicate with each other by placing them on the same Docker network

  • Data persistence: Use volumes for services that need to persist data

  • Security: Configure appropriate access controls and avoid exposing unnecessary ports

LibreTranslate Docker container integration

LibreTranslate is a free and open-source machine translation service that can be self-hosted. Integrating it with Weblate provides offline machine translation capabilities without relying on external services.

You can incorporate the LibreTranslate service into your Weblate deployment by including it in a docker-compose.override.yml file. Since it runs within the Docker network, it’s only accessible to Weblate and not exposed to the public internet.

Basic setup using docker-compose.override.yml:

services:
  libretranslate:
    image: libretranslate/libretranslate:latest
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s

volumes:
  libretranslate_models:

For GPU-accelerated translation (if you have NVIDIA GPU available):

services:
  libretranslate:
    image: libretranslate/libretranslate:latest-cuda
    command: --disable-web-ui
    restart: unless-stopped
    environment:
      LT_UPDATE_MODELS: true
      PUID: root
    volumes:
      - libretranslate_models:/home/libretranslate/.local:rw
    healthcheck:
      test: ['CMD-SHELL', './venv/bin/python scripts/healthcheck.py']
      interval: 10s
      timeout: 4s
      retries: 4
      start_period: 5s
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

volumes:
  libretranslate_models:

After starting the services with docker compose down && docker compose up -d, configure LibreTranslate in Weblate:

  1. Access the Weblate admin interface

  2. Navigate to Machine translation → Automatic suggestions

  3. Add a new LibreTranslate service with:

    Servicio:

    LibreTranslate

    URL DE LA APLICACIÓN:

    http://libretranslate:5000

    Clave de la aplicación:

    Leave empty

LibreTranslate is now configured and available for machine translation in Weblate.

Nota

  • The LibreTranslate service runs without the web UI (--disable-web-ui) and is only accessible via the API within the Docker network.

  • Models are automatically updated when the container starts. (LT_UPDATE_MODELS: true)

  • Data is persisted using Docker volumes for optimal performance and data safety.

  • Health checks ensure that the Docker engine properly observes the state of the service.

  • For GPU acceleration, use the CUDA image variant and ensure your system has NVIDIA Docker support. This container runs as a privileged user to be able to use the GPU.

  • No external ports are exposed, making the setup secure by default.

Ver también

Anubis Docker container integration

Anubis is a web AI firewall utility to block AI scrapers and other disruptive traffic on the server. It is typically needed for publicly open Weblate installations to avoid excessive load caused by scraping.

Anubis can be deployed using Docker Compose:

anubis:
   image: ghcr.io/techarohq/anubis:latest
   environment:
      BIND: ":8923"
      DIFFICULTY: "4"
      METRICS_BIND: ":9090"
      SERVE_ROBOTS_TXT: "false"
      OG_PASSTHROUGH: "false"
      # The single space in TARGET enables subrequest authentication
      TARGET: " "
      # The redirect domain has to match WEBLATE_SITE_DOMAIN
      REDIRECT_DOMAINS: weblate.example.com
      # Generate a random private key using: openssl rand -hex 32
      ED25519_PRIVATE_KEY_HEX: "..."
      # Customize your Anubis policy
      POLICY_FNAME: /data/botPolicies.yaml
   healthcheck:
      test: ["CMD", "anubis", "--healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5
      start_period: 500ms
   volumes:
      - anubis-data:/data

volumes:
   anubis-data:

Nota

The anubis-data volume in the above configuration is expected to contain botPolicies.yaml with a bot policy configured to your needs.

At minimum, you need to adjust status codes as described in https://anubis.techaro.lol/docs/admin/configuration/subrequest-auth.

It is also recommended to configure persistent storage backend as described in https://anubis.techaro.lol/docs/admin/policies/#storage-backends.

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

environment:
   WEBLATE_ANUBIS_URL: http://anubis:8923

Ver también

WEBLATE_ANUBIS_URL

Configuración del servidor PostgreSQL

El contenedor de PostgreSQL usa la configuración predeterminada de PostgreSQL y no utilizará de manera efectiva los núcleos de la CPU o la memoria. Se recomienda personalizar la configuración para mejorar el rendimiento.

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