Konfigurationsanweisungen

Weblate installieren

Wählen Sie je nach Ihren Gegebenheiten und Ihrer Erfahrung eine für Sie geeignete Installationsmethode:

Installation über Docker, empfohlen für Produktionssysteme.
Virtualenv-Installation, empfohlen für Produktionssysteme:
Installieren aus Quellen, empfohlen für die Entwicklung.
Installation auf OpenShift
Unter Kubernetes installieren

Software-Anforderungen

Betriebssystem

Von Weblate ist bekannt, dass es unter Linux, FreeBSD und macOS funktioniert. Andere Unix-ähnliche Systeme werden höchstwahrscheinlich auch funktionieren.

Weblate wird unter Windows nicht unterstützt. Aber es kann trotzdem funktionieren und Patches werden gerne angenommen.

Andere Dienste

Weblate nutzt andere Dienste für seinen Betrieb. Sie müssen mindestens die folgenden Dienste ausführen:

PostgreSQL-Datenbank-Server, siehe Datenbankeinrichtung für Weblate.
Redis-Server für Cache und Aufgabenwarteschlange, siehe Hintergrundaufgaben mit Celery.
SMTP-Server für ausgehende E-Mails, siehe Konfigurieren ausgehender E-Mail.

Python-Abhängigkeiten

Weblate ist in Python geschrieben und unterstützt Python 3.6 oder neuer. Sie können die Abhängigkeiten mit pip oder aus Ihren Distributionspaketen installieren, eine vollständige Liste finden Sie in requirements.txt.

Wichtigste Abhängigkeiten:

Django: https://www.djangoproject.com/
Celery: https://docs.celeryq.dev/
Translate Toolkit: https://toolkit.translatehouse.org/
translation-finder: https://github.com/WeblateOrg/translation-finder
Python Social Auth: https://python-social-auth.readthedocs.io/
Django REST-Framework: https://www.django-rest-framework.org/

Optionale Abhängigkeiten

Die folgenden Module sind für einige Weblate-Funktionen erforderlich. Sie finden sie alle in requirements-optional.txt.

Mercurial`(optional für die Unterstützung von :ref:`vcs-mercurial-Repositorys): https://www.mercurial-scm.org/
phply (optional für PHP-Zeichenketten): https://github.com/viraptor/phply
tesserocr (optional für OCR in Bildschirmfotos): https://github.com/sirfz/tesserocr
python-akismet (optional für Spam protection): https://github.com/Nekmo/python-akismet
ruamel.yaml (optional für YAML-Dateien): https://pypi.org/project/ruamel.yaml/
Zeep (optional für Microsoft Terminology): https://docs.python-zeep.org/
aeidon (optional für Untertiteldateien): https://pypi.org/project/aeidon/
fluent.syntax (optional für Fluent-Format): https://projectfluent.org/

Hinweis

Wenn Sie mit pip installieren, können Sie die gewünschten Funktionen direkt bei der Installation angeben:

pip install "Weblate[PHP,Fluent]"

Oder Sie können Weblate mit allen optionalen Funktionen installieren:

pip install "Weblate[all]"

Oder Sie können Weblate ohne optionale Funktionen installieren:

pip install Weblate

Datenbank-Backend-Abhängigkeiten

Weblate unterstützt PostgreSQL, MySQL und MariaDB, siehe Datenbankeinrichtung für Weblate und Backend-Dokumentation für weitere Details.

Weitere Systemanforderungen

Die folgenden Abhängigkeiten müssen auf dem System installiert sein:

Git: https://git-scm.com/
Pango, Cairo und zugehörige Header-Dateien sowie GObject-Introspektionsdaten: https://cairographics.org/, https://pango.gnome.org/, siehe Pangokairo
git-review“ (optional für Gerrit-Unterstützung): https://pypi.org/project/git-review/
git-svn (optional für Subversion-Unterstützung): https://git-scm.com/docs/git-svn
tesseract und seine Daten (optional für Bildschirmfotos-OCR): https://github.com/tesseract-ocr/tesseract
`licensee`(optional zur Erkennung der Lizenz beim Erstellen der Komponente): https://github.com/licensee/licensee

Build-Zeit-Abhängigkeiten

Um einige der Python-Abhängigkeiten zu bauen, müssen Sie möglicherweise deren Abhängigkeiten installieren. Dies hängt davon ab, wie Sie sie installieren, also konsultieren Sie bitte die Dokumentation der einzelnen Pakete. Sie werden diese nicht benötigen, wenn Sie das vorgefertigte Wheels verwenden, während Sie pip installieren oder wenn Sie Distributionspakete verwenden.

Pango und Kairo

Geändert in Version 3.7.

Weblate verwendet Pango und Cairo für die Darstellung von Bitmap-Widgets (siehe Übersetzung gezielt fördern) und für die Darstellung von Qualitätsprüfungen (siehe Schriftarten verwalten). Um die Python-Bindings dafür richtig zu installieren, müssen Sie zuerst die Systembibliotheken installieren – Sie brauchen sowohl Cairo als auch Pango, die wiederum GLib benötigen. Alle diese Bibliotheken sollten zusammen mit Entwicklungsdateien und GObject-Introspektionsdaten installiert werden.

Überprüfen von Veröffentlichungssignaturen

Weblate-Veröffentlichungen werden vom veröffentlichenden Entwickler kryptografisch signiert. Derzeit ist dies Michal Čihař. Der Fingerabdruck seines PGP-Schlüssels lautet:

63CB 1DF1 EF12 CF2A C0EE 5A32 9C27 B313 42B7 511D

und weitere Informationen zur Identifizierung erhalten Sie unter <https://keybase.io/nijel>.

Sie sollten überprüfen, ob die Signatur mit dem heruntergeladenen Archiv übereinstimmt. Auf diese Weise können Sie sicher sein, dass Sie denselben Code verwenden, der veröffentlicht wurde. Sie sollten auch das Datum der Signatur überprüfen, um sicherzustellen, dass Sie die neueste Version heruntergeladen haben.

Jedem Archiv liegen .asc Dateien bei, die die PGP-Signatur für das Archiv enthalten. Sobald Sie beide Dateien im selben Ordner haben, können Sie die Signatur überprüfen:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Can't check signature: public key not found

Wie Sie sehen können, beschwert sich GPG, dass es den öffentlichen Schlüssel nicht kennt. An diesem Punkt sollten Sie einen der folgenden Schritte durchführen:

Verwenden Sie ‚wkd‘, um den Schlüssel herunterzuladen:

$ gpg --auto-key-locate wkd --locate-keys michal@cihar.com
pub   rsa4096 2009-06-17 [SC]
      63CB1DF1EF12CF2AC0EE5A329C27B31342B7511D
uid           [ultimate] Michal Čihař <michal@cihar.com>
uid           [ultimate] Michal Čihař <nijel@debian.org>
uid           [ultimate] [jpeg image of size 8848]
uid           [ultimate] Michal Čihař (Braiins) <michal.cihar@braiins.cz>
sub   rsa4096 2009-06-17 [E]
sub   rsa4096 2015-09-09 [S]

Laden Sie den Keyring von Michals Server herunter und importieren Sie ihn mit:

$ gpg --import wmxth3chu9jfxdxywj1skpmhsj311mzm

Herunterladen und Importieren des Schlüssels von einem der Schlüsselserver:

$ gpg --keyserver hkp://pgp.mit.edu --recv-keys 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: key 9C27B31342B7511D: "Michal Čihař <michal@cihar.com>" imported
gpg: Total number processed: 1
gpg:              unchanged: 1

Dies verbessert die Situation ein wenig – zu diesem Zeitpunkt können Sie zwar überprüfen, ob die Signatur des angegebenen Schlüssels korrekt ist, aber Sie können dem im Schlüssel verwendeten Namen immer noch nicht vertrauen:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Ne 3. března 2019, 16:43:15 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 63CB 1DF1 EF12 CF2A C0EE  5A32 9C27 B313 42B7 511D

Das Problem dabei ist, dass jeder einen Schlüssel mit diesem Namen ausstellen könnte. Sie müssen sicherstellen, dass der Schlüssel tatsächlich der genannten Person gehört. Das GNU Privacy Handbook behandelt dieses Thema im Kapitel Validating other keys on your public keyring. Die zuverlässigste Methode ist es, den Entwickler persönlich zu treffen und die Fingerabdrücke der Schlüssel auszutauschen, aber Sie können sich auch auf das Netz des Vertrauens verlassen. Auf diese Weise können Sie dem Schlüssel durch die Unterschriften anderer Personen, die den Entwickler persönlich getroffen haben, vertrauen.

Sobald der Schlüssel vertrauenswürdig ist, wird die Warnung nicht angezeigt:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: assuming signed data in 'Weblate-3.5.tar.xz'
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: Good signature from "Michal Čihař <michal@cihar.com>" [ultimate]
gpg:                 aka "Michal Čihař <nijel@debian.org>" [ultimate]
gpg:                 aka "[jpeg image of size 8848]" [ultimate]
gpg:                 aka "Michal Čihař (Braiins) <michal.cihar@braiins.cz>" [ultimate]

Sollte die Signatur ungültig sein (das Archiv wurde geändert), erhalten Sie eine eindeutige Fehlermeldung, unabhängig davon, ob der Schlüssel vertrauenswürdig ist oder nicht:

$ gpg --verify Weblate-3.5.tar.xz.asc
gpg: Signature made Sun Mar  3 16:43:15 2019 CET
gpg:                using RSA key 87E673AF83F6C3A0C344C8C3F4AA229D4D58C245
gpg: BAD signature from "Michal Čihař <michal@cihar.com>" [ultimate]

Dateisystemberechtigungen

Der Weblate-Prozess muss in der Lage sein, vom und ins Verzeichnis zu lesen und zu schreiben, in dem er Daten speichert – DATA_DIR. Alle Dateien in diesem Verzeichnis sollten dem Benutzer gehören, der alle Weblate-Prozesse ausführt (normalerweise WSGI und Celery, siehe Laufender Server und Hintergrundaufgaben mit Celery).

Die Standardkonfiguration platziert sie im selben Baum wie die Weblate-Quellen, aber Sie könnten es vorziehen, sie an einen besseren Ort zu verschieben, wie zum Beispiel: /var/lib/weblate.

Weblate versucht, diese Verzeichnisse automatisch zu erstellen, aber es wird scheitern, wenn es keine entsprechenden Rechte hat.

Sie sollten auch vorsichtig sein, wenn Sie Verwaltungsbefehle ausführen, da sie unter demselben Benutzer ausgeführt werden sollten, unter dem auch Weblate selbst läuft, da sonst die Berechtigungen für einige Dateien falsch sein könnten.

Im Docker-Container müssen alle Dateien im Volume /app/data dem Benutzer weblate innerhalb des Containers gehören (UID 1000).

Siehe auch

Bereitstellung statischer Dateien

Datenbankeinrichtung für Weblate

Es wird empfohlen, Weblate mit einem PostgreSQL-Datenbankserver zu betreiben.

Siehe auch

Eine leistungsstarke Datenbank-Engine verwenden, Databases, Migration von anderen Datenbanken zu PostgreSQL

PostgreSQL

PostgreSQL ist normalerweise die beste Wahl für Django-basierte Websites. Es ist die Referenzdatenbank, die für die Implementierung der Django-Datenbankschicht verwendet wird.

Bemerkung

Weblate verwendet die Trigram-Erweiterung, die in einigen Fällen separat installiert werden muss. Suchen Sie nach postgresql-contrib oder einem ähnlich benannten Paket.

Siehe auch

PostgreSQL notes

Erstellen einer Datenbank in PostgreSQL

Normalerweise ist es eine gute Idee, Weblate in einer separaten Datenbank und unter einem separaten Benutzerkonto laufen zu lassen:

# If PostgreSQL was not installed before, set the main password
sudo -u postgres psql postgres -c "\password postgres"

# Create a database user called "weblate"
sudo -u postgres createuser --superuser --pwprompt weblate

# Create the database "weblate" owned by "weblate"
sudo -u postgres createdb -E UTF8 -O weblate weblate

Hinweis

Wenn Sie den Weblate-Benutzer nicht zu einem Superuser in PostgreSQL machen wollen, können Sie das weglassen. In diesem Fall müssen Sie einige der Migrationsschritte manuell als PostgreSQL-Superuser im Schema durchführen, das Weblate verwenden wird:

CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA weblate;
CREATE EXTENSION IF NOT EXISTS btree_gin WITH SCHEMA weblate;

Weblate für die Verwendung von PostgreSQL konfigurieren

Das settings.py-Snippet für PostgreSQL:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.postgresql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Name of role to alter to set parameters in PostgreSQL,
        # use in case role name is different than user used for authentication.
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
    }
}

Die Datenbankmigration führt ALTER ROLE für die von Weblate verwendete Datenbankrolle durch. In den meisten Fällen stimmt der Name der Rolle mit dem Benutzernamen überein. In komplexeren Setups unterscheidet sich der Rollenname vom Benutzernamen und Sie erhalten eine Fehlermeldung über eine nicht existierende Rolle während der Datenbankmigration (psycopg2.errors.UndefinedObject: role "weblate@hostname" does not exist). Es ist bekannt, dass dies mit Azure Database for PostgreSQL passiert, aber es ist nicht auf diese Umgebung beschränkt. Bitte setzen Sie ALTER_ROLE, um den Namen der Rolle zu ändern, die Weblate während der Datenbankmigration ändern soll.

MySQL und MariaDB

Hinweis

Einige Weblate-Funktionen werden mit PostgreSQL besser funktionieren. Dazu gehören die Suche und das Translation Memory, die Volltextfunktionen in der Datenbank nutzen, wobei die PostgreSQL-Implementierung besser ist.

Weblate kann auch mit MySQL oder MariaDB verwendet werden, bitte lesen Sie MySQL notes und MariaDB notes für Hinweise zur Verwendung von Django mit diesen. Aufgrund der Einschränkungen wird empfohlen, PostgreSQL für neue Installationen zu verwenden.

Weblate benötigt MySQL mindestens in der Version 5.7.8 oder MariaDB mindestens in der Version 10.2.7.

Die folgende Konfiguration wird für Weblate empfohlen:

Verwenden Sie den Zeichensatz utf8mb4, um die Darstellung höherer Unicode-Ebenen (zum Beispiel Emojis) zu ermöglichen.
Konfigurieren Sie den Server mit innodb_large_prefix, um längere Indizes für Textfelder zu ermöglichen.
Setzen Sie die Isolationsstufe auf READ COMMITTED.
Der SQL-Modus sollte auf STRICT_TRANS_TABLES eingestellt werden.

MySQL 8.x, MariaDB 10.5.x oder neuer haben eine vernünftige Standardkonfiguration, sodass keine Serveranpassung notwendig sein sollte und alles, was benötigt wird, auf der Client-Seite konfiguriert werden kann.

Unten ist ein /etc/my.cnf.d/server.cnf Beispiel für einen Server mit 8 GB RAM. Diese Einstellungen sollten für die meisten Installationen ausreichend sein. MySQL und MariaDB verfügen über Einstellungen, die die Leistung Ihres Servers erhöhen, die aber nicht als notwendig erachtet werden, es sei denn, Sie planen, dass eine große Anzahl von Benutzern gleichzeitig auf das System zugreift. Einzelheiten hierzu finden Sie in der Dokumentation des jeweiligen Anbieters.

Um Probleme bei der Installation zu vermeiden, ist es absolut wichtig, dass die Einstellung innodb_file_per_table richtig gesetzt ist und MySQL/MariaDB neu gestartet wurde, bevor Sie Ihre Weblate-Installation starten.

[mysqld]
character-set-server = utf8mb4
character-set-client = utf8mb4
collation-server = utf8mb4_unicode_ci

datadir=/var/lib/mysql

log-error=/var/log/mariadb/mariadb.log

innodb_large_prefix=1
innodb_file_format=Barracuda
innodb_file_per_table=1
innodb_buffer_pool_size=2G
sql_mode=STRICT_TRANS_TABLES

Hinweis

Falls Sie den Fehler #1071 - Specified key was too long; max key length is 767 bytes erhalten, aktualisieren Sie bitte Ihre Konfiguration, um die obigen Einstellungen innodb zu übernehmen und starten Sie Ihre Installation neu.

Hinweis

Falls Sie den Fehler #2006 - MySQL server has gone away erhalten, könnte die Konfiguration von CONN_MAX_AGE helfen.

Weblate für die Verwendung von MySQL/MariaDB konfigurieren

Das settings.py-Snippet für MySQL und MariaDB:

DATABASES = {
    "default": {
        # Database engine
        "ENGINE": "django.db.backends.mysql",
        # Database name
        "NAME": "weblate",
        # Database user
        "USER": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "127.0.0.1",
        # Set to empty string for default
        "PORT": "3306",
        # In case you wish to use additional
        # connection options
        "OPTIONS": {},
    }
}

Sie sollten auch das Benutzerkonto weblate in MySQL oder MariaDB erstellen, bevor Sie mit der Installation beginnen. Verwenden Sie dazu die folgenden Befehle:

GRANT ALL ON weblate.* to 'weblate'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

Andere Konfigurationen

Konfigurieren ausgehender E-Mail

Weblate verschickt zu verschiedenen Anlässen E-Mails – zur Kontoaktivierung und zu verschiedenen vom Nutzer konfigurierten Benachrichtigungen. Hierfür benötigt es Zugang zu einem SMTP-Server.

Das Mailserver-Setup wird mit diesen Einstellungen konfiguriert: EMAIL_HOST, EMAIL_HOST_PASSWORD, EMAIL_USE_TLS, EMAIL_USE_SSL, EMAIL_HOST_USER und EMAIL_PORT. Ihre Namen sind ziemlich selbsterklärend, aber Sie können mehr Informationen in der Django-Dokumentation finden.

Hinweis

Falls Sie die Fehlermeldung erhalten, dass die Authentifizierung nicht unterstützt wird (z. B. SMTP AUTH extension not supported by server), liegt das wahrscheinlich daran, dass Sie eine unsichere Verbindung verwenden und der Server sich weigert, sich auf diese Weise zu authentifizieren. Versuchen Sie in diesem Fall EMAIL_USE_TLS zu aktivieren.

Siehe auch

Keine E-Mails von Weblate erhalten, Konfiguration der ausgehenden E-Mails im Docker-Container

Hinter einem Reverse-Proxy ausführen

Mehrere Funktionen in Weblate sind darauf angewiesen, dass die IP-Adresse des Clients ermittelt werden kann. Dazu gehören Ratenbegrenzung, Spam protection oder Audit-Protokoll.

In der Standardkonfiguration parst Weblate die IP-Adresse von REMOTE_ADDR, die durch den WSGI-Handler gesetzt wird.

Falls Sie einen Reverse-Proxy verwenden, enthält dieses Feld höchstwahrscheinlich dessen Adresse. Sie müssen Weblate so konfigurieren, dass es zusätzlichen HTTP-Headern vertraut und die IP-Adresse aus diesen auswertet. Dies kann nicht standardmäßig aktiviert werden, da dies bei Installationen, die keinen Reverse-Proxy verwenden, IP-Adress-Spoofing ermöglichen würde. Die Aktivierung von IP_BEHIND_REVERSE_PROXY dürfte für die meisten üblichen Installationen ausreichen, aber möglicherweise müssen Sie auch IP_PROXY_HEADER und IP_PROXY_OFFSET anpassen.

Eine weitere Sache, auf die Sie achten müssen, ist der Host-Header. Er sollte mit dem übereinstimmen, der als SITE_DOMAIN konfiguriert ist. Möglicherweise ist eine zusätzliche Konfiguration in Ihrem Reverse-Proxy erforderlich (verwenden Sie zum Beispiel ProxyPreserveHost On für Apache oder proxy_set_header Host $host; für nginx).

Siehe auch

Spam protection, Ratenbegrenzung, Audit-Protokoll, IP_BEHIND_REVERSE_PROXY, IP_PROXY_HEADER, IP_PROXY_OFFSET, SECURE_PROXY_SSL_HEADER

HTTP-Proxy

Weblate führt VCS-Befehle aus und diese akzeptieren die Proxy-Konfiguration aus der Umgebung. Es wird empfohlen, die Proxy-Einstellungen in settings.py zu definieren:

import os

os.environ["http_proxy"] = "http://proxy.example.com:8080"
os.environ["HTTPS_PROXY"] = "http://proxy.example.com:8080"

Siehe auch

Proxy-Umgebungsvariablen

Anpassen der Konfiguration

Siehe auch

Beispielkonfiguration

Kopieren Sie weblate/settings_example.py nach weblate/settings.py und passen Sie es an Ihre Einrichtung an. Wahrscheinlich werden Sie die folgenden Optionen anpassen:

ADMINS

Liste der Website-Administratoren, die Benachrichtigungen erhalten sollen, wenn etwas schiefläuft, z. B. Benachrichtigungen über fehlgeschlagene Merges oder Django-Fehler.

Siehe auch

ADMINS, Administratoren richtig konfigurieren

ALLOWED_HOSTS

Sie müssen hier die Hosts auflisten, die Ihre Website bedienen soll. Zum Beispiel:
ALLOWED_HOSTS = ["demo.weblate.org"]
Alternativ können Sie auch einen Platzhalter einfügen:
ALLOWED_HOSTS = ["*"]
Siehe auch

ALLOWED_HOSTS, WEBLATE_ALLOWED_HOSTS, Einrichtung zulässiger Hosts

SESSION_ENGINE

Konfigurieren Sie, wie Ihre Sitzungen gespeichert werden sollen. Wenn Sie die Standard-Datenbank-Backend-Engine beibehalten, sollten Sie Folgendes vorsehen: weblate clearsessions, um veraltete Sitzungsdaten aus der Datenbank zu entfernen.

Wenn Sie Redis als Cache verwenden (siehe Caching einschalten), ist es empfehlenswert, ihn auch für Sitzungen zu verwenden:
SESSION_ENGINE = "django.contrib.sessions.backends.cache"
Siehe auch

Configuring the session engine, SESSION_ENGINE

DATABASES

Verbindung zum Datenbankserver, bitte lesen Sie die Django-Dokumentation für weitere Details.

Siehe auch

Datenbankeinrichtung für Weblate, DATABASES, Databases

DEBUG

Deaktivieren Sie dies für alle Produktionsserver. Wenn der Debugmodus aktiviert ist, zeigt Django den Benutzern im Falle eines Fehlers Backtraces an. Wenn Sie ihn deaktivieren, werden Fehler per E-Mail an ADMINS (siehe oben) gesendet.

Der Debugmodus verlangsamt auch Weblate, da Django in diesem Fall viel mehr Informationen intern speichert.

Siehe auch

DEBUG, Debugmodus deaktivieren

DEFAULT_FROM_EMAIL

E-Mail-Absenderadresse für ausgehende E-Mails, z. B. Registrierungs-E-Mails.

Siehe auch

DEFAULT_FROM_EMAIL

SECRET_KEY

Schlüssel, der von Django verwendet wird, um einige Informationen in Cookies zu signieren, siehe Geheimer Django-Schlüssel für weitere Informationen.

Siehe auch

SECRET_KEY

SERVER_EMAIL

E-Mail, die als Absenderadresse für den Versand von E-Mails an den Administrator verwendet wird, z. B. für Benachrichtigungen über fehlgeschlagene Merges.

Siehe auch

SERVER_EMAIL

Füllen der Datenbank

Nachdem Ihre Konfiguration fertig ist, können Sie weblate migrate ausführen, um die Datenbankstruktur zu erstellen. Nun sollten Sie in der Lage sein, Übersetzungsprojekte über die Adminoberfläche zu erstellen.

Wenn Sie die Installation nicht interaktiv durchführen möchten, können Sie weblate migrate --noinput verwenden und dann mit dem Befehl createadmin einen Administrator-Benutzer erstellen.

Wenn Sie fertig sind, sollten Sie auch den Leistungsbericht in der Adminoberfläche überprüfen, der Ihnen Hinweise auf eine möglicherweise nicht optimale Konfiguration Ihrer Website gibt.

Siehe auch

Konfiguration, Liste der Berechtigungen und integrierten Rollen

Produktionseinrichtung

Für eine Produktionseinrichtung sollten Sie die in den folgenden Abschnitten beschriebenen Anpassungen vornehmen. Die kritischsten Einstellungen lösen eine Warnung aus, die durch ein Ausrufezeichen in der oberen Leiste angezeigt wird, wenn Sie als Superuser angemeldet sind:

Es wird auch empfohlen, die von Django ausgelösten Prüfungen zu kontrollieren (auch wenn Sie nicht alle korrigieren müssen):

weblate check --deploy

Sie können die gleiche Checkliste auch über die Verwaltungsoberfläche einsehen.

Siehe auch

Deployment checklist

Debugmodus deaktivieren

Deaktivieren Sie den Debugmodus von Django (DEBUG) durch:

DEBUG = False

Wenn der Debugmodus aktiviert ist, speichert Django alle ausgeführten Abfragen und zeigt den Benutzern Rückverfolgungen von Fehlern an, was in einer Produktionsumgebung nicht erwünscht ist.

Siehe auch

Anpassen der Konfiguration

Administratoren richtig konfigurieren

Setzen Sie die richtigen Administrator-Adressen in der Einstellung ADMINS, um festzulegen, wer E-Mails erhalten soll, wenn zum Beispiel auf dem Server etwas schiefläuft:

ADMINS = (("Your Name", "your_email@example.com"),)

Siehe auch

Anpassen der Konfiguration

Seitendomain richtig einstellen

Passen Sie den Seitenname und die Seitendomain in der Adminoberfläche an, da sonst die Links in RSS oder Registrierungs-E-Mails nicht funktionieren. Dies wird mit SITE_DOMAIN konfiguriert, das den Namen der Seitendomain enthalten sollte.

Geändert in Version 4.2: Vor der Version 4.2 wurde stattdessen das Django Sites Framework verwendet, siehe The “sites” framework.

Siehe auch

Einrichtung zulässiger Hosts, HTTPS richtig konfigurieren SITE_DOMAIN, WEBLATE_SITE_DOMAIN, ENABLE_HTTPS

HTTPS richtig konfigurieren

Es wird dringend empfohlen, Weblate über das verschlüsselte HTTPS-Protokoll laufen zu lassen. Nachdem Sie es aktiviert haben, sollten Sie ENABLE_HTTPS in den Einstellungen setzen:

ENABLE_HTTPS = True

Hinweis

Vielleicht möchten Sie auch HSTS einrichten, siehe SSL/HTTPS für weitere Details.

Siehe auch

ENABLE_HTTPS, Einrichtung zulässiger Hosts, Seitendomain richtig einstellen

SECURE_HSTS_SECONDS richtig einstellen

Wenn Ihre Website über SSL bereitgestellt wird, müssen Sie einen Wert für SECURE_HSTS_SECONDS in der settings.py setzen, um HTTP Strict Transport Security zu aktivieren. Standardmäßig ist dieser Wert auf 0 gesetzt, wie unten gezeigt.

SECURE_HSTS_SECONDS = 0

Wenn auf einen Integer-Wert ungleich Null gesetzt, setzt django.middleware.security.SecurityMiddleware den HTTP Strict Transport Security-Header auf alle Antworten, die ihn nicht bereits haben.

Warnung

Eine falsche Einstellung kann Ihre Website unwiderruflich (für einige Zeit) zerstören. Lesen Sie zuerst die HTTP Strict Transport Security Dokumentation.

Eine leistungsstarke Datenbank-Engine verwenden

Bitte verwenden Sie PostgreSQL für eine Produktionsumgebung, siehe Datenbankeinrichtung für Weblate für weitere Informationen.
Verwenden Sie einen benachbarten Standort für den Betrieb des Datenbankservers, da sonst die Netzwerkleistung oder -zuverlässigkeit Ihr Weblate-Erlebnis beeinträchtigen könnte.
Überprüfen Sie die Leistung des Datenbankservers oder passen Sie seine Konfiguration an, zum Beispiel mit PGTune.

Siehe auch

Datenbankeinrichtung für Weblate, Migration von anderen Datenbanken zu PostgreSQL, Anpassen der Konfiguration, Databases

Caching einschalten

Wenn möglich, verwenden Sie Redis von Django aus, indem Sie zum Beispiel die Konfigurationsvariable CACHES anpassen:

CACHES = {
    "default": {
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/0",
        # If redis is running on same host as Weblate, you might
        # want to use unix sockets instead:
        # 'LOCATION': 'unix:///var/run/redis/redis.sock?db=0',
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    }
}

Hinweis

Falls Sie die Redis-Einstellungen für den Cache ändern, müssen Sie diese möglicherweise auch für Celery anpassen, siehe Hintergrundaufgaben mit Celery.

Siehe auch

Avatar-Caching, Django’s cache framework

Avatar-Caching

Zusätzlich zum Caching von Django führt Weblate auch ein Caching von Avataren durch. Es wird empfohlen, für diesen Zweck einen separaten, dateibasierten Cache zu verwenden:

CACHES = {
    "default": {
        # Default caching backend setup, see above
        "BACKEND": "django_redis.cache.RedisCache",
        "LOCATION": "unix:///var/run/redis/redis.sock?db=0",
        "OPTIONS": {
            "CLIENT_CLASS": "django_redis.client.DefaultClient",
            "PARSER_CLASS": "redis.connection.HiredisParser",
        },
    },
    "avatar": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": os.path.join(DATA_DIR, "avatar-cache"),
        "TIMEOUT": 604800,
        "OPTIONS": {
            "MAX_ENTRIES": 1000,
        },
    },
}

Siehe auch

ENABLE_AVATARS, AVATAR_URL_PREFIX, Avatars, Caching einschalten, Django’s cache framework

E-Mail-Versand konfigurieren

Weblate verschickt zu verschiedenen Anlässen E-Mails und diese sollten eine korrekte Absenderadresse haben. Bitte konfigurieren Sie SERVER_EMAIL und DEFAULT_FROM_EMAIL so, dass sie zu Ihrer Einsatzumgebung passen, zum Beispiel:

SERVER_EMAIL = "admin@example.org"
DEFAULT_FROM_EMAIL = "weblate@example.org"

Bemerkung

Um den Versand von E-Mails durch Weblate zu deaktivieren, setzen Sie EMAIL_BACKEND auf django.core.mail.backends.dummy.EmailBackend.

Dies deaktiviert alle E-Mails, einschließlich der E-Mails zur Registrierung oder zum Zurücksetzen des Passworts.

Siehe auch

Anpassen der Konfiguration, Konfigurieren ausgehender E-Mail, EMAIL_BACKEND, DEFAULT_FROM_EMAIL, SERVER_EMAIL

Einrichtung zulässiger Hosts

Django benötigt ALLOWED_HOSTS, um eine Liste von Domänennamen zu speichern, die Ihre Seite bedienen darf. Wenn Sie die Liste leer lassen, werden alle Anfragen blockiert.

Wenn dies nicht so konfiguriert ist, dass es zu Ihrem HTTP-Server passt, erhalten Sie Fehler wie Invalid HTTP_HOST header: '1.1.1.1'. You may need to add '1.1.1.1' to ALLOWED_HOSTS.

Hinweis

Auf Docker-Containern ist dies als WEBLATE_ALLOWED_HOSTS verfügbar.

Siehe auch

ALLOWED_HOSTS, WEBLATE_ALLOWED_HOSTS, Seitendomain richtig einstellen

Geheimer Django-Schlüssel

Die Einstellung SECRET_KEY wird von Django verwendet, um Cookies zu signieren. Sie sollten wirklich Ihren eigenen Wert erzeugen, anstatt den aus dem Beispiel-Setup zu verwenden.

Sie können einen neuen Schlüssel mittels weblate-generate-secret-key erzeugen, das mit Weblate ausgeliefert wird.

Siehe auch

SECRET_KEY

Ausführen von Wartungsaufgaben

Für eine optimale Leistung empfiehlt es sich, einige Wartungsaufgaben im Hintergrund laufen zu lassen. Dies wird nun automatisch von Hintergrundaufgaben mit Celery erledigt und umfasst die folgenden Aufgaben:

Konfigurationsintegritätsprüfung (stündlich).
Übertragen anstehender Änderungen (stündlich), siehe Lazy Commits und commit_pending.
Aktualisieren von Komponentenwarnungen (täglich).
Entfernte Branches aktualisieren (nachts), siehe AUTO_UPDATE.
Translation-Memory-Backup in JSON (täglich), siehe dump_memory.
Volltext- und Datenbankwartungsaufgaben (tägliche und wöchentliche Aufgaben), siehe :d jadmin:‘cleanuptrans‘.

Geändert in Version 3.2: Seit Version 3.2 werden diese Aufgaben standardmäßig mit Celery ausgeführt und Weblate wird bereits mit einer entsprechenden Konfiguration geliefert, siehe Hintergrundaufgaben mit Celery.

System-Sprachumgebungen und -Kodierung

Die System-Sprachumgebungen sollten als UTF-8-fähig konfiguriert werden. Bei den meisten Linux-Distributionen ist dies die Standardeinstellung. Falls dies auf Ihrem System nicht der Fall ist, ändern Sie bitte die Sprachumgebungen auf die UTF-8-Variante.

Zum Beispiel, indem Sie /etc/default/locale bearbeiten und dort LANG="C.UTF-8" einstellen.

In einigen Fällen haben die einzelnen Dienste eine separate Konfiguration für Sprachumgebungen. Dies ist je nach Distribution und Webserver unterschiedlich, daher sollten Sie die Dokumentation Ihrer Webserver-Pakete daraufhin überprüfen.

Apache unter Ubuntu verwendet /etc/apache2/envvars:

export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'

Apache unter CentOS verwendet /etc/sysconfig/httpd (oder /opt/rh/httpd24/root/etc/sysconfig/httpd):

LANG='en_US.UTF-8'

Verwenden der benutzerdefinierten Zertifizierungsstelle

Weblate prüft SSL-Zertifikate bei HTTP-Anfragen. Wenn Sie eine benutzerdefinierte Zertifizierungsstelle verwenden, der in den Standardpaketen nicht vertraut wird, müssen Sie ihr Zertifikat als vertrauenswürdig hinzufügen.

Der bevorzugte Ansatz ist, dies auf Systemebene zu tun. Bitte lesen Sie die Dokumentation Ihrer Distribution für weitere Details (unter Debian kann dies zum Beispiel durch das Ablegen des CA-Zertifikats in /usr/local/share/ca-certificates/ und dem Ausführen von update-ca-certificates geschehen).

Sobald dies geschehen ist, vertrauen die Systemprogramme dem Zertifikat, so auch Git.

Für Python-Code müssen Sie die Anfragen so konfigurieren, dass das System-CA-Bundle anstelle des mitgelieferten Pakets verwendet wird. Dies kann erreicht werden, indem der folgende Ausschnitt in settings.py eingefügt wird (der Pfad ist Debian-spezifisch):

import os

os.environ["REQUESTS_CA_BUNDLE"] = "/etc/ssl/certs/ca-certificates.crt"

Client-Assets komprimieren

Weblate wird mit einer Reihe von JavaScript- und CSS-Dateien geliefert. Aus Leistungsgründen ist es sinnvoll, diese vor dem Senden an einen Client zu komprimieren. In der Standardkonfiguration wird dies im laufenden Betrieb auf Kosten eines geringen Overheads durchgeführt. Bei großen Installationen empfiehlt es sich, den Offline-Komprimierungsmodus zu aktivieren. Dies muss in der Konfiguration vorgenommen werden, und die Komprimierung muss bei jeder Aktualisierung von Weblate ausgelöst werden.

Der Konfigurationswechsel ist einfach, indem man django.conf.settings.COMPRESS_OFFLINE aktiviert und django.conf.settings.COMPRESS_OFFLINE_CONTEXT konfiguriert (letzteres ist bereits in der Beispielkonfiguration enthalten):

COMPRESS_OFFLINE = True

Bei jeder Bereitstellung müssen Sie die Dateien komprimieren, damit sie der aktuellen Version entsprechen:

weblate compress

Hinweis

Im offiziellen Docker-Image ist diese Funktion bereits aktiviert.

Siehe auch

Common Deployment Scenarios, Bereitstellung statischer Dateien

Laufender Server

Hinweis

Falls Sie keine Erfahrung mit den unten beschriebenen Diensten haben, sollten Sie Installation über Docker ausprobieren.

Sie benötigen mehrere Dienste, um Weblate auszuführen, die empfohlene Einrichtung besteht aus:

Datenbankserver (siehe Datenbankeinrichtung für Weblate)
Cache-Server (siehe Caching einschalten)
Frontend-Webserver für statische Dateien und SSL-Terminierung (siehe Bereitstellung statischer Dateien)
WSGI-Server für dynamische Inhalte (siehe Beispielkonfiguration für NGINX und uWSGI)
Celery für die Ausführung von Hintergrundaufgaben (siehe Hintergrundaufgaben mit Celery)

Bemerkung

Es gibt einige Abhängigkeiten zwischen den Diensten, zum Beispiel sollten Cache und Datenbank beim Starten von Celery- oder uwsgi-Prozessen bereits laufen.

In den meisten Fällen werden Sie alle Dienste auf einem einzigen (virtuellen) Server laufen lassen, aber wenn Ihre Installation stark ausgelastet ist, können Sie die Dienste aufteilen. Die einzige Einschränkung dabei ist, dass Celery- und Wsgi-Server Zugriff auf DATA_DIR benötigen.

Bemerkung

Der WSGI-Prozess muss unter demselben Benutzer wie der Celery-Prozess ausgeführt werden, sonst werden die Dateien im DATA_DIR mit unterschiedlichen Besitzverhältnissen gespeichert, was zu Laufzeitproblemen führt.

Siehe auch Dateisystemberechtigungen und Hintergrundaufgaben mit Celery.

Webserver ausführen

Die Ausführung von Weblate unterscheidet sich nicht von der Ausführung anderer Django-basierter Programme. Django wird normalerweise als uWSGI oder fcgi ausgeführt (siehe Beispiele für verschiedene Webserver unten).

Zu Testzwecken können Sie den in Django integrierten Webserver verwenden:

weblate runserver

Warnung

VERWENDEN SIE DIESEN SERVER NICHT IN EINER PRODUKTIONSUMGEBUNG. Er hat keine Sicherheits- oder Leistungstests durchlaufen. Siehe auch Django-Dokumentation zu runserver.

Hinweis

Der integrierte Django-Server stellt statische Dateien nur mit aktiviertem DEBUG bereit, da er nur für die Entwicklung gedacht ist. Für den produktiven Einsatz siehe die wsgi-Einstellungen in Beispielkonfiguration für NGINX und uWSGI, Beispielkonfiguration für Apache, Beispielkonfiguration für Apache und Gunicorn und Bereitstellung statischer Dateien.

Bereitstellung statischer Dateien

Geändert in Version 2.4: Vor der Version 2.4 nutzte Weblate das Django-Framework für statische Dateien nicht richtig und die Einrichtung war komplexer.

Django muss seine statischen Dateien in einem einzigen Verzeichnis sammeln. Um dies zu tun, führen Sie weblate collectstatic --noinput aus. Dadurch werden die statischen Dateien in ein Verzeichnis kopiert, das durch die Einstellung STATIC_ROOT festgelegt ist (dies ist standardmäßig ein static Verzeichnis innerhalb von DATA_DIR).

Es wird empfohlen, statische Dateien direkt von Ihrem Webserver bereitzustellen, was Sie für die folgenden Pfade verwenden sollten:

/static/: Stellt statische Dateien für Weblate und das Admin-Interface bereit (definiert durch STATIC_ROOT).
/media/: Wird für Medien-Uploads durch Benutzer (z. B. Bildschirmfotos) verwendet.
/favicon.ico: Sollte umgeschrieben werden, um eine Regel zur Bereitstellung von /static/favicon.ico umzuschreiben.

Siehe auch

Beispielkonfiguration für NGINX und uWSGI, Beispielkonfiguration für Apache, Beispielkonfiguration für Apache und Gunicorn, Client-Assets komprimieren, How to deploy Django, How to deploy static files

Richtlinie zur Inhaltssicherheit

Die Standardkonfiguration von Weblate aktiviert die Middleware weblate.middleware.SecurityMiddleware, die sicherheitsbezogene HTTP-Header wie Content-Security-Policy oder X-XSS-Protection setzt. Diese sind standardmäßig so eingerichtet, dass sie mit Weblate und seiner Konfiguration zusammenarbeiten, aber dies muss möglicherweise an Ihre Umgebung angepasst werden.

Siehe auch

CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC

Beispielkonfiguration für NGINX und uWSGI

Um einen produktiven Webserver zu betreiben, verwenden Sie den mit Weblate installierten wsgi-Wrapper (in der virtuellen Umgebung wird er als ~/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py installiert). Vergessen Sie nicht, auch den Python-Suchpfad in Ihrer virtuellen Umgebung zu setzen (zum Beispiel mit virtualenv = /home/user/weblate-env in uWSGI).

In der folgenden Konfiguration wird Weblate als uWSGI unter dem NGINX-Webserver ausgeführt.

Konfiguration für NGINX (auch verfügbar als weblate/examples/weblate.nginx.conf):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
server {
    listen 80;
    server_name weblate;
    # Not used
    root /var/www/html;

    location ~ ^/favicon.ico$ {
        # DATA_DIR/static/favicon.ico
        alias /home/weblate/data/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # DATA_DIR/static/
        alias /home/weblate/data/static/;
        expires 30d;
    }

    location /media/ {
        # DATA_DIR/media/
        alias /home/weblate/data/media/;
        expires 30d;
    }

    location / {
        include uwsgi_params;
        # Needed for long running operations in admin interface
        uwsgi_read_timeout 3600;
        # Adjust based to uwsgi configuration:
        uwsgi_pass unix:///run/uwsgi/app/weblate/socket;
        # uwsgi_pass 127.0.0.1:8080;
    }
}

Konfiguration für uWSGI (auch verfügbar als weblate/examples/weblate.uwsgi.ini):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
[uwsgi]
plugins       = python3
master        = true
protocol      = uwsgi
socket        = 127.0.0.1:8080
wsgi-file     = /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py

# Add path to Weblate checkout if you did not install
# Weblate by pip
# python-path   = /path/to/weblate

# In case you're using virtualenv uncomment this:
virtualenv = /home/weblate/weblate-env

# Needed for OAuth/OpenID
buffer-size   = 8192

# Reload when consuming too much of memory
reload-on-rss = 250

# Increase number of workers for heavily loaded sites
workers       = 8

# Enable threads for Sentry error submission
enable-threads = true

# Child processes do not need file descriptors
close-on-exec = true

# Avoid default 0000 umask
umask = 0022

# Run as weblate user
uid = weblate
gid = weblate

# Enable harakiri mode (kill requests after some time)
# harakiri = 3600
# harakiri-verbose = true

# Enable uWSGI stats server
# stats = :1717
# stats-http = true

# Do not log some errors caused by client disconnects
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

Siehe auch

How to use Django with uWSGI

Beispielkonfiguration für Apache

Es wird empfohlen, prefork MPM zu verwenden, wenn WSGI mit Weblate genutzt wird.

Die folgende Konfiguration lässt Weblate als WSGI laufen, Sie müssen mod_wsgi aktiviert haben (verfügbar als weblate/examples/apache.conf):

#
# VirtualHost for Weblate
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias / /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Bemerkung

Weblate erfordert Python 3, also stellen Sie bitte sicher, dass Sie die Python 3-Variante des modwsgi verwenden. Normalerweise ist es als separates Paket verfügbar, zum Beispiel libapache2-mod-wsgi-py3.

Siehe auch

System-Sprachumgebungen und -Kodierung, How to use Django with Apache and mod_wsgi

Beispielkonfiguration für Apache und Gunicorn

Die folgende Konfiguration führt Weblate in Gunicorn und Apache 2.4 aus (verfügbar als weblate/examples/apache.gunicorn.conf):

#
# VirtualHost for Weblate using gunicorn on localhost:8000
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/https_cert.cert
    SSLCertificateKeyFile /etc/apache2/ssl/https_key.pem
    SSLProxyEngine On

    ProxyPass /favicon.ico !
    ProxyPass /static/ !
    ProxyPass /media/ !

    ProxyPass / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

Siehe auch

How to use Django with Gunicorn

Weblate unter Pfad ausführen

Neu in Version 1.3.

Es wird empfohlen, prefork MPM zu verwenden, wenn WSGI mit Weblate genutzt wird.

Eine beispielhafte Apache-Konfiguration für die Bereitstellung von Weblate unter /weblate. Wiederum unter mod_wsgi (auch verfügbar als weblate/examples/apache-path.conf):

#
# VirtualHost for Weblate, running under /weblate path
#
# You will want to change:
#
# - ServerAdmin and ServerName
# - change /home/weblate/weblate-env to location where Weblate virtualenv is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.9 to match your Python version
# - change weblate user to match your Weblate user
#
<VirtualHost *:80>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # DATA_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/static/favicon.ico

    # DATA_DIR/static/
    Alias /weblate/static/ /home/weblate/data/static/
    <Directory /home/weblate/data/static/>
        Require all granted
    </Directory>

    # DATA_DIR/media/
    Alias /weblate/media/ /home/weblate/data/media/
    <Directory /home/weblate/data/media/>
        Require all granted
    </Directory>

    # Path to your Weblate virtualenv
    WSGIDaemonProcess weblate python-home=/home/weblate/weblate-env user=weblate request-timeout=600
    WSGIProcessGroup weblate
    WSGIApplicationGroup %{GLOBAL}

    WSGIScriptAlias /weblate /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.9/site-packages/weblate/>
        <Files wsgi.py>
        Require all granted
        </Files>
    </Directory>

</VirtualHost>

Zusätzlich müssen Sie weblate/settings.py anpassen:

URL_PREFIX = "/weblate"

Hintergrundaufgaben mit Celery

Neu in Version 3.2.

Weblate verwendet Celery, um regelmäßige Aufgaben und Hintergrundaufgaben auszuführen. Sie sollten einen Celery-Dienst laufen lassen, der diese ausführt. Er ist zum Beispiel für die folgenden Vorgänge zuständig (diese Liste ist nicht vollständig):

Empfang von Webhooks von externen Diensten (siehe Benachrichtigungs-Hooks).
Durchführung regelmäßiger Wartungsaufgaben wie Sicherungen, Bereinigungen, tägliche Erweiterungen oder Aktualisierungen (siehe Sichern und Verschieben von Weblate, BACKGROUND_TASKS, Erweiterungen).
Ausführung von Automatische Übersetzung.
Zusammenfassungs-Benachrichtigungen senden.
Auslagerung kostspieliger Operationen aus dem wsgi-Prozess.
Übergabe ausstehender Änderungen (siehe Lazy Commits).

Eine typische Einrichtung mit Redis als Backend sieht wie folgt aus:

CELERY_TASK_ALWAYS_EAGER = False
CELERY_BROKER_URL = "redis://localhost:6379"
CELERY_RESULT_BACKEND = CELERY_BROKER_URL

Siehe auch

Redis-Broker-Konfiguration in Celery

Sie sollten auch den Celery-Worker starten, um die Aufgaben zu verarbeiten und geplante Aufgaben zu starten. Dies kann direkt auf der Befehlszeile erfolgen (was vor allem beim Debuggen oder Entwickeln nützlich ist):

./weblate/examples/celery start
./weblate/examples/celery stop

Bemerkung

Der Celery-Prozess muss unter demselben Benutzer wie der WSGI-Prozess ausgeführt werden, sonst werden die Dateien im DATA_DIR mit unterschiedlichen Besitzverhältnissen gespeichert, was zu Laufzeitproblemen führt.

Siehe auch Dateisystemberechtigungen und Hintergrundaufgaben mit Celery.

Ausführung von Celery-Aufgaben in der wsgi unter Verwendung des Eager-Modus

Bemerkung

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, Zusammenfassungs-Benachrichtigungen oder Backups).

Für Entwicklungszwecke möchten Sie vielleicht eine Eager-Konfiguration verwenden, die alle Aufgaben an Ort und Stelle verarbeitet:

CELERY_TASK_ALWAYS_EAGER = True
CELERY_BROKER_URL = "memory://"
CELERY_TASK_EAGER_PROPAGATES = True

Celery als Systemdienst ausführen

Höchstwahrscheinlich werden Sie Celery als Daemon laufen lassen wollen, und das wird in Daemonization behandelt. Für die gebräuchlichste Linux-Konfiguration mit systemd können Sie die Beispieldateien verwenden, die, wie im Ordner examples unten aufgelistet, geliefert werden.

Die Systemd-Unit muss als /etc/systemd/system/celery-weblate.service abgelegt werden:

[Unit]
Description=Celery Service (Weblate)
After=network.target

[Service]
Type=forking
User=weblate
Group=weblate
EnvironmentFile=/etc/default/celery-weblate
WorkingDirectory=/home/weblate
RuntimeDirectory=celery
RuntimeDirectoryPreserve=restart
LogsDirectory=celery
ExecStart=/bin/sh -c '${CELERY_BIN} multi start ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'
ExecStop=/bin/sh -c '${CELERY_BIN} multi stopwait ${CELERYD_NODES} \
  --pidfile=${CELERYD_PID_FILE}'
ExecReload=/bin/sh -c '${CELERY_BIN} multi restart ${CELERYD_NODES} \
  -A ${CELERY_APP} --pidfile=${CELERYD_PID_FILE} \
  --logfile=${CELERYD_LOG_FILE} --loglevel=${CELERYD_LOG_LEVEL} ${CELERYD_OPTS}'

[Install]
WantedBy=multi-user.target

Umgebungskonfiguration als :file:`/etc/default/celery-weblate`abzulegen:

# Name of nodes to start
CELERYD_NODES="celery notify memory backup translate"

# Absolute or relative path to the 'celery' command:
CELERY_BIN="/home/weblate/weblate-env/bin/celery"

# App instance to use
# comment out this line if you don't use an app
CELERY_APP="weblate.utils"

# Extra command-line arguments to the worker,
# increase concurrency if you get weblate.E019
CELERYD_OPTS="--beat:celery --queues:celery=celery --prefetch-multiplier:celery=4 \
    --queues:notify=notify --prefetch-multiplier:notify=10 \
    --queues:memory=memory --prefetch-multiplier:memory=10 \
    --queues:translate=translate --prefetch-multiplier:translate=4 \
    --concurrency:backup=1 --queues:backup=backup  --prefetch-multiplier:backup=2"

# Logging configuration
# - %n will be replaced with the first part of the nodename.
# - %I will be replaced with the current child process index
#   and is important when using the prefork pool to avoid race conditions.
CELERYD_PID_FILE="/run/celery/weblate-%n.pid"
CELERYD_LOG_FILE="/var/log/celery/weblate-%n%I.log"
CELERYD_LOG_LEVEL="INFO"

Zusätzliche Konfiguration für die Rotation der Celery-Logs mit logrotate, die als /etc/logrotate.d/celery abgelegt wird:

/var/log/celery/*.log {
        weekly
        missingok
        rotate 12
        compress
        notifempty
}

Regelmäßige Aufgaben mit Celery Beat

Weblate wird mit integrierten Einstellungen für geplante Aufgaben geliefert. Sie können jedoch zusätzliche Aufgaben in settings.py definieren, siehe zum Beispiel Lazy Commits.

Die Aufgaben sollen vom Celery-Beats-Daemon ausgeführt werden. Wenn er nicht richtig funktioniert, läuft er möglicherweise nicht oder seine Datenbank wurde beschädigt. Überprüfen Sie in einem solchen Fall die Startprotokolle von Celery, um die Ursache herauszufinden.

Celery-Status überwachen

Sie können die aktuelle Länge der Celery-Aufgabenwarteschlangen im Verwaltungsoberfläche finden oder Sie können celery_queues auf der Kommandozeile verwenden. Falls die Warteschlange zu lang wird, erhalten Sie auch einen Konfigurationsfehler in der Verwaltungsoberfläche.

Warnung

Die Celery-Fehler werden standardmäßig nur im Celery-Log protokolliert und sind für den Benutzer nicht sichtbar. Falls Sie einen Überblick über solche Fehler haben möchten, wird empfohlen, Sammeln von Fehlerberichten zu konfigurieren.

Siehe auch

Weblate überwachen, Wie überprüft man ob Weblate richtig eingerichtet ist?, Configuration and defaults, Workers Guide, Daemonization, Monitoring and Management Guide, celery_queues

Weblate überwachen

Weblate stellt die URL /healthz/ zur Verfügung, die für einfache Gesundheitsprüfungen verwendet werden kann, zum Beispiel mit Kubernetes. Der Docker-Container verfügt über integrierte Gesundheitsprüfungen, die diese URL verwenden.

Zur Überwachung der Metriken von Weblate können Sie den GET /api/metrics/ API-Endpunkt verwenden.

Siehe auch

Wie überprüft man ob Weblate richtig eingerichtet ist?, Celery-Status überwachen,`Weblate-Plugin für Munin <https://github.com/WeblateOrg/munin>`_

Sammeln von Fehlerberichten

Weblate kann, wie jede andere Software auch, ausfallen. Um nützliche Fehlermeldungen zu sammeln, empfehlen wir die Nutzung von Diensten Dritter, um solche Informationen zu sammeln. Dies ist besonders nützlich bei fehlgeschlagenen Celery-Aufgaben, die sonst nur Fehler in den Logs melden würden und über die Sie nicht benachrichtigt werden. Weblate bietet Unterstützung für die folgenden Dienste:

Sentry

Weblate hat integrierte Unterstützung für Sentry. Um sie zu nutzen, genügt es, SENTRY_DSN in der settings.py zu setzen:

SENTRY_DSN = "https://id@your.sentry.example.com/"

Rollbar

Weblate hat integrierte Unterstützung für Rollbar. Um sie zu nutzen, genügt es, den Anweisungen für Rollbar-Notifier für Python zu folgen.

Kurz gesagt, Sie müssen settings.py anpassen:

# Add rollbar as last middleware:
MIDDLEWARE = [
    # … other middleware classes …
    "rollbar.contrib.django.middleware.RollbarNotifierMiddleware",
]

# Configure client access
ROLLBAR = {
    "access_token": "POST_SERVER_ITEM_ACCESS_TOKEN",
    "client_token": "POST_CLIENT_ITEM_ACCESS_TOKEN",
    "environment": "development" if DEBUG else "production",
    "branch": "main",
    "root": "/absolute/path/to/code/root",
}

Alles andere wird automatisch integriert, Sie werden jetzt sowohl server- als auch clientseitige Fehler sammeln.

Migration von Weblate auf einen anderen Server

Die Migration von Weblate auf einen anderen Server sollte ziemlich einfach sein, es speichert jedoch Daten an wenigen Orten, die Sie sorgfältig migrieren sollten. Der beste Ansatz ist, Weblate für die Migration zu stoppen.

Migration der Datenbank

Abhängig von Ihrem Datenbank-Backend haben Sie mehrere Möglichkeiten, die Datenbank zu migrieren. Der einfachste Ansatz ist die Verwendung datenbankeigener Tools, da diese normalerweise am effektivsten sind (z. B. mysqldump oder pg_dump). Alternativ können Sie auch die Replikation verwenden, falls Ihre Datenbank dies unterstützt.

Siehe auch

Migration zwischen Datenbanken, beschrieben in Migration von anderen Datenbanken zu PostgreSQL.

Migration der VCS-Repositorys

Die VCS-Repositorys, die unter DATA_DIR gespeichert sind, müssen ebenfalls migriert werden. Sie können sie einfach kopieren oder rsync verwenden, um die Migration effektiver durchzuführen.

Sonstige Anmerkungen

Vergessen Sie nicht, andere Dienste zu verschieben, die Weblate möglicherweise verwendet hat, wie Redis, Cron-Jobs oder benutzerdefinierte Authentifizierungs-Backends.