Installation über Docker

Mit der Bereitstellung von Weblate per 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 eingerichtet.

Hardwareanforderungen

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

2 GB Arbeitsspeicher
2 CPU-Kerne
1 GB Speicherplatz

Je mehr Speicher, desto besser - er wird für das Caching auf allen Ebenen (Dateisystem, Datenbank und Weblate) verwendet.

Viele gleichzeitige Benutzer erhöhen die Anzahl der benötigten CPU-Kerne. Für Hunderte von Übersetzungskomponenten werden mindestens 4 GB RAM empfohlen.

Dies hat schwerwiegende Auswirkungen auf die Leistung der Weboberfläche und beeinträchtigt Funktionen, die von regelmäßigen Auslösern abhängen (z. B. das Übertragen ausstehender Änderungen, Digest-Benachrichtigungen oder Sicherungen).

Bemerkung

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

Installation

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

Klonen Sie das Weblate-Docker-Repository:

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

Erstellen Sie eine Datei docker-compose.override.yml mit Ihren Einstellungen. 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 angelegt, 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.

Weblate-Container starten:
```
docker-compose up
```

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

Geändert in Version 2.15-2: Die Einrichtung hat sich kürzlich geändert, vorher gab es einen separaten Webserver-Container, seit 2.15-2 ist der Webserver in den Weblate-Container eingebettet.

Geändert in Version 3.7.1-6: Im Juli 2019 (beginnend mit dem Tag 3.7.1-6) werden die Container nicht als Root-Benutzer ausgeführt. Dadurch hat sich der exponierte Port von 80 auf 8080 geändert.

Siehe auch

Invoking management commands

Auswählen des Docker-Hub-Tags

Sie können die folgenden Tags auf Docker Hub verwenden. Eine vollständige Liste der verfügbaren Tags finden Sie unter https://hub.docker.com/r/weblate/weblate/tags/.

Tag-Name	Beschreibung	Anwendungsfall
`latest`	Stabile Version von Weblate, entspricht der neuesten getaggten Version	Fortlaufende Updates in einer Produktionsumgebung
`<VERSION>-<PATCH>`	Weblate stabile Version	Gut definierter Einsatz in einer Produktionsumgebung
`edge`	Stabiles Weblate-Release mit Entwicklungsänderungen im Docker-Container (z. B. aktualisierte Abhängigkeiten)	Fortlaufende Updates in einer Staging-Umgebung
`edge-<DATE>-<SHA>`	Stabiles Weblate-Release 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 Bild wird vor der Veröffentlichung von unserer CI getestet, so dass selbst die bleeding-Version sicher zu verwenden ist.

Docker-Container mit HTTPS-Unterstützung

Bitte lesen Sie :ref:‘docker-deploy‘ für allgemeine Bereitstellungsanweisungen, dieser Abschnitt erwähnt nur Unterschiede im Vergleich dazu.

Verwendung eigener SSL-Zertifikate

Neu in Version 3.8-3.

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

ssl/fullchain.pem, das das Zertifikat enthält, einschließlich aller erforderlichen CA-Zertifikate
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 Port-Weiterleitung für HTTPS in den Docker Compose Override 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;
    listen [::]:443;

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

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:

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.10-1: Seit Weblate 4.10-1 verwendet der Docker-Container Django 4.0, was PostgreSQL 10 oder neuer erfordert. Bitte aktualisieren Sie es vor dem Upgrade von Weblate. Siehe Upgrade von 4.0 auf 4.10 und 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 z. B. 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.

Siehe auch

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

Weblate-Container stoppen:
```
docker-compose stop weblate cache
```

Datenbank sichern:

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

Datenbank-Container sperren:
```
docker-compose stop database
```

Entfernen des PostgreSQL-Volumes:

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

Passen Sie docker-compose.yml an, um die neue PostgreSQL-Version zu verwenden.
Datenbank-Container öffnen:
```
docker-compose up -d database
```

Datenbank aus Sicherung wiederherstellen:

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

Alle verbleibenden Container öffnen:
```
docker-compose up -d
```

Administrator-Anmeldung

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

WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

Anzahl der Prozesse und Speicherverbrauch

Die Anzahl der Mitarbeitervorgänge 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 Arbeitskräfte zu reduzieren:

environment:
  WEBLATE_WORKERS: 2

Sie können auch individuelle Arbeitskräftekategorien feinabstimmen:

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

Siehe auch

WEBLATE_WORKERS CELERY_MAIN_OPTIONS, CELERY_NOTIFY_OPTIONS, CELERY_MEMORY_OPTIONS, CELERY_TRANSLATE_OPTIONS, CELERY_BACKUP_OPTIONS, CELERY_BEAT_OPTIONS, UWSGI_WORKERS

Horizontale Skalierung

Neu 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 hat eine definierte Rolle mit der Umgebungsvariablen WEBLATE_SERVICE. Bitte folgen Sie sorgfältig der Dokumentation, da einige der Dienste nur einmal im Cluster laufen sollen und auch die Reihenfolge der Dienste wichtig ist.

Ein Beispiel-Setup finden Sie im docker-compose-Repo als docker-compose-split.yml.

Docker-Umgebungsvariablen

Viele von Weblates Konfiguration können 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.

Allgemeine Einstellungen

WEBLATE_DEBUG

Konfiguriert den Debugmodus von Django mit DEBUG.

Beispiel:

environment:
  WEBLATE_DEBUG: 1

Siehe auch

Debugmodus deaktivieren

WEBLATE_LOGLEVEL: Konfiguriert die Ausführlichkeit der Protokollierung.

WEBLATE_LOGLEVEL_DATABASE: Konfiguriert die Protokollierung der Ausführlichkeit der Datenbankabfragen.

WEBLATE_SITE_TITLE: Ändert den Plattform-Titel, der in der Kopfzeile aller Seiten angezeigt wird.

WEBLATE_SITE_DOMAIN: Konfiguriert die Seitendomain. Dieser Parameter ist erforderlich.

Siehe auch

Stellen Sie die richtige Websitedomäne ein, SITE_DOMAIN

WEBLATE_ADMIN_NAME

WEBLATE_ADMIN_EMAIL

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

Administrator-Anmeldung, Administratoren richtig konfigurieren, ADMINS

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

Administrator-Anmeldung, WEBLATE_ADMIN_PASSWORD, WEBLATE_ADMIN_PASSWORD_FILE, WEBLATE_ADMIN_NAME, WEBLATE_ADMIN_EMAIL

WEBLATE_ADMIN_PASSWORD_FILE: Legt den Pfad zu einer Datei fest, die das Passwort für den Benutzer Administrator enthält.

Siehe auch

WEBLATE_ADMIN_PASSWORD

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

Siehe auch

SERVER_EMAIL, Konfigurieren Sie den E-Mail-Versand

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

Siehe auch

DEFAULT_FROM_EMAIL, Konfigurieren Sie den E-Mail-Versand

WEBLATE_CONTACT_FORM: Konfiguriert das Verhalten des Kontaktformulars, siehe CONTACT_FORM.

WEBLATE_ALLOWED_HOSTS

Konfiguriert erlaubte HTTP-Hostnamen mit ALLOWED_HOSTS.

Defaults to * which allows all hostnames.

Beispiel:

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

Siehe auch

ALLOWED_HOSTS, Einrichtung zulässiger Hosts, Stellen Sie die richtige Websitedomäne ein

WEBLATE_REGISTRATION_OPEN

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

Beispiel:

environment:
  WEBLATE_REGISTRATION_OPEN: 0

WEBLATE_REGISTRATION_ALLOW_BACKENDS

Configure which authentication methods can be used to create new account via REGISTRATION_ALLOW_BACKENDS.

Beispiel:

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

WEBLATE_TIME_ZONE

Configures the used time zone in Weblate, see TIME_ZONE.

Bemerkung

To change the time zone of the Docker container itself, use the TZ environment variable.

Beispiel:

environment:
  WEBLATE_TIME_ZONE: Europe/Prague

WEBLATE_ENABLE_HTTPS

Makes Weblate assume it is operated behind a reverse HTTPS proxy, it makes Weblate use HTTPS in e-mail and API links or set secure flags on cookies.

Hinweis

Please see ENABLE_HTTPS documentation for possible caveats.

Bemerkung

This does not make the Weblate container accept HTTPS connections, you need to configure that as well, see Docker-Container mit HTTPS-Unterstützung for examples.

Beispiel:

environment:
  WEBLATE_ENABLE_HTTPS: 1

Siehe auch

ENABLE_HTTPS Stellen Sie die richtige Websitedomäne ein, WEBLATE_SECURE_PROXY_SSL_HEADER

WEBLATE_INTERLEDGER_PAYMENT_POINTERS: Neu in Version 4.12.1.

Lets Weblate set the meta[name=monetization] field in the head of the document. If multiple are specified, chooses one randomly.

Siehe auch

INTERLEDGER_PAYMENT_POINTERS

WEBLATE_IP_PROXY_HEADER

Lets Weblate fetch the IP address from any given HTTP header. Use this when using a reverse proxy in front of the Weblate container.

Enables IP_BEHIND_REVERSE_PROXY and sets IP_PROXY_HEADER.

Bemerkung

The format must conform to Django’s expectations. Django transforms raw HTTP header names as follows:

converts all characters to uppercase
replaces any hyphens with underscores
prepends HTTP_ prefix

So X-Forwarded-For would be mapped to HTTP_X_FORWARDED_FOR.

Beispiel:

environment:
  WEBLATE_IP_PROXY_HEADER: HTTP_X_FORWARDED_FOR

WEBLATE_SECURE_PROXY_SSL_HEADER

A tuple representing a 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

SECURE_PROXY_SSL_HEADER

WEBLATE_REQUIRE_LOGIN

Enables REQUIRE_LOGIN to enforce authentication on whole Weblate.

Beispiel:

environment:
  WEBLATE_REQUIRE_LOGIN: 1

WEBLATE_LOGIN_REQUIRED_URLS_EXCEPTIONS

WEBLATE_ADD_LOGIN_REQUIRED_URLS_EXCEPTIONS

WEBLATE_REMOVE_LOGIN_REQUIRED_URLS_EXCEPTIONS

Adds URL exceptions for authentication required for the whole Weblate installation using LOGIN_REQUIRED_URLS_EXCEPTIONS.

You can either replace whole settings, or modify default value using ADD and REMOVE variables.

WEBLATE_GOOGLE_ANALYTICS_ID: Configures ID for Google Analytics by changing GOOGLE_ANALYTICS_ID.

WEBLATE_GITHUB_USERNAME

WEBLATE_GITHUB_TOKEN

WEBLATE_GITHUB_HOST: Konfiguriert die Integration von GitHub-Pull-Requests durch Ändern von GITHUB_CREDENTIALS (wenn WEBLATE_GITHUB_HOST gesetzt ist), oder GITHUB_USERNAME und GITHUB_TOKEN.

Siehe auch

GitHub-Pull-Requests

WEBLATE_GITLAB_USERNAME

WEBLATE_GITLAB_TOKEN

WEBLATE_GITLAB_HOST: Konfiguriert die Integration von GitLab-Merge-Requests durch Ändern von GITLAB_CREDENTIALS (wenn WEBLATE_GITLAB_HOST gesetzt ist), oder GITLAB_USERNAME und GITLAB_TOKEN.

Siehe auch

GitLab-Merge-Requests

WEBLATE_GITEA_USERNAME

WEBLATE_GITEA_TOKEN

WEBLATE_GITEA_HOST: Konfiguriert die Integration von Gitea-Pull-Requests durch Ändern von GITEA_CREDENTIALS (wenn WEBLATE_GITEA_HOST gesetzt ist), oder GITEA_USERNAME und GITEA_TOKEN.

Siehe auch

Gitea-Pull-Requests

WEBLATE_PAGURE_USERNAME

WEBLATE_PAGURE_TOKEN

WEBLATE_PAGURE_HOST: Konfiguriert die Integration von Pagure-Merge-Requests durch Ändern von PAGURE_CREDENTIALS (wenn WEBLATE_PAGURE_HOST gesetzt ist), oder PAGURE_USERNAME und PAGURE_TOKEN.

Siehe auch

Pagure-Merge-Requests

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: Configures the language simplification policy, see SIMPLIFY_LANGUAGES.

WEBLATE_DEFAULT_ACCESS_CONTROL: Configures the default Zugriffssteuerung for new projects, see DEFAULT_ACCESS_CONTROL.

WEBLATE_DEFAULT_RESTRICTED_COMPONENT: Configures the default value for Restricted access for new components, see DEFAULT_RESTRICTED_COMPONENT.

WEBLATE_DEFAULT_TRANSLATION_PROPAGATION: Configures the default value for Verbreitung von Übersetzungen erlauben for new components, see 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: Configures the Akismet API key, see AKISMET_API_KEY.

WEBLATE_GPG_IDENTITY: Configures GPG signing of commits, see WEBLATE_GPG_IDENTITY.

Siehe auch

Signing Git commits with GnuPG

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

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

WEBLATE_CSP_SCRIPT_SRC

WEBLATE_CSP_IMG_SRC

WEBLATE_CSP_CONNECT_SRC

WEBLATE_CSP_STYLE_SRC

WEBLATE_CSP_FONT_SRC: Allows to customize Content-Security-Policy HTTP header.

Siehe auch

Richtlinie zur Inhaltssicherheit, CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

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: Neu in Version 4.6.

Konfiguriert den Ratelimiter.

Hinweis

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

Siehe auch

Rate limiting, RATELIMIT_ATTEMPTS, RATELIMIT_WINDOW, RATELIMIT_LOCKOUT

WEBLATE_API_RATELIMIT_ANON

WEBLATE_API_RATELIMIT_USER: Neu in Version 4.11.

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

Siehe auch

API rate limiting

WEBLATE_ENABLE_HOOKS: Neu in Version 4.13.

Konfiguriert ENABLE_HOOKS.

WEBLATE_ENABLE_AVATARS: Neu in Version 4.6.1.

Konfiguriert ENABLE_AVATARS.

WEBLATE_AVATAR_URL_PREFIX: Neu in Version 4.15.

Konfiguriert AVATAR_URL_PREFIX.

WEBLATE_LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH: Neu in Version 4.9.

Konfiguriert LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH.

WEBLATE_SSH_EXTRA_ARGS: Neu in Version 4.9.

Konfiguriert SSH_EXTRA_ARGS.

WEBLATE_BORG_EXTRA_ARGS: Neu in Version 4.9.

Konfiguriert BORG_EXTRA_ARGS.

WEBLATE_ENABLE_SHARING: Neu in Version 4.14.1.

Konfiguriert ENABLE_SHARING.

WEBLATE_EXTRA_HTML_HEAD: Neu in Version 4.15.

Konfiguriert EXTRA_HTML_HEAD.

WEBLATE_PRIVATE_COMMIT_EMAIL_TEMPLATE: Neu in Version 4.15.

Konfiguriert PRIVATE_COMMIT_EMAIL_TEMPLATE.

WEBLATE_PRIVATE_COMMIT_EMAIL_OPT_IN: Neu in Version 4.15.

Konfiguriert PRIVATE_COMMIT_EMAIL_OPT_IN.

Automatische Vorschlagseinstellungen

Geändert in Version 4.13: Automatic suggestion services are now configured in the user interface, see Automatische Vorschläge konfigurieren.

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

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_BIND_PASSWORD_FILE: Pfad zu der Datei, die das LDAP-Server-Verbindungskennwort enthält.

Siehe auch

WEBLATE_AUTH_LDAP_BIND_PASSWORD

WEBLATE_AUTH_LDAP_CONNECTION_OPTION_REFERRALS

WEBLATE_AUTH_LDAP_USER_SEARCH

WEBLATE_AUTH_LDAP_USER_SEARCH_FILTER

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION

WEBLATE_AUTH_LDAP_USER_SEARCH_UNION_DELIMITER

Konfiguration der LDAP-Authentifizierung.

Example for direct bind:

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

Example for search and bind:

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

Example for union search and bind:

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

Example with search and bind against Active Directory:

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

Siehe auch

LDAP-Authentifizierung

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: Enables GitHub-Authentifizierung.

Bitbucket

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_KEY

WEBLATE_SOCIAL_AUTH_BITBUCKET_OAUTH2_SECRET

WEBLATE_SOCIAL_AUTH_BITBUCKET_KEY

WEBLATE_SOCIAL_AUTH_BITBUCKET_SECRET: Enables Bitbucket-Authentifizierung.

Facebook

WEBLATE_SOCIAL_AUTH_FACEBOOK_KEY

WEBLATE_SOCIAL_AUTH_FACEBOOK_SECRET: Enables 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: Enables Google OAuth 2.

GitLab

WEBLATE_SOCIAL_AUTH_GITLAB_KEY

WEBLATE_SOCIAL_AUTH_GITLAB_SECRET

WEBLATE_SOCIAL_AUTH_GITLAB_API_URL: Enables 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: Enables Azure Active Directory authentication, see Microsoft Azure Active Directory.

Azure Active Directory with Tenant support

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_KEY

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_SECRET

WEBLATE_SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_TENANT_ID: Enables Azure Active Directory authentication with Tenant support, see 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: Enables Keycloak authentication, see documentation.

Linux vendors

You can enable authentication using Linux vendors authentication services by setting following variables to any value.

WEBLATE_SOCIAL_AUTH_FEDORA

WEBLATE_SOCIAL_AUTH_OPENSUSE

WEBLATE_SOCIAL_AUTH_UBUNTU

Slack

WEBLATE_SOCIAL_AUTH_SLACK_KEY

SOCIAL_AUTH_SLACK_SECRET: Enables Slack authentication, see Slack.

OpenID Connect

Neu 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: Configures generic OpenID Connect intergration.

Siehe auch

OIDC (OpenID Connect)

SAML

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

WEBLATE_SAML_IDP_ENTITY_ID

WEBLATE_SAML_IDP_URL

WEBLATE_SAML_IDP_X509CERT

WEBLATE_SAML_IDP_IMAGE

WEBLATE_SAML_IDP_TITLE: SAML Identity Provider settings, see SAML-Authentifizierung.

Other authentication settings

WEBLATE_NO_EMAIL_AUTH: Disables e-mail authentication when set to any value. See Passwort-Authentifizierung deaktivieren.

PostgreSQL database setup

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

Siehe auch

Datenbankeinrichtung für Weblate

POSTGRES_PASSWORD: PostgreSQL-Passwort.

POSTGRES_PASSWORD_FILE: Path to the file containing the PostgreSQL password. Use as an alternative to POSTGRES_PASSWORD.

POSTGRES_USER: PostgreSQL-Benutzername.

POSTGRES_DATABASE: PostgreSQL-Datenbankname.

POSTGRES_HOST: PostgreSQL server hostname or IP address. Defaults to database.

POSTGRES_PORT: PostgreSQL server port. Defaults to none (uses the default value).

POSTGRES_SSL_MODE: Configure how PostgreSQL handles SSL in connection to the server, for possible choices see SSL Mode Descriptions

POSTGRES_ALTER_ROLE: Configures name of role to alter during migrations, see Weblate für die Verwendung von PostgreSQL konfigurieren.

POSTGRES_CONN_MAX_AGE

Neu in Version 4.8.1.

Die Lebensdauer einer Datenbankverbindung als ganze Zahl von Sekunden. Verwenden Sie 0, um Datenbankverbindungen am Ende jeder Anfrage zu schließen (dies ist das Standardverhalten).

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

Beispielkonfiguration:

environment:
    POSTGRES_CONN_MAX_AGE: 3600

Siehe auch

CONN_MAX_AGE, Persistent connections

POSTGRES_DISABLE_SERVER_SIDE_CURSORS

Neu in Version 4.9.1.

Disable server side cursors in the database. This is necessary in some pgbouncer setups.

Beispielkonfiguration:

environment:
    POSTGRES_DISABLE_SERVER_SIDE_CURSORS: 1

Siehe auch

DISABLE_SERVER_SIDE_CURSORS, Transaction pooling and server-side cursors

Database backup settings

Siehe auch

Gedumpte Daten für Backups

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

Caching server setup

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

Siehe auch

Aktivieren Sie Caching

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

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

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

REDIS_PASSWORD: The Redis server password, not used by default.

REDIS_PASSWORD_FILE: Pfad zu der Datei, die das Passwort für den Redis-Server enthält.

Siehe auch

REDIS_PASSWORD

REDIS_TLS: Enables using SSL for Redis connection.

REDIS_VERIFY_SSL: Can be used to disable SSL certificate verification for Redis connection.

Einrichtung eines E-Mail-Servers

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

Konfigurieren ausgehender E-Mail

WEBLATE_EMAIL_HOST: Mail server hostname or IP address.

Siehe auch

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, WEBLATE_EMAIL_USE_TLS, EMAIL_HOST

WEBLATE_EMAIL_PORT: Mail server port, defaults to 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

EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_HOST_PASSWORD_FILE: Pfad zu der Datei, die das Kennwort für die E-Mail-Authentifizierung enthält.

Siehe auch

WEBLATE_EMAIL_HOST_PASSWORD

WEBLATE_EMAIL_USE_SSL: Whether to use an implicit TLS (secure) connection when talking to the SMTP server. In most e-mail documentation, this type of TLS connection is referred to as SSL. It is generally used on port 465. If you are experiencing problems, see the explicit TLS setting WEBLATE_EMAIL_USE_TLS.

Geändert in Version 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Siehe auch

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_TLS, EMAIL_USE_SSL

WEBLATE_EMAIL_USE_TLS: Whether to use a TLS (secure) connection when talking to the SMTP server. This is used for explicit TLS connections, generally on port 587 or 25. If you are experiencing connections that hang, see the implicit TLS setting WEBLATE_EMAIL_USE_SSL.

Geändert in Version 4.11: The SSL/TLS support is automatically enabled based on the WEBLATE_EMAIL_PORT.

Siehe auch

WEBLATE_EMAIL_PORT, WEBLATE_EMAIL_USE_SSL, EMAIL_USE_TLS

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

Siehe auch

Konfigurieren Sie den E-Mail-Versand, EMAIL_BACKEND

WEBLATE_AUTO_UPDATE: Configures if and how Weblate should update repositories.

Siehe auch

AUTO_UPDATE

Bemerkung

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

Integration der Website

WEBLATE_GET_HELP_URL: Konfiguriert GET_HELP_URL.

WEBLATE_STATUS_URL: Konfiguriert STATUS_URL.

WEBLATE_LEGAL_URL: Konfiguriert LEGAL_URL.

WEBLATE_PRIVACY_URL: Konfiguriert PRIVACY_URL.

Fehlerbericht

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

To enable support for Rollbar, set the following:

ROLLBAR_KEY: Your Rollbar post server access token.

ROLLBAR_ENVIRONMENT: Your Rollbar environment, defaults to production.

To enable support for Sentry, set following:

SENTRY_DSN: Your Sentry DSN.

SENTRY_ENVIRONMENT: Your Sentry Environment (optional).

Lokalisierung CDN

WEBLATE_LOCALIZE_CDN_URL

WEBLATE_LOCALIZE_CDN_PATH

Neu in Version 4.2.1.

Configuration for JavaScript-Lokalisierung CDN.

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

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

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

Bemerkung

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

Siehe auch

Translating HTML and JavaScript using Weblate CDN, LOCALIZE_CDN_URL, LOCALIZE_CDN_PATH

Changing enabled apps, checks, add-ons or autofixes

Neu in Version 3.8-5.

The built-in configuration of enabled checks, add-ons or autofixes can be adjusted by the following variables:

WEBLATE_ADD_APPS

WEBLATE_REMOVE_APPS

WEBLATE_ADD_CHECK

WEBLATE_REMOVE_CHECK

WEBLATE_ADD_AUTOFIX

WEBLATE_REMOVE_AUTOFIX

WEBLATE_ADD_ADDONS

WEBLATE_REMOVE_ADDONS

Beispiel:

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

Siehe auch

CHECK_LIST, AUTOFIX_LIST, WEBLATE_ADDONS, INSTALLED_APPS

Container-Einstellungen

WEBLATE_WORKERS

Neu in Version 4.6.1.

Basisanzahl der im Container laufenden Arbeitsprozesse. 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

These variables allow you to adjust Celery worker options. It can be useful to adjust concurrency (--concurrency 16) or use different pool implementation (--pool=gevent).

By default, the number of concurrent workers is based on WEBLATE_WORKERS.

Beispiel:

environment:
  CELERY_MAIN_OPTIONS: --concurrency 16

Siehe auch

Celery worker options, Hintergrundaufgaben mit Celery

WEB_WORKERS

Configure how many uWSGI workers should be executed.

It defaults to WEBLATE_WORKERS.

Beispiel:

environment:
  WEB_WORKERS: 32

WEBLATE_SERVICE

Defines which services should be executed inside the container. Use this for 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 Backups, es sollte nur eine Instanz laufen.
celery-celery: Generischer 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 Datenvolumen wird verwendet, um persistente 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 der Speicherung statischer Dateien. 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.

Siehe auch

Dokumentation der Docker-Volumes

Konfiguration über Umgebungsvariablen hinaus

Docker environment variables are intended to expose most configuration settings of relevance for Weblate installations.

If you find a setting that is not exposed as an environment variable, and you believe that it should be, feel free to ask for it to be exposed in a future version of Weblate.

If you need to modify a setting that is not exposed as a Docker environment variable, you can still do so, either from the data volume or extending the Docker image.

Siehe auch

Anpassen von Weblate

Overriding settings from the data volume

You can create a file at /app/data/settings-override.py, i.e. at the root of the data volume, to extend or override settings defined through environment variables.

Overriding settings by extending the Docker image

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

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

For example, within the example package structure defined at Erstellung eines Python-Moduls, you could create a file at weblate_customization/weblate_customization/settings.py with the following initial code:
```
from weblate.settings_docker import *
```

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

FROM weblate/weblate

USER root

COPY weblate_customization /usr/src/weblate_customization
RUN pip install --no-cache-dir /usr/src/weblate_customization
ENV DJANGO_SETTINGS_MODULE=weblate_customization.settings

USER 1000

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

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

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

See the Compose file build reference for details on building images from source when using docker-compose.
Extend your custom settings module to define or redefine settings.

You can define settings before or after the import statement above to determine which settings take precedence. Settings defined before the import statement can be overriden by environment variables and setting overrides defined in the data volume. Setting defined after the import statement cannot be overriden.

You can also go further. For example, you can reproduce some of the things that weblate.docker_settings does, such as exposing settings as environment variables, or allow overriding settings from Python files in the data volume.

Ersetzen des Logos und anderer statischer Dateien

Neu in Version 3.8-5.

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.

This approach can be also used to override Weblate templates. For example Rechtliche Grundlagen documents can be placed into /app/data/python/customize/templates/legal/documents.

Alternativ können Sie auch ein eigenes Modul einbinden (siehe Anpassen von Weblate) und es z.B. 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

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

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

Container-Interna

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

Um den Status der Dienste zu überprüfen, verwenden Sie:

docker-compose exec --user weblate weblate supervisorctl status

There are individual services for each Celery queue (see Hintergrundaufgaben mit Celery for details). You can stop processing some tasks by stopping the appropriate worker:

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