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 Valkey como backend 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, consulte Certificados SSL automáticos con Let’s Encrypt. Para configuraciones mayores, consulte Escala horizontalmente.

  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

<YEAR>

Versión estable de Weblate

Rolling updates within a calendar year in a production environment

<YEAR>.<MONTH>

Versión estable de Weblate

Rolling updates within a monthly release in a production environment

<YEAR>.<MONTH>.<PATCH>.<BUILD>

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)

Actualizaciones de roles en un entorno de etapa

edge-<DATE>-<SHA>

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

Despliegue bien definido en un entorno puesto en escena

bleeding

Versión de desarrollo Weblate desde Git

Actualizaciones continuas para las próximas funcionalidades 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

En caso que tenga certificados SSL propios que desea utilizar, simplemente coloque los archivos en el volumen de datos de Weblate (consulte 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

Ambos de estos archivos deben ser propiedad del mismo usuario como el que inicie el contenedor de docker y tiene la máscara de archivo a 600 (legible y escribible solo para el usuario propietario).

Adicionalmente, el contendedor Weblate ahora aceptará conexiones SSL sobre puerto 4443, deseará incluir el puerto de re-envío para HTTPS en anilación de composición de Docker:

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.

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

Direct upgrades are only supported for releases from the current or previous calendar year. If you need to upgrade from an older release, upgrade first to an intermediate version listed in Instrucciones de versión específica.

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

Actualización del contenedor de PostgreSQL

Nota

PostgreSQL 18 ha cambiado el directorio de datos predeterminado dentro del contenedor. Una configuración anterior común montaba el volumen de la base de datos en /var/lib/postgresql/data, mientras que PostgreSQL 18 ahora usa /var/lib/postgresql por defecto.

Si está mejorando desde una versión anterior, actualice el destino de montaje en su configuración de Docker a la ruta nueva, o mantenga el destino de montaje anterior y configure PGDATA en consecuencia.

Dejar el destino de montaje anterior sin modificar y sin configurar PGDATA puede provocar que PostgreSQL escriba sus datos fuera del volumen persistente.

Consulte la documentación de PGDATA para obtener más información.

Los contenedores de PostgreSQL no admiten la actualización automática entre versiones, debe realizar la migración manualmente. Los siguientes pasos muestran una de las opciones de migració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, el cual es 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 incidencias sobre 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

El empleo de memoria puede ser más reducido ejecutando solo un único proceso de Celery:

environment:
  CELERY_SINGLE_PROCESS: 1

Ver también

Escala horizontalmente

Added in version 4.6.

Puede ejecutar múltiples contenedores de Weblate para escala del servicio horizontalmente. El volumen /app/data tiene que estar compartido por todos los contenedores, está recomendado para utilizar sistema de archivos en cluster tales como GlusterFS para esto. El volumen /app/cache estaría separado por cada contenedor.

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 envía un correo-e 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_REGISTRATION_ALLOW_DISPOSABLE_EMAILS

Added in version 5.16.1.

Configura REGISTRATION_ALLOW_DISPOSABLE_EMAILS.

Ejemplo:

environment:
  WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS: 1
WEBLATE_PROJECT_WEB_RESTRICT_PRIVATE

Added in version 5.17.

Configura PROJECT_WEB_RESTRICT_PRIVATE.

Predeterminado a habilitado.

WEBLATE_PROJECT_WEB_RESTRICT_ALLOWLIST

Added in version 5.17.

Configures PROJECT_WEB_RESTRICT_ALLOWLIST.

Expects a comma-separated list of trusted project slugs.

WEBLATE_WEBHOOK_RESTRICT_PRIVATE

Added in version 5.17.

Configura WEBHOOK_RESTRICT_PRIVATE.

Predeterminado a habilitado.

WEBLATE_WEBHOOK_PRIVATE_ALLOWLIST

Added in version 5.17.

Configura WEBHOOK_PRIVATE_ALLOWLIST.

Expects a comma-separated list of trusted hostnames or domains.

WEBLATE_ASSET_RESTRICT_PRIVATE

Added in version 2025.5.

Configures ASSET_RESTRICT_PRIVATE.

Predeterminado a habilitado.

WEBLATE_ASSET_PRIVATE_ALLOWLIST

Added in version 2025.5.

Configures ASSET_PRIVATE_ALLOWLIST.

Expects a comma-separated list of trusted hostnames or domains.

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; también necesita configurar también eso, consulte Contenedor Docker con compatibilidad con HTTPS para obtener ejemplos.

Ejemplo:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Ver también

WEBLATE_NGINX_IPV6

Added in version 5.17.

Controla si los NGINX vinculados escuchan en direcciones IPv6.

Los valores admitidos son:

  • auto habilita los oyentes IPv6 solo cuando IPv6 está disponible en el entorno de ejecución del contenedor. Esta es lo predeterminado.

  • on para habilitar siempre los oyentes IPv6.

  • off para inhabilitar los oyentes IPv6.

Ejemplo:

environment:
  WEBLATE_NGINX_IPV6: auto
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

A tuple representing an HTTP header/value combination that signifies a request is secure. This is needed when Weblate is running behind a reverse proxy doing SSL termination which does not pass standard HTTPS headers.

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

Habilita el módulo Módulo legal en despliegues de Docker. Por defecto, la integración está inhabilitada; deje esta variable sin definir o vacía para inhabilitarlo.

Los valores admitidos son:

  • tos-confirm para habilitar el módulo legal y hacer cumplir la confirmación de los términos de servicio durante la autenticación social y para los usuarios que hayan iniciado sesión.

  • wllegal habilita la misma integración y carga adicional de las plantillas de documentos legales alojadas en wllegal. Estas plantillas son utilizadas por los servicios operados por Weblate s.r.o. y no están destinadas al uso general.

Para proporcionar sus propios documentos legales en Docker, sobrescriba las plantillas en /app/data/python/customize/templates/legal/documents, consulte Reemplazo de logotipos y otros archivos estáticos.

Ejemplo:

environment:
  WEBLATE_LEGAL_INTEGRATION: tos-confirm

Ver también

WEBLATE_PUBLIC_ENGAGE

Habilita PUBLIC_ENGAGE.

WEBLATE_GOOGLE_ANALYTICS_ID

Configura el ID de Google Analytics cambiando GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE

Configura el título y el mensaje predeterminados para las solicitudes de extracción por medio de API cambiando DEFAULT_PULL_MESSAGE.

Ver también

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES

Configure el idioma simplificando normativa, consulte SIMPLIFY_LANGUAGES.

WEBLATE_HIDE_SHARED_GLOSSARY_COMPONENTS

Oculta componentes del glosario cuando compartieron en otros proyectos, consulte HIDE_SHARED_GLOSSARY_COMPONENTS.

WEBLATE_DEFAULT_ACCESS_CONTROL

Configure el Control de acceso predeterminado para proyectos nuevos, consulte DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_TRANSLATION_REVIEW

Added in version 5.16.

Configura el valor por defecto para Activar revisiones, apagado por defecto.

WEBLATE_DEFAULT_SOURCE_REVIEW

Added in version 5.16.

Configura el valor por defecto para Activar revisiones de origen, apagado por defecto.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT

Configure el valor predeterminado para Acceso restringido para componentes nuevos, consulte DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION

Configura el valor predeterminado para Conceder propagación de traducciones para componentes nuevos, consulte 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

Configure DEFAULT_AUTOCLEAN_TM.

WEBLATE_COMMIT_PENDING_HOURS

Configure el valor predeterminado para Antigüedad de cambios por consolidar para componentes nuevos, consulte COMMIT_PENDING_HOURS.

WEBLATE_GPG_IDENTITY

Configura la firma con GPG de consolidaciones; consulte WEBLATE_GPG_IDENTITY.

Ver también

Firmando consolidaciones de Git con GnuPG

WEBLATE_URL_PREFIX

Configura prefijo de URL donde Weblate está ejecutándose, consulte URL_PREFIX.

WEBLATE_STATIC_URL

Configura prefijo URL para archivos estáticos servidos desde CACHE_DIR.

WEBLATE_SILENCED_SYSTEM_CHECKS

Configura comprobantes los cuales no desean ser exhibidos, consulte 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

Concede personalizar cabeceras HTTP Content-Security-Policy.

Ver también

WEBLATE_LICENSE_FILTER

Configura LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED

Configura LICENSE_REQUIRED.

WEBLATE_WEBSITE_REQUIRED

Configura WEBSITE_REQUIRED.

WEBLATE_VERSION_DISPLAY

Configura VERSION_DISPLAY.

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

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

Configurar PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_PRIVATE_COMMIT_NAME_TEMPLATE

Added in version 5.16.

Configurar PRIVATE_COMMIT_NAME_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_NAME_OPT_IN

Added in version 5.16.

Configurar PRIVATE_COMMIT_NAME_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_VCS_ALLOW_HOSTS

Added in version 5.15.

Configura VCS_ALLOW_HOSTS.

WEBLATE_VCS_ALLOW_SCHEMES

Added in version 5.15.

Configura VCS_ALLOW_SCHEMES.

WEBLATE_VCS_RESTRICT_PRIVATE

Added in version 5.17.

Configura VCS_RESTRICT_PRIVATE.

WEBLATE_VCS_CLONE_DEPTH

Added in version 5.4.

Configura VCS_CLONE_DEPTH.

WEBLATE_VCS_API_DELAY

Added in version 5.4.

Configura VCS_API_DELAY.

WEBLATE_VCS_API_TIMEOUT

Added in version 5.15.

Configura VCS_API_TIMEOUT.

WEBLATE_CORS_ALLOWED_ORIGINS

Added in version 4.16.

Permitir solicitudes CORS al 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 al API desde todos los orígenes.

WEBLATE_WEBSITE_ALERTS_ENABLED

Added in version 5.17.

Configura WEBSITE_ALERTS_ENABLED.

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

Esta variable intencionalmente carece del prefijo WEBLATE_ ya que está compartido con contenedor de terceros utilizado en Certificados SSL automáticos con Let’s Encrypt.

WEBLATE_TRANSLATION_UPLOAD_MAX_SIZE

Configures TRANSLATION_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_COMPONENT_ZIP_UPLOAD_MAX_SIZE

Configures COMPONENT_ZIP_UPLOAD_MAX_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_UPLOAD_MAX_SIZE

Configures PROJECT_BACKUP_UPLOAD_MAX_SIZE.

The value is in bytes. Make sure CLIENT_MAX_BODY_SIZE is also large enough for uploaded backup files.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_MEMBERS

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_MEMBERS.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_TOTAL_UNCOMPRESSED_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MIN_RATIO_SIZE.

The value is in bytes.

WEBLATE_PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO

Added in version 2026.5.

Configures PROJECT_BACKUP_IMPORT_MAX_COMPRESSED_ENTRY_RATIO.

Credenciales de sitios de alojamiento de código

In the Docker container, the code hosting credentials can be configured either in separate variables or using a Python dictionary to set them at once. The following examples are for Solicitudes de incorporación de GitHub, but apply to all Integración de control de versiones with appropriately changed variable names.

Importante

Todos los nombres de variables de entorno deben incluir el prefijo WEBLATE_. Por ejemplo, para configurar las credenciales de GitHub, use WEBLATE_GITHUB_USERNAME, no GITHUB_USERNAME. Esto aplica tanto para la configuración de solicitudes de extracción como para cualquier otra integración de VCS.

Una configuración de ejemplo para solicitudes de incorporación a 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

Configures Solicitudes de incorporación de GitHub by changing GITHUB_CREDENTIALS.

Ver también

Configurar las credenciales de alojamiento de código en Docker

WEBLATE_GITLAB_USERNAME
WEBLATE_GITLAB_TOKEN
WEBLATE_GITLAB_HOST
WEBLATE_GITLAB_CREDENTIALS

Configures Solicitudes de fusión de GitLab by changing GITLAB_CREDENTIALS.

Ver también

Configurar las credenciales de alojamiento de código en Docker

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST
WEBLATE_GITEA_CREDENTIALS

Configures Solicitudes de incorporación de Gitea by changing GITEA_CREDENTIALS.

Ver también

Configurar las credenciales de alojamiento de código en Docker

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST
WEBLATE_PAGURE_CREDENTIALS

Configures Solicitudes de fusión de Pagure by changing PAGURE_CREDENTIALS.

Ver también

Configurar las credenciales de alojamiento de código en Docker

WEBLATE_BITBUCKETSERVER_USERNAME
WEBLATE_BITBUCKETSERVER_TOKEN
WEBLATE_BITBUCKETSERVER_HOST
WEBLATE_BITBUCKETSERVER_CREDENTIALS

Configures Solicitudes de incorporación al Centro de Datos Bitbucket by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME
WEBLATE_BITBUCKETCLOUD_WORKSPACE
WEBLATE_BITBUCKETCLOUD_TOKEN
WEBLATE_BITBUCKETCLOUD_HOST
WEBLATE_BITBUCKETCLOUD_CREDENTIALS

Configures Solicitud de incorporación a BitBucket Cloud by changing BITBUCKETCLOUD_CREDENTIALS.

Ver también

Configurar las credenciales de alojamiento de código en Docker

WEBLATE_AZURE_DEVOPS_USERNAME
WEBLATE_AZURE_DEVOPS_ORGANIZATION
WEBLATE_AZURE_DEVOPS_TOKEN
WEBLATE_AZURE_DEVOPS_HOST
WEBLATE_AZURE_DEVOPS_CREDENTIALS

Configures Solicitud de incorporación Azure DevOps by changing AZURE_DEVOPS_CREDENTIALS.

Ver también

Configurar las credenciales de alojamiento de código en 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

Consejo

El correo-e basado en autenticación está encendido a no ser que inhabilitado por WEBLATE_NO_EMAIL_AUTH.

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.

Ejemplo para bind directo:

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

Ejemplo para búsqueda y vínculo:

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

Ejemplo para búsqueda de fusión y vínculo:

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

Ejemplo de search y bind frente a Directorio Activo:

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 autenticación por Gitea.

Microsoft Entra ID

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET

Habilita la autenticación del ID Microsoft Entra, consulte Microsoft Entra ID.

Microsoft Entra ID 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 Microsoft Entra ID con soporte Tenant, consulte Microsoft Entra ID.

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.

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ID_KEY

Added in version 5.17.

Configura cual reclamo es utilizado como identificador único de usuario desde Keycloak. Por defecto a email.

Consejo

Cuando está configurado Keycloak a abstracto de terceros IDP, necesitará configurar WEBLATE_CSP_FORM_SRC para el dominio IDP de terceros.

Ejemplo cuando Keycloak está pasando autenticación a 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
WEBLATE_SOCIAL_AUTH_SLACK_SECRET

Habilita la autenticación de Slack, ver Slack.

Conexión OpenID

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)

Conexión OpenID de Fedora

Added in version 5.15.

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_KEY
WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_SECRET

Configura la integración de OpenID Connect de Fedora.

Ver también

Fedora

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

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

Set to false to disable environment based configuration of the database connection. Use Anulación de la configuración del volumen de datos 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

Configure el volcado diario de la base de datos utilizando DATABASE_BACKUP. Por defecto a plain.

Configuración del servidor de almacenamiento de datos

Es requerido utilizar Valkey o Redis para el contenedor Weblate y tiene que proporcionar una conexión de parámetros cuando ejecute Weblate en Docker.

Ver también

Configurar caché

REDIS_HOST

El nombre de host del servidor de almacén de datos o dirección IP. Por defecto a cache.

REDIS_PORT

El puerto del servidor almacenaje de datos. Predeterminado a 6379.

REDIS_DB

La número de base de datos del almacén de datos, por defecto a 1.

REDIS_USER

Added in version 5.13: El usuario de la base de datos del almacén de datos, no utilizado por defecto.

REDIS_PASSWORD

La contraseña del servidor del almacén de datos, no utilizado por defecto.

Ver también

Pasando secretos

REDIS_TLS

Habilita el uso de SSL para la conexión al almacén de datos.

REDIS_VERIFY_SSL

Se puede utilizar para desactivar la verificación de certificados SSL para la conexión del almacén de datos.

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.

WEBLATE_PASSWORD_RESET_URL

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

Configuration for CDN add-ons, including CDN de regionalización de JavaScript and Translation files CDN.

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

You are responsible for setting up serving of the files generated by Weblate, it only stores the files in configured location. See CDN de regionalización for secure serving guidance.

Ver también

Cambiar aplicaciones habilitadas, comprobaciones, complementos, traducción por máquina o auto-correcciones

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.

Por defecto a la mitad de WEBLATE_WORKERS, pero siempre es al menos 2.

Ejemplo:

environment:
  WEB_WORKERS: 4

Distinto en la versión 5.13: WEB_WORKERS configura cuantos procesos de trabajador utilizados por granian.

WEBLATE_SERVICE

Define qué servicios deben ejecutarse dentro del contenedor. Usa esto para Escala horizontalmente.

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

Tareas internas en segundo plano

WEBLATE_ANUBIS_URL

Added in version 5.11.4.

LA URL del servidor Anubis para manipular sub-solicitudes de autenticación. Esto puede ser útil para filtrar solicitudes HTTP entrantes utilizando prueba de trabajo para detener orugas de IA. Necesita configurar Anubis para Autenticación Subsolicitada para hacer que funcione.

Ver también

Volúmenes de contenedores Docker

Hay dos volúmenes (data y cache) exportados por el contenedor Weblate.

Nota

Los otros contenedores de servicio (tales como PostgreSQL o Valkey) tienen sus volúmenes de datos bien y son requeridos para mantener persistencia de Weblate.

El contenedor de PostgreSQL almacena la base de datos dentro del volumen /var/lib/postgresql y Valkey dentro del volumen /data. El contenedor Valkey no guarda los datos por defecto y necesita configuración adicional para habilitar persistencia.

Basada tu configuración sobre ejemplos proporcionados por Weblate o consulta su documentación para más información.

El volumen data se monta como /app/data y se utiliza para almacenar datos persistentes de Weblate, como repositorios clonados, o para personalizar la instalación de Weblate. DATA_DIR describe con más detalle qué se almacena aquí.

El volumen data también es un lugar para almacenar personalizaciones de Weblate tales como Anulación de la configuración del volumen de datos, Reemplazo de logotipos y otros archivos estáticos, o 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).

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, but the mount has to allow execution because Weblate stores generated helper files there.

When mounting /app/cache explicitly as tmpfs in Docker Compose, enable execution:

tmpfs:
  - /app/cache:exec

When also setting ownership options, keep the exec option:

tmpfs:
  - /app/cache:exec,uid=1000,gid=1000

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. Crear un paquete de Python personalizado.

  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 hace, como exponer la configuración como variables de entorno o permitir anular los ajustes 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 el lugar correspondiente al iniciar el contenedor, por lo que es necesario reiniciar Weblate tras 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 (consulte 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

El API interno 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 migración.

Puede colocar código Python adicional en /app/data/python/customize (consulte: 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.

An example of custom scheduled tasks in /app/data/python/customize/tasks.py.
"""Custom scheduled task."""

import subprocess  # noqa: S404

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)  # noqa: S607


@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"
    )

Integrar contenedores de terceros

La configuración de Weblate en Docker se puede ampliar con contenedores adicionales para proporcionar servicios complementarios como traducción automática, corrección ortográfica u otras herramientas que mejoran el flujo de trabajo de traducción. Estos servicios se pueden integrar en la configuración de Docker Compose y funcionan junto con Weblate.

Cuando añada contenedores de terceros, considere lo siguiente:

  • Conectividad de red. Asegure que contenedores pueden comunicar con cada otro colocándolos en la misma red Docker

  • Persistencia de datos: utilice volúmenes para servicios que necesiten datos persistentes

  • Seguridad: configure controles de acceso apropiado y evita exponer puertos innecesarios

Integración de contenedor Docker de LibreTranslate

LibreTranslate es un servicio de traducción de máquina de fuente-abierta que puede ser hospedado para sí. Es integrado con Weblate proporcionando capacidades de traducción con máquina sin depender de servicios externos.

Puedes integrar el servicio LibreTranslate en tu despliegue de Weblate incluyéndolo en un archivo docker-compose.override.yml. Dado que se ejecuta dentro de la red Docker, solo es accesible para Weblate y no está expuesto a Internet.

Configuración básica utilizando 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:

Para traslado de GPU acelerada (si tiene disponible NVIDIA GPU):

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:

Tras iniciar los servicios con docker compose down && docker compose up -d, configure LibreTransalte en Weblate:

  1. Accede al interfaz administrativa de Weblate

  2. Navega a Machine translation → Automatic suggestions

  3. Añade un servicio nuevo de LibreTranslate con:

    Servicio:

    LibreTranslate

    URL DE API:

    http://libretranslate:5000

    Clave API:

    Dejarlo vacío

LibreTranslate ahora está configurado y disponible para máquina de traducción en Weblate.

Nota

  • El servicio de LibreTranslate se ejecuta sin el IU de web (--disable-web-ui) y solo es accesible por medio del API sin la red Docker.

  • Los modelos nos actualizados automáticamente cuando el contenedor arranca. (LT_UPDATE_MODELS: true)

  • Los datos son persistente utilizando volúmenes de Docker para rendimiento óptimo y seguridad de los datos.

  • Las comprobaciones de estado garantizan que el motor de Docker observe correctamente el estado del servicio.

  • Su aceleración de GPU, utilice la variante de imagen CUDA y asegure su sistema tenga soporte de Docker NVIDIA. Este contenedor ejecuta como un usuario privilegiados para ser capaz de utilizar la GPU.

  • Sin puertos externos estén expuestos, realizando la configuración segura por defecto.

Ver también

Integración del contenedor Docker Anubis

Anubis es una utilidad de cortafuegos de web con IA para bloquear raspadores IA y otro tráfico disruptivo en el servidor. Típicamente es necesario para abrir públicamente las instalaciones de Weblate para evitar sobrecarga excesiva causada por raspadores.

Anubis puede ser desplegado utilizando Compose de Docker:

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

El volumen de anubis-data en la configuración anterior está esperado para contener botPolicies.yaml con una normativa de bot configurada para sus necesidades.

Como mínimo, necesita adjuntar códigos de estado como descritos en https://anubis.techaro.lol/docs/admin/configuration/subrequest-auth.

Además está recomendado para configurar el segundo plano de almacén persistente tal como describió en https://anubis.techaro.lol/docs/admin/policies/#storage-backends.

Entonces puede activar el empleo de Anubis en Weblate utilizando:

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.

La configuración puede ser ajustada como se describió en Configuración de Base de Datos en https://hub.docker.com/_/postgres. La configuración coincide con su entorno puede ser generado utilizando https://pgtune.leopard.in.ua/.

Internos del contenedor

El contenedor está utilizando supervisor para iniciar servicios individuales. En caso de Escala horizontalmente, solo inicia un servicio único dentro de un contenedor.

Para comprobar el estado de uso de los servicios:

docker compose exec --user weblate weblate supervisorctl status

Hay servicios individuales por cada solicitud de Celery (consulte Tareas en segundo plano con Celery para detalles). Puede detener procesar algunas taras deteniendo el trabajados apropiado:

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