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

Speicherverbrauch

Je mehr Speicher, 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 Speicher als empfohlen, 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.

    version: '3'
    services:
      weblate:
        ports:
          - 80:8080
        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
    

    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.

Auswahl der Docker-Image-Registry

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.

Auswahl des Docker-Image-Tags

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

<MAJOR>

Stabile Weblate-Version

Fortlaufende Updates innerhalb einer Hauptversion in einer Produktionsumgebung

<MAJOR>.<MINOR>

Stabile Weblate-Version

Fortlaufende Updates innerhalb einer Unterversion in einer Produktionsumgebung

<VERSION>.<PATCH>

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

Verwendung eigener SSL-Zertifikate

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

Aktualisieren des Docker-Containers

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.

Geändert in Version 4.17-1: Seit Weblate 4.17-1 verwendet der Docker-Container Django 4.2, was PostgreSQL 12 oder neuer erfordert. Bitte aktualisieren Sie es vor dem Upgrade von Weblate. Siehe Aktualisieren des PostgreSQL-Containers.

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

Upgrades über Hauptversionen hinweg werden von Weblate nicht unterstützt. Wenn Sie zum Beispiel mit der 3.x-Serie arbeiten und auf 4.x aktualisieren möchten, aktualisieren Sie zunächst auf das neueste 4.0.x-y-Image (zum Zeitpunkt der Erstellung dieses Artikels ist es das 4.0.4-5), das die Migration durchführt, und fahren Sie dann mit dem Upgrade auf neuere Versionen fort.

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

Aktualisieren des PostgreSQL-Containers

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.

  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.

Anzahl der Prozesse und Speicherverbrauch

Die Anzahl der Worker-Prozesse wird sowohl für uWSGI als auch Celery automatisch auf Grundlage der Anzahl der CPUs bestimmt. Dies funktioniert für die meisten virtuellen Maschinen in der Cloud gut, da sie typischerweise wenig CPUs und große Speicherkapazitäten besitzen.

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

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

Allgemeine Einstellungen

WEBLATE_DEBUG

Konfiguriert den Debugmodus von Django mit DEBUG.

Beispiel:

environment:
  WEBLATE_DEBUG: 1
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_SITE_TITLE

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

WEBLATE_SITE_DOMAIN

Konfiguriert die Seitendomain. Dieser Parameter ist erforderlich.

WEBLATE_ADMIN_NAME
WEBLATE_ADMIN_EMAIL

Legt den Namen und die E-Mail 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
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.

WEBLATE_SERVER_EMAIL

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

WEBLATE_DEFAULT_FROM_EMAIL

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

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
WEBLATE_REGISTRATION_OPEN

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

Beispiel:

environment:
  WEBLATE_REGISTRATION_OPEN: 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_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
WEBLATE_INTERLEDGER_PAYMENT_POINTERS

Added in version 4.12.1.

Lässt Weblate das Feld meta[name=monetization] im Kopf des Dokuments setzen. Wenn mehrere angegeben sind, wird eines zufällig ausgewählt.

WEBLATE_IP_PROXY_HEADER

Ermöglicht es Weblate, die IP-Adresse aus einem beliebigen HTTP-Header zu holen. 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.

Bemerkung

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

WEBLATE_SECURE_PROXY_SSL_HEADER

Ein Tupel, das eine HTTP-Header/Wert-Kombination darstellt, die bedeutet, dass eine Anfrage sicher ist. Dies wird benötigt, wenn Weblate hinter einem Reverse-Proxy läuft, der die SSL-Terminierung durchführt und keine Standard-HTTPS-Header weitergibt.

Beispiel:

environment:
  WEBLATE_SECURE_PROXY_SSL_HEADER: HTTP_X_FORWARDED_PROTO,https
WEBLATE_REQUIRE_LOGIN

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

Beispiel:

environment:
  WEBLATE_REQUIRE_LOGIN: 1
WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS
WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS
WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS

Fügt URL-Ausnahmen für die Authentifizierung hinzu, die für die gesamte Weblate-Installation durch LOGIN_REQUIRED_URLS_EXCEPTIONS erforderlich sind.

Sie können entweder ganze Einstellungen ersetzen oder den Standardwert mittels der Variablen ADD und REMOVE ändern.

Um die Authentifizierung für das Kontaktformular zu erzwingen, tun Sie dies:

environment:
  WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS: /contact/$
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

WEBLATE_SIMPLIFY_LANGUAGES

Konfiguriert die Richtlinie zur Sprachvereinfachung, siehe SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL

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

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_AKISMET_API_KEY

Konfiguriert den Akismet-API-Schlüssel, siehe AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY

Konfiguriert die GPG-Signierung von Commits, siehe WEBLATE_GPG_IDENTITY.

WEBLATE_URL_PREFIX

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

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

Ermöglicht die Anpassung des HTTP-Headers Content-Security-Policy.

WEBLATE_LICENSE_FILTER

Konfiguriert LICENSE_FILTER.

WEBLATE_LICENSE_REQUIRED

Konfiguriert LICENSE_REQUIRED

WEBLATE_WEBSITE_REQUIRED

Konfiguriert WEBSITE_REQUIRED

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.

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_UNUSED_ALERT_DAYS

Added in version 4.17.

Konfiguriert UNUSED_ALERT_DAYS.

WEBLATE_CORS_ALLOWED_ORIGINS

Added in version 4.16.

Allow CORS requests to API from given origins.

Beispiel:

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

Added in version 5.6.1: Allows CORS requests to API from all origins.

CLIENT_MAX_BODY_SIZE

Added in version 4.16.3.

Konfiguriert die maximale Body Size, die der integrierte Webserver akzeptiert.

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.

Anmeldedaten für Code-Hosting-Sites

Im Docker-Container können die Zugangsdaten für das Code-Hosting entweder in separaten Variablen konfiguriert werden oder mit einem Python-Wörterbuch auf einmal festgelegt werden. Die folgenden Beispiele sind für GitHub-Pull-Requests, gelten aber auch für die Integration der Versionsverwaltung mit entsprechend geänderten Variablennamen.

Eine Beispielkonfiguration für GitHub 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

Konfiguriert GitHub-Pull-Requests durch Ändern von GITHUB_CREDENTIALS.

WEBLATE_GITLAB_USERNAME
WEBLATE_GITLAB_TOKEN
WEBLATE_GITLAB_HOST
WEBLATE_GITLAB_CREDENTIALS

Konfiguriert GitLab-Merge-Requests durch Ändern von GITLAB_CREDENTIALS.

WEBLATE_GITEA_USERNAME
WEBLATE_GITEA_TOKEN
WEBLATE_GITEA_HOST
WEBLATE_GITEA_CREDENTIALS

Konfiguriert Gitea-Pull-Requests durch Ändern von GITEA_CREDENTIALS.

WEBLATE_PAGURE_USERNAME
WEBLATE_PAGURE_TOKEN
WEBLATE_PAGURE_HOST
WEBLATE_PAGURE_CREDENTIALS

Konfiguriert Pagure-Merge-Requests durch Ändern von PAGURE_CREDENTIALS.

WEBLATE_BITBUCKETSERVER_USERNAME
WEBLATE_BITBUCKETSERVER_TOKEN
WEBLATE_BITBUCKETSERVER_HOST
WEBLATE_BITBUCKETSERVER_CREDENTIALS

Konfiguriert Bitbucket-Server-Pull-Request durch Ändern von BITBUCKETSERVER_CREDENTIALS.

WEBLATE_AZURE_DEVOPS_USERNAME
WEBLATE_AZURE_DEVOPS_ORGANIZATION
WEBLATE_AZURE_DEVOPS_TOKEN
WEBLATE_AZURE_DEVOPS_HOST
WEBLATE_AZURE_DEVOPS_CREDENTIALS

Konfiguriert Azure-DevOps-Pull-Request durch Ändern von AZURE_DEVOPS_CREDENTIALS.

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

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)

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

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

Bitbucket

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET
WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY
WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET

Aktiviert Bitbucket-Authentifizierung.

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.

Azure Active Directory

WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_KEY
WEBLATE_SOCIAL_AUTH_AZUREAD_OAUTH2_SECRET

Aktiviert die Azure Active Directory-Authentifizierung, siehe Microsoft Azure Active Directory.

Azure Active Directory 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 Azure Active Directory-Authentifizierung mit Mandantenunterstützung, siehe Microsoft Azure Active Directory.

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

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

Konfiguriert die allgemeine OpenID Connect-Integration.

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

Einrichtung der PostgreSQL-Datenbank

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

POSTGRES_PASSWORD

PostgreSQL-Passwort.

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 Rolle, der bei Migrationen geändert werden soll, siehe Weblate für die Verwendung von PostgreSQL konfigurieren.

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

Added in version 5.1.

Diesen Wert auf false setzen, um die umgebungsbasierte Konfiguration der Datenbankverbindung zu deaktivieren. Überschreiben von Einstellungen des Daten-Volumes verwenden, um die Datenbankverbindung manuell zu konfigurieren.

MySQL- oder MariaDB-Server

Weder MySQL noch MariaDB können über Umgebungsvariablen konfiguriert werden. Siehe MySQL und MariaDB für Informationen zur Verwendung dieser Variablen mit Weblate. WEBLATE_DATABASES verwenden, um die Datenbankverbindung manuell zu konfigurieren.

Datenbanksicherung einstellen

WEBLATE_DATABASE_BACKUP

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

Caching-Server einrichten

Die Verwendung von Redis wird von Weblate dringend empfohlen und Sie müssen eine Redis-Instanz bereitstellen, wenn Sie Weblate in Docker ausführen.

Siehe auch

Caching einschalten

REDIS_HOST

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

REDIS_PORT

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

REDIS_DB

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

REDIS_PASSWORD

Das Redis Server-Passwort, nicht standardmäßig verwendet.

REDIS_TLS

Ermöglicht die Verwendung von SSL für Redis-Verbindungen.

REDIS_VERIFY_SSL

Kann verwendet werden, um die SSL-Zertifikatsüberprüfung für Redis-Verbindungen 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
WEBLATE_EMAIL_HOST

Hostname oder IP-Adresse des Mailservers.

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.

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.

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.

WEBLATE_EMAIL_BACKEND

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

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

Integration der Website

WEBLATE_GET_HELP_URL

Konfiguriert GET_HELP_URL.

WEBLATE_STATUS_URL

Konfiguriert STATUS_URL.

Konfiguriert LEGAL_URL.

WEBLATE_PRIVACY_URL

Konfiguriert PRIVACY_URL.

Sammeln von Fehlerberichten und Überwachen der Leistung

Es wird empfohlen, Fehler bei der Installation systematisch zu sammeln, siehe Sammeln von Fehlerberichten und Überwachen der Leistung.

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

Konfiguration für JavaScript-Lokalisierungs-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

Sie sind für die Einrichtung der Bereitstellung der von Weblate erzeugten Dateien verantwortlich, es speichert nur die Dateien am konfigurierten Speicherort.

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

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

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
WEB_WORKERS

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

Der Standardwert ist WEBLATE_WORKERS.

Beispiel:

environment:
  WEB_WORKERS: 32
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.

Docker-Container-Volumes

Es gibt zwei Volumes (Daten und Cache), die vom Weblate-Container exportiert werden. Die anderen Service-Container (PostgreSQL oder Redis) verfügen ebenfalls über Datenvolumina, die jedoch in diesem Dokument nicht behandelt werden.

Das Daten-Volume wird verwendet, um dauerhafte Weblate-Daten wie geklonte Repositorys zu speichern oder die Weblate-Installation anzupassen.

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

Das Cache-Volume wird als /app/cache gemountet und dient zum Speichern von statischen Dateien und CACHE_DIR. Sein Inhalt wird beim Start des Containers neu erstellt und das Volume kann mit einem ephemeren Dateisystem wie tmpfs eingebunden werden.

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

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 sind dazu gedacht, die meisten Konfigurationseinstellungen, die für Weblate-Installationen von Bedeutung sind, sichtbar zu machen.

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

Überschreiben von Einstellungen des Daten-Volumes

Sie können eine Datei unter /app/data/settings-override.py erstellen, d. h. in der Wurzel des Daten-Volume, um Einstellungen zu erweitern oder zu überschreiben, die durch Umgebungsvariablen definiert wurden.

Überschreiben von Einstellungen 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. Ein Modul zum eigenen Paket hinzufügen, das alle Einstellungen von weblate.settings_docker importiert.

    Innerhalb der Beispiel-Paketstruktur, die unter Erstellen eines Python-Moduls 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. Ein benutzerdefiniertes Dockerfile erstellen, 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 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 markiert, 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. Das eigene Einstellungsmodul erweitern, 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.

Ersetzen des Logos und anderer statischer Dateien

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 Rechtliche Grundlagen-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

Konfigurieren des PostgreSQL-Servers

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