Installation über Docker

Mit der Bereitstellung von Weblate über Docker können Sie Ihre persönliche Weblate-Instanz in Sekundenschnelle zum Laufen bringen. Alle Abhängigkeiten von Weblate sind bereits enthalten. PostgreSQL ist als Standarddatenbank und Valkey als Caching-Backend eingerichtet.

Hardwareanforderungen

Weblate sollte auf jeder modernen Hardware problemlos laufen. Nachfolgend finden Sie die minimale Konfiguration, die erforderlich ist, um Weblate auf einem einzelnen Host zu betreiben (Weblate, Datenbank und Webserver):

  • 3 GB Arbeitsspeicher

  • 2 CPU-Kerne

  • 1 GB Speicherplatz

Bemerkung

Die tatsächlichen Anforderungen an Ihre Weblate-Installation hängen stark von der Größe der darin verwalteten Übersetzungen ab.

RAM-Auslastung

Je mehr Arbeitsspeicher, desto besser – er wird für das Caching auf allen Ebenen (Dateisystem, Datenbank und Weblate) verwendet. Für Hunderte von Übersetzungskomponenten werden mindestens 4 GB RAM empfohlen.

Hinweis

Für Systeme mit weniger Arbeitsspeicher, wird Celery-Einzelprozess einrichten empfohlen.

CPU-Auslastung

Viele gleichzeitige Benutzer erhöhen die Anzahl der benötigten CPU-Kerne.

Speichernutzung

Der typische Speicherbedarf der Datenbank liegt bei 300 MB pro 1 Million gehosteter Wörter.

Der benötigte Speicherplatz für geklonte Repositorys variiert, aber Weblate versucht, die Größe der Repositorys durch flache Klone gering zu halten.

Knoten

Für kleine und mittelgroße Plattformen (Millionen von gehosteten Wörtern) können alle Komponenten von Weblate (siehe Architekturübersicht) auf einem einzigen Knoten ausgeführt werden.

Wenn die Anzahl der gehosteten Wörter auf Hunderte Millionen anwächst, empfiehlt sich ein dedizierter Knoten für die Datenbank (siehe Datenbankeinrichtung für Weblate).

Installation

Hinweis

Die folgenden Beispiele gehen davon aus, dass Sie eine funktionierende Docker-Umgebung haben, in der docker-compose-plugin installiert ist. Anweisungen hierzu finden Sie in der Docker-Dokumentation.

Dadurch wird ein Weblate-Bereitstellungsserver über HTTP erstellt, daher sollten Sie ihn hinter einem abschließenden HTTPS-Proxy platzieren. Sie können auch einen HTTPS-Proxy einsetzen, siehe Automatische SSL-Zertifikate mit Let’s Encrypt. Für größere Installationen siehe Horizontale Skalierung.

  1. Das Weblate-Docker-Repository klonen:

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

  2. Eine docker-compose.override.yml mit den eigenen Einstellungen erstellen. Siehe Docker-Umgebungsvariablen für eine vollständige Liste der Umgebungsvariablen.

    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

    Bemerkung

    Wenn WEBLATE_ADMIN_PASSWORD nicht gesetzt ist, wird der Benutzer admin mit einem zufälligen Passwort erstellt, das beim ersten Start angezeigt wird.

    Das mitgelieferte Beispiel lässt Weblate auf Port 80 lauschen. Bearbeiten Sie die Portzuordnung in der Datei docker-compose.override.yml, um sie zu ändern.

  3. Weblate-Container starten:

    docker compose up

Viel Spaß beim Einsatz von Weblate, es ist über Port 80 des Containers weblate erreichbar.

Siehe auch

Aufrufen von Verwaltungsbefehlen

Docker-Image-Registry auswählen

Weblate-Container werden in den folgenden Registrys veröffentlicht:

Bemerkung

Alle Beispiele beziehen derzeit Images von Docker Hub, bitte passen Sie die Konfiguration entsprechend an, um eine andere Registry zu verwenden.

Docker-Image-Tag auswählen

Bitte wählen Sie einen Tag, der Ihrer Einsatzumgebung und Ihren Erwartungen entspricht:

Tag-Name

Beschreibung

Anwendungsfall

latest

Stabile Version von Weblate, entspricht der neuesten getaggten Version

Fortlaufende Updates in einer Produktionsumgebung

<YEAR>

Stabile Weblate-Version

Rolling updates within a calendar year in a production environment

<YEAR>.<MONTH>

Stabile Weblate-Version

Rolling updates within a monthly release in a production environment

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

Stabile Weblate-Version

Gut definierter Einsatz in einer Produktionsumgebung

edge

Stabile Weblate-Version mit Entwicklungsänderungen im Docker-Container (z. B. aktualisierte Abhängigkeiten)

Fortlaufende Updates in einer Staging-Umgebung

edge-<DATE>-<SHA>

Stabile Weblate-Version mit Entwicklungsänderungen im Docker-Container (z. B. aktualisierte Abhängigkeiten)

Gut definierter Einsatz in einer Staging-Umgebung

bleeding

Weblate-Entwicklungsversion von Git

Fortlaufende Aktualisierungen zum Testen kommender Weblate-Funktionen

bleeding-<DATE>-<SHA>

Weblate-Entwicklungsversion von Git

Gut definierter Einsatz zum Testen kommender Weblate-Funktionen

Jedes Image wird vor der Veröffentlichung von unserer CI getestet, sodass selbst die bleeding-Version sicher verwendbar ist.

Eine vollständige Liste der veröffentlichten Tags finden Sie unter GitHub Packages

Docker-Container mit HTTPS-Unterstützung

Bitte lesen Sie Installation für allgemeine Bereitstellungsanweisungen, dieser Abschnitt erwähnt nur Unterschiede im Vergleich dazu.

SSL-Termination-Proxy

SSL kann außerhalb des Weblate-Containers aufgelöst werden. Damit dies gut funktioniert, müssen mehrere Header an den Container übergeben werden, damit er seine aktuelle Einsatzumgebung kennt. Diese Header werden unter Hinter einem Reverse-Proxy ausführen genauer beschrieben.

Beispielkonfiguration eines nginx-Reverse-Proxys für einen Docker-Container.
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;
}
Docker-Container-Einsatzumgebung für externe SSL-Terminierung.
WEBLATE_ENABLE_HTTPS=1
WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR

Eigene SSL-Zertifikate verwenden

Wenn Sie ein eigenes SSL-Zertifikat haben, das Sie verwenden möchten, legen Sie die Dateien einfach in das Weblate-Daten-Volume (siehe Docker-Container-Volumes):

  • ssl/fullchain.pem, die das Zertifikat einschließlich aller erforderlichen CA-Zertifikate enthält

  • ssl/privkey.pem mit dem privaten Schlüssel

Beide Dateien müssen demselben Benutzer gehören wie demjenigen, der den Docker-Container startet und die Dateimaske muss auf 600 gesetzt sein (nur lesbar und schreibbar für den besitzenden Benutzer).

Außerdem akzeptiert der Weblate-Container jetzt SSL-Verbindungen auf Port 4443. Sie müssen die Portweiterleitung für HTTPS in die Docker-Compose-Überschreibung aufnehmen:

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

Wenn Sie bereits andere Sites auf demselben Server hosten, werden die Ports 80 und 443 wahrscheinlich von einem Reverse-Proxy wie NGINX verwendet. Um die HTTPS-Verbindung von NGINX an den Docker-Container zu übergeben, können Sie die folgende Konfiguration verwenden:

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>;
    }
}

Ersetzen Sie <SITE_URL>, <SITE> und <EXPOSED_DOCKER_PORT> durch tatsächliche Werte aus Ihrer Einsatzumgebung.

Automatische SSL-Zertifikate mit Let’s Encrypt

Für den Fall, dass Sie automatisch generierte Let’s Encrypt SSL-Zertifikate auf der öffentlichen Installation verwenden möchten, müssen Sie einen Reverse-HTTPS-Proxy in einem zusätzlichen Docker-Container hinzufügen, https-portal wird dafür verwendet. Dieser wird in der Datei docker-compose-https.yml verwendet. Anschließend erstellen Sie eine Datei docker-compose-https.override.yml mit Ihren Einstellungen:

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'

Bei jedem Aufruf von docker compose müssen Sie beide Dateien übergeben und dann Folgendes tun:

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

Den Docker-Container aktualisieren

Normalerweise ist es eine gute Idee, nur den Weblate-Container zu aktualisieren und den PostgreSQL-Container auf der vorhandenen Version zu belassen, da ein Upgrade von PostgreSQL ziemlich mühsam ist und in den meisten Fällen nicht viel bringt.

Sie können dies tun, indem Sie das bestehende Docker-Compose beibehalten und einfach die neuesten Images ziehen und dann neu starten:

# 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

Die Weblate-Datenbank sollte beim ersten Start automatisch migriert werden, und es sollten keine weiteren manuellen Maßnahmen erforderlich sein.

Bemerkung

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

Sie können auch das docker-compose Repository aktualisieren, obwohl dies in den meisten Fällen nicht notwendig ist. Siehe PostgreSQL-Container aktualisieren für die Aktualisierung des PostgreSQL-Servers.

PostgreSQL-Container aktualisieren

Bemerkung

PostgreSQL 18 hat das Standard-Datenverzeichnis innerhalb des Containers geändert. Eine häufigere ältere Konfiguration hat das Datenbank-Volume unter /var/lib/postgresql/data eingehängt, während PostgreSQL 18 nun standardmäßig /var/lib/postgresql verwendet.

Wenn Sie von einer älteren Version upgraden, aktualisieren Sie entweder das Einhängeziel in Ihrer Docker-Konfiguration auf den neuen Pfad, oder behalten Sie das alte Einhängeziel bei und setzen Sie PGDATA entsprechend.

Wenn Sie das alte Einhängeziel unverändert lassen, ohne PGDATA zu setzen, kann dies dazu führen, dass PostgreSQL seine Daten außerhalb des dauerhaften Volumes schreibt.

Siehe PGDATA-Dokumentation für weitere Informationen.

PostgreSQL-Container unterstützen kein automatisches Upgrade zwischen Versionen, Sie müssen das Upgrade manuell durchführen. Die folgenden Schritte zeigen eine der Möglichkeiten des Upgrades.

Siehe auch

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

  1. Weblate-Container stoppen:

    docker compose stop weblate cache

  2. Datenbank sichern:

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

  3. Datenbank-Container sperren:

    docker compose stop database

  4. PostgreSQL-Volumen entfernen:

    docker compose rm -v database
docker volume remove weblate-docker_postgres-data

    Hinweis

    Der Volume-Name enthält den Namen des Docker-Compose-Projekts, der standardmäßig der Verzeichnisname ist, das in dieser Dokumentation weblate-docker heißt.

  5. docker-compose.yml anpassen, um die neue PostgreSQL-Version zu verwenden.

  6. Datenbank-Container öffnen:

    docker compose up -d database

  7. Datenbank aus Sicherung wiederherstellen:

    cat backup.sql | docker compose exec -T database psql --username weblate --dbname weblate

    Hinweis

    Bitte prüfen Sie, ob der Datenbankname mit POSTGRES_DB übereinstimmt.

  8. (Optional) Das Passwort für den Weblate-Benutzer aktualisieren. Dies kann bei der Migration auf PostgreSQL 14 oder 15 erforderlich sein, da die Art der Speicherung von Passwörtern geändert wurde:

    docker compose exec -T database psql --username weblate --dbname weblate -c "ALTER USER weblate WITH PASSWORD 'weblate'"

    Hinweis

    Bitte prüfen Sie, ob der Datenbankname mit POSTGRES_DB übereinstimmt.

  9. Alle verbleibenden Container öffnen:

    docker compose up -d

Administratoranmeldung

Nach der Container-Einrichtung können Sie sich als Benutzer admin mit dem in WEBLATE_ADMIN_PASSWORD bereitgestellten Passwort oder, falls es nicht festgelegt wurde, mit einem beim ersten Öffnen generierten Zufallspasswort anmelden.

Um das Passwort für admin zurückzusetzen, öffnen Sie den Container mit dem in WEBLATE_ADMIN_PASSWORD neu festgelegten Passwort nochmals.

Siehe auch

Anzahl der Prozesse und Speicherverbrauch

Die Anzahl der Worker-Prozesse wird sowohl für WSGI als auch Celery automatisch anhand der Anzahl der CPUs bestimmt. Dies funktioniert gut für die meisten virtuellen Maschinen in der Cloud, da diese normalerweise über wenige CPUs und viel Arbeitsspeicher verfügen.

Für den Fall, dass Sie sehr viele CPU-Kerne haben und auf Speicherprobleme stoßen, versuchen Sie die Zahl der Worker zu reduzieren:

environment:
  WEBLATE_WORKERS: 2

Sie können auch einzelne Worker-Kategorien feinabstimmen:

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

Die Speicherauslastung kann weiter reduziert werden, indem nur ein einziger Celery-Prozess ausgeführt wird:

environment:
  CELERY_SINGLE_PROCESS: 1

Siehe auch

Horizontale Skalierung

Added in version 4.6.

Sie können mehrere Weblate-Container ausführen, um den Dienst horizontal zu skalieren. Das Volume /app/data muss von allen Containern gemeinsam genutzt werden, es wird empfohlen, dafür ein Cluster-Dateisystem wie z. B. GlusterFS zu verwenden. Das Volume /app/cache sollte für jeden Container separat sein.

Jeder Weblate-Container verfügt über eine definierte Rolle, die über die Umgebungsvariable WEBLATE_SERVICE festgelegt wird. Bitte befolgen Sie die Dokumentation sorgfältig, da einige der Dienste nur einmal im Cluster ausgeführt werden sollten und die Reihenfolge der Dienste ebenfalls wichtig ist.

Eine Beispieleinrichtung finden Sie im docker-compose-Repo als docker-compose-split.yml.

Docker-Umgebungsvariablen

Vieles von der Weblate-Konfiguration kann mit den unten beschriebenen Umgebungsvariablen im Docker-Container eingestellt werden.

Wenn Sie eine Einstellung definieren müssen, die nicht über Docker-Umgebungsvariablen zugänglich ist, siehe Konfiguration über Umgebungsvariablen hinaus.

Geheimnisse weitergeben

Added in version 5.0.

Der Weblate-Container unterstützt die Weitergabe von Geheimnissen als Dateien. Um dies zu nutzen, hängen Sie das Suffix _FILE an die Umgebungsvariable an und übergeben Sie die geheime Datei über Docker.

Die zugehörige docker-compose.yml könnte so aussehen:

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

Siehe auch

Wie man Geheimnisse in Docker Compose verwendet

Allgemeine Einstellungen

WEBLATE_DEBUG

Konfiguriert den Debugmodus von Django mit DEBUG.

Beispiel:

environment:
  WEBLATE_DEBUG: 1

Siehe auch

Debugmodus deaktivieren

WEBLATE_LOGLEVEL

Legt die Ausführlichkeit der Protokollierung fest. Auf DEBUG setzen, um ausführlichere Protokolle zu erhalten.

Der Standardwert ist INFO wenn WEBLATE_DEBUG ausgeschaltet ist, DEBUG wird verwendet, wenn der Debugmodus eingeschaltet ist.

Für eine ruhigere Protokollierung ERROR oder WARNING verwenden.

WEBLATE_LOGLEVEL_DATABASE

Konfiguriert die Protokollierung der Ausführlichkeit der Datenbankabfragen.

WEBLATE_LOG_GELF_HOST

Added in version 5.9.

Konfiguriert die Remote-Protokollierung über eine GELF-TCP-Verbindung. Kann zur Integration mit Graylog verwendet werden.

WEBLATE_LOG_GELF_PORT

Added in version 5.9.

Verwendet einen benutzerdefinierten Port für WEBLATE_LOG_GELF_HOST, Standardwert ist 12201.

WEBLATE_SITE_TITLE

Ändert den Seitentitel, der in der Kopfzeile aller Seiten angezeigt wird.

WEBLATE_SITE_DOMAIN

Konfiguriert die Seitendomain. Dieser Parameter ist erforderlich.

Port angeben, wenn ein nicht standardmäßiger verwendet wird.

Beispiel:

environment:
  WEBLATE_SITE_DOMAIN: example.com:8080

Siehe auch

WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Legt den Namen und die E-Mail-Adresse des Website-Administrators fest. Es wird sowohl für die ADMINS-Einstellung als auch für die Erstellung des admin-Benutzers verwendet (siehe WEBLATE_ADMIN_PASSWORD für weitere Informationen dazu).

Beispiel:

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

Siehe auch

WEBLATE_ADMIN_PASSWORD

Setzt das Passwort für den Benutzer admin.

  • Wenn nicht gesetzt und der Benutzer admin nicht existiert, wird er mit einem zufälligen Passwort erstellt, das beim ersten Start des Containers angezeigt wird.

  • Wenn nicht gesetzt und der Benutzer admin existiert, wird keine Aktion durchgeführt.

  • Wenn gesetzt, wird der admin-Benutzer bei jedem Start des Containers angepasst, um WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME und WEBLATE_ADMIN_EMAIL zu entsprechen.

Warnung

Es könnte ein Sicherheitsrisiko darstellen, das Passwort in der Konfigurationsdatei zu speichern. Erwägen Sie, diese Variable nur für die Ersteinrichtung zu verwenden (oder lassen Sie Weblate beim ersten Start ein zufälliges Passwort generieren) oder für die Wiederherstellung des Passworts.

Siehe auch

WEBLATE_ADMIN_NOTIFY_ERROR

Ob bei einem Serverfehler eine E-Mail an Administratoren gesendet werden soll. Standardmäßig aktiviert.

Möglicherweise möchten Sie eine andere Fehlersammlung wie Sentry oder Rollbar verwenden und diese hier ausschalten.

Siehe auch

WEBLATE_SERVER_EMAIL

Die E-Mail-Adresse, von der aus Fehlermeldungen gesendet werden.

Siehe auch

WEBLATE_DEFAULT_FROM_EMAIL

Legt die Adresse für ausgehende E-Mails fest.

Siehe auch

WEBLATE_ADMINS_CONTACT

Konfiguriert ADMINS_CONTACT.

WEBLATE_CONTACT_FORM

Konfiguriert das Verhalten des Kontaktformulars, siehe CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS

Konfiguriert erlaubte HTTP-Hostnamen mit ALLOWED_HOSTS.

Der Standardwert ist *, der alle Hostnamen zulässt.

Beispiel:

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

Siehe auch

WEBLATE_REGISTRATION_OPEN

Legt fest, ob Registrierungen offen sind, durch Umschaltung von REGISTRATION_OPEN.

Beispiel:

environment:
  WEBLATE_REGISTRATION_OPEN: 0
WEBLATE_REGISTRATION_CAPTCHA

Added in version 5.10.

Legt fest, ob Captcha für die Registrierung und andere nicht authentifizierte Aktionen verwendet wird, siehe REGISTRATION_CAPTCHA.

Beispiel:

environment:
  WEBLATE_REGISTRATION_CAPTCHA: 0
WEBLATE_REGISTRATION_ALLOW_BACKENDS

Konfiguriert, welche Authentifizierungsmethoden zum Erstellen eines neuen Kontos verwendet werden können, über REGISTRATION_ALLOW_BACKENDS.

Beispiel:

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

Added in version 4.16.

Konfiguriert REGISTRATION_REBIND.

WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS

Added in version 5.16.1.

Konfiguriert REGISTRATION_ALLOW_DISPOSABLE_EMAILS.

Beispiel:

environment:
  WEBLATE_REGISTRATION_ALLOW_DISPOSABLE_EMAILS: 1
WEBLATE_PROJECT_WEB_RESTRICT_PRIVATE

Added in version 5.17.

Konfiguriert PROJECT_WEB_RESTRICT_PRIVATE.

Standardwert ist eingeschaltet.

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.

Konfiguriert WEBHOOK_RESTRICT_PRIVATE.

Standardwert ist eingeschaltet.

WEBLATE_WEBHOOK_PRIVATE_ALLOWLIST

Added in version 5.17.

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

Standardwert ist eingeschaltet.

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

Konfiguriert die verwendete Zeitzone in Weblate, siehe TIME_ZONE.

Bemerkung

Um die Zeitzone des Docker-Containers selbst zu ändern, die Umgebungsvariable TZ verwenden.

Beispiel:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague
WEBLATE_ENABLE_HTTPS

Lässt Weblate davon ausgehen, dass es hinter einem Reverse-HTTPS-Proxy betrieben wird, und bringt Weblate dazu, HTTPS in E-Mails und API-Links zu verwenden oder sichere Markierungen für Cookies zu setzen.

Hinweis

Bitte lesen Sie die ENABLE_HTTPS-Dokumentation für mögliche Vorsichtsmaßnahmen.

Bemerkung

Dies führt nicht dazu, dass der Weblate-Container HTTPS-Verbindungen akzeptiert. Sie müssen dies ebenfalls konfigurieren, siehe Docker-Container mit HTTPS-Unterstützung für Beispiele.

Beispiel:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Siehe auch

WEBLATE_NGINX_IPV6

Added in version 5.17.

Legt fest, ob das mitgelieferte NGINX auf IPv6-Adressen lauscht.

Unterstützte Werte sind:

  • „auto, um IPv6-Listener nur zu aktivieren, wenn IPv6 in der Container-Laufzeitumgebung verfügbar ist. Dies ist die Voreinstellung.

  • on, um IPv6-Listener immer zu aktivieren.

  • off, um IPv6-Listener zu deaktivieren.

Beispiel:

environment:
  WEBLATE_NGINX_IPV6: auto
WEBLATE_IP_PROXY_HEADER

Ermöglicht es Weblate, die IP-Adresse aus einem beliebigen HTTP-Header abzurufen. Verwenden Sie dies, wenn Sie einen Reverse-Proxy vor dem Weblate-Container einsetzen.

Aktiviert IP_BEHIND_REVERSE_PROXY und setzt IP_PROXY_HEADER.

Bemerkung

Das Format muss mit den Erwartungen von Django übereinstimmen. Django wandelt rohe HTTP-Header-Namen wie folgt um:

  • wandelt alle Zeichen in Großbuchstaben um

  • ersetzt alle Bindestriche durch Unterstriche

  • stellt den HTTP_-Präfix voran

So würde X-Forwarded-For auf HTTP_X_FORWARDED_FOR abgebildet werden.

Beispiel:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR
WEBLATE_IP_PROXY_OFFSET

Added in version 5.0.1.

Konfiguriert IP_PROXY_OFFSET.

WEBLATE_USE_X_FORWARDED_PORT

Added in version 5.0.1.

Ein boolescher Wert, der angibt, ob der X-Forwarded-Port-Header anstelle der SERVER_PORT META-Variable verwendet werden soll. Dies sollte nur aktiviert werden, wenn ein Proxy verwendet wird, der diesen Header setzt.

Siehe auch

USE_X_FORWARDED_PORT

Bemerkung

Dies ist eine boolesche Einstellung ("true" oder "false" verwenden).

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.

Beispiel:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https

Siehe auch

WEBLATE_REQUIRE_LOGIN

Aktiviert REQUIRE_LOGIN, um die Authentifizierung auf dem gesamten Weblate zu erzwingen.

Beispiel:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

Aktiviert das Modul Rechtsmodul in Docker-Bereitstellungen. Standardmäßig ist die Integration deaktiviert; lassen Sie diese Variable nicht gesetzt oder leer, um sie zu deaktivieren.

Unterstützte Werte sind:

  • tos-confirm, um das Rechtsmodul zu aktivieren und die Bestätigung der Nutzungsbedingungen während der sozialen Authentifizierung und für angemeldete Benutzer durchzusetzen.

  • wllegal, um dieselbe Integration zu ermöglichen und zusätzlich die gehosteten rechtlichen Dokumentenvorlagen von wllegal zu laden. Diese Vorlagen werden von den von Weblate s.r.o. betriebenen Diensten verwendet, und sind nicht für den allgemeinen Gebrauch bestimmt.

Um Ihre eigenen rechtlichen Dokumente in Docker bereitzustellen, überschreiben Sie die Vorlagen in /app/data/python/customize/templates/legal/documents, siehe Logo und andere statische Dateien ersetzen.

Beispiel:

environment:
  WEBLATE_LEGAL_INTEGRATION: tos-confirm

Siehe auch

WEBLATE_PUBLIC_ENGAGE

Konfiguriert PUBLIC_ENGAGE.

WEBLATE_GOOGLE_ANALYTICS_ID

Konfiguriert die ID für Google Analytics durch Ändern von GOOGLE_ANALYTICS_ID.

WEBLATE_DEFAULT_PULL_MESSAGE

Konfiguriert den Standardtitel und die Nachricht für Pull Requests über die API durch Ändern von DEFAULT_PULL_MESSAGE.

Siehe auch

DEFAULT_PULL_MESSAGE

WEBLATE_SIMPLIFY_LANGUAGES

Konfiguriert die Richtlinie zur Sprachvereinfachung, siehe SIMPLIFY_LANGUAGES.

WEBLATE_HIDE_SHARED_GLOSSARY_COMPONENTS

Blendet Glossarkomponenten aus, wenn sie mit anderen Projekte geteilt werden, siehe HIDE_SHARED_GLOSSARY_COMPONENTS.

WEBLATE_DEFAULT_ACCESS_CONTROL

Konfiguriert die standardmäßige Zugriffssteuerung für neue Projekte, siehe DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_TRANSLATION_REVIEW

Added in version 5.16.

Konfiguriert den Standardwert von Überprüfung aktivieren, standardmäßig ausgeschaltet.

WEBLATE_DEFAULT_SOURCE_REVIEW

Added in version 5.16.

Konfiguriert den Standardwert von Quellenüberprüfung aktivieren, standardmäßig ausgeschaltet.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT

Legt den Standardwert für Eingeschränkter Zugriff für neue Komponenten fest, siehe DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION

Legt den Standardwert für Weitergabe von Übersetzungen erlauben für neue Komponenten fest, siehe DEFAULT_TRANSLATION_PROPAGATION.

WEBLATE_DEFAULT_COMMITER_EMAIL

Konfiguriert DEFAULT_COMMITER_EMAIL.

WEBLATE_DEFAULT_COMMITER_NAME

Konfiguriert DEFAULT_COMMITER_NAME.

WEBLATE_DEFAULT_SHARED_TM

Konfiguriert DEFAULT_SHARED_TM.

WEBLATE_DEFAULT_AUTOCLEAN_TM

Konfiguriert DEFAULT_AUTOCLEAN_TM.

WEBLATE_COMMIT_PENDING_HOURS

Legt den Standardwert für Alter der Änderungen, bis ein Commit erfolgt für neue Komponenten fest, siehe COMMIT_PENDING_HOURS.

WEBLATE_GPG_IDENTITY

Konfiguriert die GPG-Signierung von Commits, siehe WEBLATE_GPG_IDENTITY.

Siehe auch

Git-Commits mit GnuPG signieren

WEBLATE_URL_PREFIX

Konfiguriert den URL-Präfix, unter dem Weblate läuft, siehe URL_PREFIX.

WEBLATE_STATIC_URL

Konfiguriert das URL-Präfix für statische Dateien, die von CACHE_DIR bereitgestellt werden.

WEBLATE_SILENCED_SYSTEM_CHECKS

Konfiguriert Prüfungen, die nicht angezeigt werden sollen, siehe 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

Ermöglicht das Anpassen des HTTP-Headers Content-Security-Policy.

Siehe auch

WEBLATE_LICENSE_FILTER

Konfiguriert LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED

Konfiguriert LICENSE_REQUIRED.

WEBLATE_WEBSITE_REQUIRED

Konfiguriert WEBSITE_REQUIRED.

WEBLATE_VERSION_DISPLAY

Konfiguriert VERSION_DISPLAY.

WEBLATE_HIDE_VERSION

Konfiguriert HIDE_VERSION.

WEBLATE_BASIC_LANGUAGES

Konfiguriert BASIC_LANGUAGES.

WEBLATE_DEFAULT_AUTO_WATCH

Konfiguriert DEFAULT_AUTO_WATCH.

WEBLATE_RATELIMIT_ATTEMPTS
WEBLATE_RATELIMIT_LOCKOUT
WEBLATE_RATELIMIT_WINDOW

Added in version 4.6.

Konfiguriert den Ratenbegrenzer.

Hinweis

Sie können die Konfiguration für beliebige Ratenbegrenzer-Bereiche festlegen. Fügen Sie dazu das Präfix WEBLATE_ zu einer der in Ratenbegrenzung beschriebenen Einstellungen hinzu.

Siehe auch

WEBLATE_API_RATELIMIT_ANON
WEBLATE_API_RATELIMIT_USER

Added in version 4.11.

Konfiguriert die API-Ratenbegrenzung. Der Standardwert ist 100/day für anonyme und 5000/hour für authentifizierte Benutzer.

Siehe auch

API-Ratenbegrenzung

WEBLATE_ENABLE_HOOKS

Added in version 4.13.

Konfiguriert ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS

Added in version 4.6.1.

Konfiguriert ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX

Added in version 4.15.

Konfiguriert AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH

Added in version 4.9.

Konfiguriert LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS

Added in version 4.9.

Konfiguriert SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS

Added in version 4.9.

Konfiguriert BORG_EXTRA_ARGS als komma-getrennte Liste von Argumenten.

Beispiel:

environment:
  WEBLATE_BORG_EXTRA_ARGS: --exclude,vcs/
WEBLATE_ENABLE_SHARING

Added in version 4.14.1.

Konfiguriert ENABLE_SHARING.

WEBLATE_SUPPORT_STATUS_CHECK

Added in version 5.5.

Konfiguriert SUPPORT_STATUS_CHECK.

WEBLATE_EXTRA_HTML_HEAD

Added in version 4.15.

Konfiguriert EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE

Added in version 4.15.

Konfiguriert PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN

Added in version 4.15.

Konfiguriert PRIVATE_COMMIT_EMAIL_OPT_IN.

WEBLATE_PRIVATE_COMMIT_NAME_TEMPLATE

Added in version 5.16.

Konfiguriert PRIVATE_COMMIT_NAME_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_NAME_OPT_IN

Added in version 5.16.

Konfiguriert PRIVATE_COMMIT_NAME_OPT_IN.

WEBLATE_UNUSED_ALERT_DAYS

Added in version 4.17.

Konfiguriert UNUSED_ALERT_DAYS.

WEBLATE_UPDATE_LANGUAGES

Added in version 4.3.2.

Konfiguriert UPDATE_LANGUAGES.

WEBLATE_VCS_ALLOW_HOSTS

Added in version 5.15.

Konfiguriert VCS_ALLOW_HOSTS.

WEBLATE_VCS_ALLOW_SCHEMES

Added in version 5.15.

Konfiguriert VCS_ALLOW_SCHEMES.

WEBLATE_VCS_RESTRICT_PRIVATE

Added in version 5.17.

Konfiguriert VCS_RESTRICT_PRIVATE.

WEBLATE_VCS_CLONE_DEPTH

Added in version 5.4.

Konfiguriert VCS_CLONE_DEPTH.

WEBLATE_VCS_API_DELAY

Added in version 5.4.

Konfiguriert VCS_API_DELAY.

WEBLATE_VCS_API_TIMEOUT

Added in version 5.15.

Konfiguriert VCS_API_TIMEOUT.

WEBLATE_CORS_ALLOWED_ORIGINS

Added in version 4.16.

Lässt CORS-Anfragen an die API von bestimmten Quellen zu.

Beispiel:

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

Added in version 5.6.1: Lässt CORS-Anfragen an die API von allen Quellen zu.

WEBLATE_WEBSITE_ALERTS_ENABLED

Added in version 5.17.

Konfiguriert WEBSITE_ALERTS_ENABLED.

CLIENT_MAX_BODY_SIZE

Added in version 4.16.3.

Konfiguriert die maximale Dateigröße, die vom integrierten Webserver akzeptiert wird.

environment:
    CLIENT_MAX_BODY_SIZE: 200m

Hinweis

Dieser Variable fehlt absichtlich das Präfix WEBLATE_, da sie mit dem in Automatische SSL-Zertifikate mit Let’s Encrypt verwendeten Container eines Drittanbieters geteilt wird.

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.

Zugangsdaten für Code-Hosting-Sites

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 GitHub-Pull-Requests, but apply to all Integration der Versionsverwaltung with appropriately changed variable names.

Wichtig

Alle Namen von Umgebungsvariablen müssen das Präfix WEBLATE_ enthalten. Um zum Beispiel die Zugangsdaten für GitHub zu konfigurieren, verwenden Sie WEBLATE_GITHUB_USERNAME, nicht GITHUB_USERNAME. Dies gilt unabhängig davon, ob Sie die Konfiguration für Pull Requests oder eine andere VCS-Integration vornehmen.

Eine Beispielkonfiguration für GitHub-Pull-Requests könnte wie folgt aussehen:

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

Wird verwendet als:

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

Alternativ kann das Python-Wörterbuch auch als Zeichenkette angegeben werden:

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

Oder den Pfad zu einer Datei, die das Python-Wörterbuch enthält:

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 GitHub-Pull-Requests by changing GITHUB_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_GITLAB_USERNAME
WEBLATE_GITLAB_TOKEN
WEBLATE_GITLAB_HOST
WEBLATE_GITLAB_CREDENTIALS

Configures GitLab-Merge-Requests by changing GITLAB_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST
WEBLATE_GITEA_CREDENTIALS

Configures Gitea-Pull-Requests by changing GITEA_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST
WEBLATE_PAGURE_CREDENTIALS

Configures Pagure-Merge-Requests by changing PAGURE_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_BITBUCKETSERVER_USERNAME
WEBLATE_BITBUCKETSERVER_TOKEN
WEBLATE_BITBUCKETSERVER_HOST
WEBLATE_BITBUCKETSERVER_CREDENTIALS

Configures Bitbucket-Data-Center-Pull-Requests by changing BITBUCKETSERVER_CREDENTIALS.

WEBLATE_BITBUCKETCLOUD_USERNAME
WEBLATE_BITBUCKETCLOUD_WORKSPACE
WEBLATE_BITBUCKETCLOUD_TOKEN
WEBLATE_BITBUCKETCLOUD_HOST
WEBLATE_BITBUCKETCLOUD_CREDENTIALS

Configures Bitbucket-Cloud-Pull-Requests by changing BITBUCKETCLOUD_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

WEBLATE_AZURE_DEVOPS_USERNAME
WEBLATE_AZURE_DEVOPS_ORGANIZATION
WEBLATE_AZURE_DEVOPS_TOKEN
WEBLATE_AZURE_DEVOPS_HOST
WEBLATE_AZURE_DEVOPS_CREDENTIALS

Configures Azure-DevOps-Pull-Requests by changing AZURE_DEVOPS_CREDENTIALS.

Siehe auch

Konfiguration der Code-Hosting-Zugangsdaten in Docker

Automatische Vorschlagseinstellungen

Geändert in Version 4.13: Automatische Vorschlagsdienste werden jetzt in der Bedienoberfläche konfiguriert, siehe Automatische Vorschläge.

Die vorhandenen Umgebungsvariablen werden bei der Migration auf Weblate 4.13 importiert, sie zu ändern hat jedoch keine weiteren Auswirkungen.

Authentifizierungseinstellungen

Hinweis

Die E-Mail-basierte Authentifizierung ist aktiviert, sofern sie nicht durch WEBLATE_NO_EMAIL_AUTH deaktiviert wird.

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

Konfiguration der LDAP-Authentifizierung.

Beispiel für direkte Bindung:

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

Beispiel für Suche und Bindung:

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

Beispiel für Vereinigungssuche und Bindung:

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

Beispiel mit Suche und Bindung gegen 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)

Siehe auch

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

Aktiviert GitHub.

GitHub Enterprise Edition

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

Aktiviert GitHub EE.

Bitbucket

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET

Aktiviert Bitbucket.

Facebook

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY
WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET

Aktiviert Facebook OAuth 2.

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

Aktiviert Google OAuth 2.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY
WEBLATE_SOCIAL_AUTH_GITLAB_SECRET
WEBLATE_SOCIAL_AUTH_GITLAB_API_URL

Aktiviert GitLab OAuth 2.

Gitea

WEBLATE_SOCIAL_AUTH_GITEA_API_URL
WEBLATE_SOCIAL_AUTH_GITEA_KEY
WEBLATE_SOCIAL_AUTH_GITEA_SECRET

Aktiviert die Gitea-Authentifizierung.

Microsoft Entra ID

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET

Aktiviert die Microsoft-Entra-ID-Authentifizierung, siehe Microsoft Entra ID.

Microsoft Entra ID mit Mandantenunterstützung

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET
WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID

Aktiviert die Microsoft-Entra-ID-Authentifizierung mit Mandantenunterstützung, siehe 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

Aktiviert die Keycloak-Authentifizierung, siehe Keycloak - Open Source Red Hat SSO.

WEBLATE_SOCIAL_AUTH_KEYCLOAK_ID_KEY

Added in version 5.17.

Legt fest, welcher Claim als eindeutige Benutzerkennung von Keycloak verwendet wird. Der Standardwert ist email.

Hinweis

Wenn Keycloak für die abstrakte IDP eines Drittanbieters konfiguriert ist, müssen Sie WEBLATE_CSP_FORM_SRC für die IDP-Domain des Drittanbieters konfigurieren.

Beispiel, wenn Keycloak die Authentifizierung an Microsoft weitergibt.
environment:
  WEBLATE_CSP_FORM_SRC: login.microsoftonline.com

Linux-Anbieter

Sie können die Authentifizierung über die Authentifizierungsdienste von Linux-Anbietern aktivieren, indem Sie die folgenden Variablen auf einen beliebigen Wert setzen.

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

Aktiviert die Slack-Authentifizierung, siehe 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

Konfiguriert die allgemeine Integration von OpenID Connect.

Siehe auch

OIDC (OpenID Connect)

Fedora OpenID Connect

Added in version 5.15.

WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_KEY
WEBLATE_SOCIAL_AUTH_FEDORA_OIDC_SECRET

Konfiguriert die Integration von Fedora OpenID Connect.

Siehe auch

Fedora

SAML

Selbstsignierte SAML-Schlüssel werden beim ersten Start des Containers automatisch erzeugt. Wenn Sie eigene Schlüssel verwenden möchten, legen Sie das Zertifikat und den privaten Schlüssel in /app/data/ssl/saml.crt und /app/data/ssl/saml.key ab.

WEBLATE_SAML_IDP_ENTITY_ID
WEBLATE_SAML_IDP_URL
WEBLATE_SAML_IDP_X509CERT
WEBLATE_SAML_IDP_IMAGE
WEBLATE_SAML_IDP_TITLE

SAML-Identitätsanbietereinstellungen, siehe SAML-Authentifizierung.

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.

SAML-Attribut-Zuordnung.

Weitere Authentifizierungseinstellungen

WEBLATE_NO_EMAIL_AUTH

Deaktiviert die E-Mail-Authentifizierung, wenn auf einen beliebigen Wert gesetzt. Siehe Passwort-Authentifizierung deaktivieren.

WEBLATE_MIN_PASSWORD_SCORE

Minimaler Passwortwert, wie er vom zxcvbn-Passwortstärke-Schätzer ermittelt wurde. Standardwert ist 3, auf 0 setzen, um die Prüfung zu deaktivieren.

Siehe auch

PostgreSQL-Datenbank einrichten

Die Datenbank wird von docker-compose.yml erstellt, daher betreffen diese Einstellungen sowohl Weblate- als auch PostgreSQL-Container.

Siehe auch

Datenbankeinrichtung für Weblate

POSTGRES_PASSWORD

PostgreSQL-Passwort.

Siehe auch

Geheimnisse weitergeben

POSTGRES_USER

PostgreSQL-Benutzername.

POSTGRES_DB

PostgreSQL-Datenbankname.

POSTGRES_HOST

Hostname oder IP-Adresse des PostgreSQL-Servers. Der Standardwert ist database.

POSTGRES_PORT

PostgreSQL-Serverport. Der Standardwert ist none (verwendet den Standardwert).

POSTGRES_SSL_MODE

Konfiguriert, wie PostgreSQL SSL bei der Verbindung zum Server handhabt, für mögliche Auswahlen siehe SSL Mode Descriptions.

POSTGRES_ALTER_ROLE

Konfiguriert den Namen der PostgreSQL-Rolle, die während der Datenbankmigration geändert werden soll, siehe Weblate für die Verwendung von PostgreSQL konfigurieren.

Der Standardwert ist POSTGRES_USER.

POSTGRES_CONN_MAX_AGE

Added in version 4.8.1.

Die Lebensdauer einer Datenbankverbindung, als ganze Zahl von Sekunden. 0 verwenden, um Datenbankverbindungen am Ende jeder Anfrage zu schließen.

Geändert in Version 5.1: Das Standardverhalten ist eine unbegrenzte Anzahl von dauerhaften Datenbankverbindungen.

Die Aktivierung der Verbindungsaufrechterhaltung führt normalerweise zu mehr offenen Verbindungen zur Datenbank. Bitte passen Sie Ihre Datenbankkonfiguration vor der Aktivierung an.

Beispielkonfiguration:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Siehe auch

POSTGRES_DISABLE_SERVER_SIDE_CURSORS

Added in version 4.9.1.

Deaktiviert serverseitige Cursor in der Datenbank. Dies ist bei einigen pgbouncer-Einrichtungen notwendig.

Beispielkonfiguration:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Siehe auch

WEBLATE_DATABASES

Added in version 5.1.

Set to false to disable environment based configuration of the database connection. Use Einstellungen aus dem Daten-Volume überschreiben to configure the database connection manually.

Datenbanksicherung einstellen

Siehe auch

Ausgegebene Daten für Sicherungen

WEBLATE_DATABASE_BACKUP

Konfiguriert den täglichen Datenbankauszug mit DATABASE_BACKUP. Die Voreinstellung ist plain.

Datenspeicher-Server einrichten

Die Verwenden von Valkey oder Redis ist für den Weblate-Container erforderlich und Sie müssen beim Ausführen von Weblate in Docker Verbindungsparameter angeben.

Siehe auch

Cache konfigurieren

REDIS_HOST

Der Hostname oder die IP-Adresse des Datenspeicher-Servers. Der Standardwert ist cache.

REDIS_PORT

Der Port des Datenspeicher-Servers. Der Standardwert ist 6379.

REDIS_DB

Die Nummer der Datenspeicher-Datenbank, standardmäßig 1.

REDIS_USER

Added in version 5.13: Der Benutzer der Datenspeicher-Datenbank, nicht standardmäßig verwendet.

REDIS_PASSWORD

Das Passwort des Datenspeicher-Servers, nicht standardmäßig verwendet.

Siehe auch

Geheimnisse weitergeben

REDIS_TLS

Aktiviert die Verwendung von SSL für die Datenspeicher-Verbindung.

REDIS_VERIFY_SSL

Kann verwendet werden, um die SSL-Zertifikatsüberprüfung für die Datenspeicher-Verbindung zu deaktivieren.

E-Mail-Server einrichten

Damit ausgehende E-Mails funktionieren, müssen Sie einen Mailserver bereitstellen.

Beispiel für eine TLS-Konfiguration:

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

Beispiel für eine SSL-Konfiguration:

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

Siehe auch

Ausgehende E-Mails konfigurieren

WEBLATE_EMAIL_HOST

Hostname oder IP-Adresse des Mailservers.

Siehe auch

WEBLATE_EMAIL_PORT

Mailserver-Port, standardmäßig 25.

Siehe auch

EMAIL_PORT

WEBLATE_EMAIL_HOST_USER

Benutzer der E-Mail-Authentifizierung.

Siehe auch

EMAIL_HOST_USER

WEBLATE_EMAIL_HOST_PASSWORD

Passwort für die E-Mail-Authentifizierung.

Siehe auch

WEBLATE_EMAIL_USE_SSL

Ob eine implizite (sichere) TLS-Verbindung für die Kommunikation mit dem SMTP-Server verwendet werden soll. In den meisten E-Mail-Dokumentationen wird diese Art der TLS-Verbindung als SSL bezeichnet. Sie wird im Allgemeinen auf Port 465 eingesetzt. Wenn Sie Probleme haben, sehen Sie sich die explizite TLS-Einstellung WEBLATE_EMAIL_USE_TLS an.

Geändert in Version 4.11: Die SSL/TLS-Unterstützung wird automatisch auf der Grundlage des WEBLATE_EMAIL_PORT aktiviert.

Siehe auch

WEBLATE_EMAIL_USE_TLS

Ob eine (sichere) TLS-Verbindung verwendet werden soll, wenn mit dem SMTP-Server kommuniziert wird. Dies wird für explizite TLS-Verbindungen verwendet, im Allgemeinen auf Port 587 oder 25. Wenn Sie feststellen, dass Verbindungen hängen bleiben, sehen Sie sich die implizite TLS-Einstellung WEBLATE_EMAIL_USE_SSL an.

Geändert in Version 4.11: Die SSL/TLS-Unterstützung wird automatisch auf der Grundlage des WEBLATE_EMAIL_PORT aktiviert.

Siehe auch

WEBLATE_EMAIL_BACKEND

Konfiguriert das Django-Backend, das für den Versand von E-Mails verwendet werden soll.

Siehe auch

WEBLATE_AUTO_UPDATE

Konfiguriert, ob und wie Weblate Repositorys aktualisieren soll.

Siehe auch

AUTO_UPDATE

Bemerkung

Dies ist eine boolesche Einstellung ("true" oder "false" verwenden).

Website-Integration

WEBLATE_GET_HELP_URL

Konfiguriert GET_HELP_URL.

WEBLATE_STATUS_URL

Konfiguriert STATUS_URL.

Konfiguriert LEGAL_URL.

WEBLATE_PRIVACY_URL

Konfiguriert PRIVACY_URL.

WEBLATE_PASSWORD_RESET_URL

Konfiguriert PASSWORD_RESET_URL.

Fehlerberichte sammeln und Leistung überwachen

Es wird empfohlen, Fehler bei der Installation systematisch zu sammeln, siehe Fehlerberichte sammeln und Leistung überwachen.

Um die Unterstützung für Rollbar zu aktivieren, stellen Sie Folgendes ein:

ROLLBAR_KEY

Ihr Rollbar-Postserver-Zugangstoken.

ROLLBAR_ENVIRONMENT

Ihre Rollbar-Umgebung, standardmäßig production.

Um die Unterstützung für Sentry zu aktivieren, stellen Sie Folgendes ein:

SENTRY_DSN

Ihr Sentry-DSN, siehe SENTRY_DSN.

SENTRY_ENVIRONMENT

Ihre Sentry-Umgebung (optional), standardmäßig WEBLATE_SITE_DOMAIN.

SENTRY_MONITOR_BEAT_TASKS

Ob Celery-Beat-Aufgaben mit Sentry überwacht werden sollen, standardmäßig True.

SENTRY_TRACES_SAMPLE_RATE

Konfiguriert SENTRY_TRACES_SAMPLE_RATE.

Beispiel:

environment:
  SENTRY_TRACES_SAMPLE_RATE: 0.5
SENTRY_PROFILES_SAMPLE_RATE

Konfiguriert SENTRY_PROFILES_SAMPLE_RATE.

Beispiel:

environment:
  SENTRY_PROFILES_SAMPLE_RATE: 0.5
SENTRY_SEND_PII

Konfiguriert SENTRY_SEND_PII.

Lokalisierungs-CDN

WEBLATE_LOCALIZE_CDN_URL
WEBLATE_LOCALIZE_CDN_PATH

Added in version 4.2.1.

Configuration for CDN add-ons, including JavaScript-Lokalisierungs-CDN and Translation files CDN.

Der WEBLATE_LOCALIZE_CDN_PATH ist ein Pfad innerhalb des Containers. Er sollte auf dem dauerhaften Volume und nicht im flüchtigen Speicher gespeichert werden.

Eine der Möglichkeiten ist die Speicherung im Weblate-Datenverzeichnis:

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

Bemerkung

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

Siehe auch

Aktivierte Apps, Qualitätsprüfungen, Erweiterungen, maschinelle Übersetzungen oder Autofixes ändern

Die integrierte Konfiguration der aktivierten Qualitätsprüfungen, Erweiterungen oder Autofixes kann durch die folgenden Variablen angepasst werden:

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.

Beispiel:

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

Siehe auch

Container-Einstellungen

WEBLATE_WORKERS

Added in version 4.6.1.

Basisanzahl der im Container laufenden Worker-Prozesse. Wenn sie nicht festgelegt ist, wird sie automatisch beim Start des Containers anhand der Anzahl der verfügbaren CPU-Kerne ermittelt.

Wird zur Bestimmung von CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS und WEB_WORKERS verwendet. Sie können diese Einstellungen zur Feinabstimmung nutzen.

CELERY_MAIN_OPTIONS
CELERY_NOTIFY_OPTIONS
CELERY_MEMORY_OPTIONS
CELERY_TRANSLATE_OPTIONS
CELERY_BACKUP_OPTIONS
CELERY_BEAT_OPTIONS

Mit diesen Variablen können die Celery-Worker-Optionen angepasst werden. Es kann nützlich sein, die Parallelität anzupassen (--concurrency 16) oder eine andere Pool-Implementierung zu verwenden (--pool=gevent).

Standardmäßig basiert die Anzahl der gleichzeitigen Worker auf WEBLATE_WORKERS.

Beispiel:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Siehe auch

CELERY_SINGLE_PROCESS

Added in version 5.7.1: Diese Variable kann auf 1 gesetzt werden, um nur einen Celery-Prozess auszuführen. Dies reduziert die Speicherauslastung, kann aber die Leistung von Weblate beeinträchtigen.

environment:
  CELERY_SINGLE_PROCESS: 1

Siehe auch

Celery-Einzelprozess einrichten

WEB_WORKERS

Konfiguriert, wie viele WSGI-Worker ausgeführt werden sollen.

Der Standardwert ist die Hälfte von WEBLATE_WORKERS, beträgt aber immer mindestens 2.

Beispiel:

environment:
  WEB_WORKERS: 4

Geändert in Version 5.13: WEB_WORKERS konfiguriert, wie viele Worker-Prozesse von granian verwendet werden sollen.

WEBLATE_SERVICE

Legt fest, welche Dienste innerhalb des Containers ausgeführt werden sollen. Verwenden Sie dies für Horizontale Skalierung.

Folgende Dienste sind definiert:

celery-beat

Celery-Aufgabenplaner, es sollte nur eine Instanz ausgeführt werden. Dieser Container ist auch für die Migrationen der Datenbankstruktur zuständig und sollte vor den anderen gestartet werden.

celery-backup

Celery-Worker für Sicherungen, es sollte nur eine Instanz laufen.

celery-celery

Allgemeiner Celery-Worker.

celery-memory

Übersetzungsspeicher Celery-Worker.

celery-notify

Benachrichtigungen Celery-Worker.

celery-translate

Automatische Übersetzung Celery-Worker.

web

Webserver.

Siehe auch

Interne Hintergrundaufgaben

WEBLATE_ANUBIS_URL

Added in version 5.11.4.

URL des Anubis-Servers für die Authentifizierung von Subrequests. Dies kann nützlich sein, um eingehende HTTP-Anfragen mithilfe von Proof-of-Work zu filtern und so KI-Crawler zu stoppen. Sie müssen Anubis für Subrequest-Authentifizierung konfigurieren, damit es funktioniert.

Siehe auch

Docker-Container-Volumes

Es gibt zwei Volumes (data und cache), die vom Weblate-Container exportiert werden.

Bemerkung

Die anderen Dienst-Container (wie PostgreSQL oder Valkey) verfügen ebenfalls über Daten-Volumes und sind für die Aufrechterhaltung der Weblate-Persistenz erforderlich.

Der PostgreSQL-Container speichert die Datenbank auf dem Volume /var/lib/postgresql und Valkey auf dem Volume /data. Der Valkey-Container speichert die Daten standardmäßig nicht und muss zusätzlich konfiguriert werden, um die Persistenz zu aktivieren.

Orientieren Sie sich bei der Konfiguration an den von Weblate bereitgestellten Beispielen oder lesen Sie die Dokumentation für weitere Informationen.

Das Volume data wird als /app/data eingebunden und dient zum Speichern von dauerhaften Weblate-Daten wie geklonte Repositorys oder zum Anpassen der Weblate-Installation. DATA_DIR beschreibt genauer, was hier gespeichert wird.

Auf dem Volume data können auch Weblate-Anpassungen wie Einstellungen aus dem Daten-Volume überschreiben, Logo und andere statische Dateien ersetzen oder Code anpassen gespeichert werden.

Das Platzieren des Docker-Volumes auf dem Host-System hängt von der Docker-Konfiguration ab, aber normalerweise wird es in /var/lib/docker/volumes/weblate-docker_weblate-data/_data/ gespeichert (der Pfad besteht aus dem Namen des Docker-Compose-Verzeichnisses, dem -Container und den -Volume-Namen).

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

Wenn Sie die Volumes manuell erstellen, sollten die Verzeichnisse der UID 1000 gehören, da dies der im Container verwendete Benutzer ist.

Der Weblate-Container kann auch mit einem schreibgeschützten Root-Dateisystem ausgeführt werden. In diesem Fall sollten zwei zusätzliche tmpfs-Volumes eingebunden werden: /tmp und /run.

Siehe auch

Schreibgeschütztes Root-Dateisystem

Added in version 4.18.

Wenn der Container mit einem schreibgeschützten Root-Dateisystem läuft, werden zwei zusätzliche tmpfs-Volumes benötigt - /tmp und /run.

Konfiguration über Umgebungsvariablen hinaus

Docker-Umgebungsvariablen sollen die relevantesten Konfigurationseinstellungen für Ihre Weblate-Installationen aufzeigen.

Wenn Sie eine Einstellung finden, die nicht als Umgebungsvariable verfügbar ist und Sie glauben, dass sie es sein sollte, können Sie fordern, dass sie in einer zukünftigen Version von Weblate verfügbar gemacht wird.

Wenn Sie eine Einstellung ändern müssen, die nicht als Docker-Umgebungsvariable verfügbar ist, können Sie dies trotzdem tun, entweder über das Daten-Volume oder durch Erweitern des Docker-Images.

Siehe auch

Weblate anpassen

Einstellungen aus dem Daten-Volume überschreiben

Sie können eine Datei unter /app/data/settings-override.py erstellen, d. h. im Stammverzeichnis des Daten-Volumes, um die durch Umgebungsvariablen definierten Einstellungen zu erweitern oder zu überschreiben.

Einstellungen überschreiben durch Erweitern des Docker-Images

Um Einstellungen auf der Ebene des Docker-Images statt des Daten-Volumes zu überschreiben:

  1. Ein benutzerdefiniertes Python-Paket erstellen.

  2. Hinzufügen eines Moduls zum eigenen Paket, das alle Einstellungen von weblate.settings_docker importiert.

    Innerhalb der Beispiel-Paketstruktur, die unter Ein Python-Modul erstellen definiert ist, kann zum Beispiel eine Datei unter weblate_customization/weblate_customization/settings.py mit dem folgenden Anfangscode erstellt werden:

    from weblate.settings_docker import *

  3. Erstellen eines benutzerdefinierten Dockerfile, das vom offiziellen Weblate-Docker-Image erbt, und dann das Paket installiert und die Umgebungsvariable DJANGO_SETTINGS_MODULE auf das Einstellungsmodul verweist:

    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. Anstatt das offizielle Weblate-Docker-Image zu verwenden, sollte ein eigenes Image aus dieser Dockerfile-Datei erstellt werden.

    Es gibt keine saubere Möglichkeit, dies mit docker-compose.override.yml zu tun. Sie könnten build: . zum weblate-Knoten in dieser Datei hinzufügen, aber dann wird Ihr benutzerdefiniertes Image als weblate/weblate in Ihrem System getaggt, was problematisch sein könnte.

    Anstatt also docker-compose.yml direkt unverändert aus dem offiziellen Repository zu verwenden und es durch docker-compose.override.yml zu erweitern, sollten Sie eine Kopie der offiziellen docker-compose.yml Datei erstellen und diese Kopie so bearbeiten, dass image: weblate/weblate durch build: . ersetzt wird.

    Weitere Informationen zum Erstellen von Images aus der Quelle bei Verwendung von docker-compose finden Sie in der Compose-Datei-Build-Referenz.

  5. Erweitern des benutzerdefinierten Einstellungsmoduls, um Einstellungen zu definieren oder neu zu definieren.

    Es können Einstellungen vor oder nach der obigen Importanweisung definiert werden, um festzulegen, welche Einstellungen Vorrang haben. Einstellungen, die vor der Importanweisung definiert wurden, können durch Umgebungsvariablen und die im Data-Volume definierte Einstellungsüberschreibungen überschrieben werden. Einstellungen, die nach der Importanweisung definiert werden, können nicht überschrieben werden.

    Sie können auch noch weiter gehen. Zum Beispiel können Sie einige der Dinge reproduzieren, die weblate.docker_settings tut , wie z. B. Einstellungen als Umgebungsvariablen offenlegen oder das Überschreiben von Einstellungen aus Python-Dateien im Daten-Volume erlauben.

Logo und andere statische Dateien ersetzen

Die mit Weblate gelieferten statischen Dateien können überschrieben werden, indem sie in /app/data/python/customize/static abgelegt werden (siehe Docker-Container-Volumes). Zum Beispiel wird durch die Erstellung von /app/data/python/customize/static/favicon.ico das Favicon ersetzt.

Hinweis

Die Dateien werden beim Start des Containers an den entsprechenden Ort kopiert, so dass ein Neustart von Weblate erforderlich ist, wenn der Inhalt des Volumes geändert wurde.

Dieser Ansatz kann auch verwendet werden, um Weblate-Vorlagen außer Kraft zu setzen. Zum Beispiel können Rechtsmodul-Dokumente in /app/data/python/customize/templates/legal/documents platziert werden.

Alternativ können Sie auch ein eigenes Modul einbinden (siehe Weblate anpassen) und es zum Beispiel als separates Volume dem Docker-Container hinzufügen:

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

Code anpassen

Bemerkung

Die interne Weblate-API kann von Version zu Version stark variieren und ist nicht als stabil zu betrachten. Bitte überprüfen Sie bei jedem Upgrade Ihren benutzerdefinierten Code, der mit Weblate-Interna interagiert.

Sie können zusätzlichen Python-Code in /app/data/python/customize einfügen (siehe Docker-Container-Volumes). Es ist bereits als Django-Anwendung in Weblate installiert (dies wird zum Anpassen von Vorlagen und statischen Dateien wie oben beschrieben verwendet).

Dies kann verwendet werden, um beliebigen Code zu platzieren (z. B. Eigene Qualitätsprüfungen schreiben) oder um benutzerdefinierte Wartungsaufgaben in den Celery-Aufgabenplaner aufzunehmen.

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

Drittanbieter-Container integrieren

Die Weblate-Docker-Installation kann mit zusätzlichen Containern erweitert werden, um ergänzende Dienste wie maschinelle Übersetzungen, Rechtschreibprüfungen oder andere Tools zum Verbesseren des Übersetzungsablaufs bereitzustellen. Diese Dienste können in Ihre Docker-Compose-Konfiguration integriert werden und mit Weblate zusammenarbeiten.

Wenn Sie Drittanbieter-Container hinzufügen, sollten Sie Folgendes beachten:

  • Netzwerkverbindung: Sicherstellen, dass Container miteinander kommunizieren können, indem sie in dasselbe Docker-Netzwerk eingebunden werden

  • Datenpersistenz: Verwenden von Volumes für Dienste, die Daten aufbewahren müssen

  • Sicherheit: Konfigurieren Sie geeignete Zugriffssteuerungen und vermeiden Sie die Freigabe unnötiger Ports

LibreTranslate-Docker-Container-Integration

LibreTranslate ist ein freier und quelloffener maschineller Übersetzungsdienst, der selbst gehostet werden kann. Die Integration in Weblate ermöglicht maschinelle Übersetzungen, ohne auf externe Dienste angewiesen zu sein.

Sie können den LibreTranslate-Dienst in Ihre Weblate-Bereitstellung einbinden, indem Sie ihn in eine docker-compose.override.yml-Datei aufnehmen. Da er innerhalb des Docker-Netzwerks läuft, ist er nur für Weblate zugänglich und nicht dem öffentlichen Internet ausgesetzt.

Basis-Einrichtung mit 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:

Für GPU-beschleunigte Übersetzungen (wenn eine NVIDIA-GPU vorhanden ist):

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:

Nachdem Sie die Dienste mit docker compose down && docker compose up -d gestartet haben, konfigurieren Sie LibreTranslate in Weblate:

  1. Auf die Adminoberfläche von Weblate zugreifen

  2. Zu Maschinelle Übersetzung → Automatische Vorschläge navigieren

  3. Einen neuen LibreTranslate-Dienst hinzufügen:

    Dienst:

    LibreTranslate

    API-URL:

    http://libretranslate:5000

    API-Schlüssel:

    Leer lassen

LibreTranslate ist jetzt für maschinelle Übersetzungen in Weblate konfiguriert und verfügbar.

Bemerkung

  • Der LibreTranslate-Dienst läuft ohne Web-UI (--disable-web-ui) und ist nur über die API innerhalb des Docker-Netzwerks zugänglich.

  • Modelle werden beim Start des Containers automatisch aktualisiert. (LT_UPDATE_MODELS: true)

  • Daten werden mit Docker-Volumes für optimale Leistung und Datensicherheit dauerhaft gespeichert.

  • Integritätsprüfungen stellen sicher, dass die Docker-Engine den Zustand des Dienstes ordnungsgemäß überwacht.

  • Für GPU-Beschleunigung verwenden Sie die CUDA-Image-Variante und stellen Sie sicher, dass Ihr System NVIDIA-Docker-Unterstützung bietet. Dieser Container wird als privilegierter Benutzer ausgeführt, um die GPU nutzen zu können.

  • Es sind keine externen Ports zugänglich, so dass die Einrichtung standardmäßig sicher ist.

Siehe auch

Anubis-Docker-Container-Integration

Anubis ist ein Web-KI-Firewall-Dienstprogramm, das KI-Scraper und anderen störenden Verkehr auf dem Server blockiert. Es wird in der Regel für öffentlich zugängliche Weblate-Installationen benötigt, um eine übermäßige Belastung durch Scraping zu vermeiden.

Anubis kann mit Docker Compose bereitgestellt werden:

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:

Bemerkung

Das Volume anubis-data in der obigen Konfiguration sollte die Datei botPolicies.yaml mit einer entsprechend Ihren Anforderungen konfigurierten Bot-Richtlinie enthalten.

Zumindest müssen Sie die Statuscodes wie in https://anubis.techaro.lol/docs/admin/configuration/subrequest-auth beschrieben anpassen.

Es wird auch empfohlen, das persistente Speicher-Backend wie unter https://anubis.techaro.lol/docs/admin/policies/#storage-backends beschrieben zu konfigurieren.

Anschließend kann die Anubis-Nutzung in Weblate wie folgt aktiviert werden:

environment:
   WEBLATE_ANUBIS_URL: http://anubis:8923

Siehe auch

WEBLATE_ANUBIS_URL

PostgreSQL-Server konfigurieren

Der PostgreSQL-Container verwendet die Standardkonfiguration von PostgreSQL, welche die CPU-Kerne und den Speicher nicht effektiv nutzt. Es wird empfohlen, die Konfiguration anzupassen, um die Leistung zu verbessern.

Die Konfiguration kann wie in Datenbankkonfiguration unter https://hub.docker.com/_/postgres beschrieben angepasst werden. Die für Ihre Einsatzumgebung passende Konfiguration kann mit https://pgtune.leopard.in.ua/ erzeugt werden.

Container-Interna

Der Container verwendet supervisor, um einzelne Dienste zu starten. Im Falle von Horizontale Skalierung wird nur ein einzelner Dienst in einem Container gestartet.

Um den Servicestatus zu überprüfen, verwenden Sie:

docker compose exec --user weblate weblate supervisorctl status

Für jede Celery-Warteschlange gibt es eigene Dienste (siehe Hintergrundaufgaben mit Celery für Details). Die Verarbeitung einiger Aufgaben kann durch das Anhalten der entsprechenden Worker gestoppt werden:

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