Konfigurationsanweisungen

Weblate installieren

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

Architekturübersicht

digraph architecture { graph [fontname="sans-serif", fontsize=10, newrank=true, rankdir=LR, splines=ortho ]; node [fontname="sans-serif", fontsize=10, height=0, margin=.15, shape=box ]; edge [fontname="sans-serif", fontsize=10 ]; subgraph cluster_thirdparty { graph [color=lightgrey, label="Third-party services", style=filled ]; mt [label="Machine translation", style=dotted]; sentry [label="Sentry\nError collection", style=dotted]; graylog [label="Graylog\nLog collection", style=dotted]; mail [label="E-mail server"]; auth [label="SSO\nAuthentication provider", style=dotted]; } subgraph cluster_ingress { graph [color=lightgrey, label=Ingress, style=filled ]; web [label="Web server", shape=hexagon]; } subgraph cluster_weblate { graph [color=lightgrey, label="Weblate code-base", style=filled ]; celery [fillcolor="#144d3f", fontcolor=white, label="Celery workers", style=filled]; wsgi [fillcolor="#144d3f", fontcolor=white, label="WSGI server", style=filled]; } subgraph cluster_services { graph [color=lightgrey, label=Services, style=filled ]; redis [label="Datastore\nTask queue\nCache", shape=cylinder]; db [label="PostgreSQL\nDatabase", shape=cylinder]; fs [label=Filesystem, shape=cylinder]; } web -> wsgi; web -> fs; celery -> mt [style=dotted]; celery -> sentry [style=dotted]; celery -> graylog [style=dotted]; celery -> mail; celery -> redis; celery -> db; celery -> fs; wsgi -> mt [style=dotted]; wsgi -> sentry [style=dotted]; wsgi -> graylog [style=dotted]; wsgi -> auth [style=dotted]; wsgi -> redis; wsgi -> db; wsgi -> fs; }

Webserver

Verarbeitung eingehender HTTP-Anfragen, Statische Dateien bereitstellen.

Celery-Worker

Hintergrundaufgaben mit Celery werden hier ausgeführt.

Je nach Auslastung möchten Sie möglicherweise die Anzahl der Worker anpassen.

Verwenden Sie einen dedizierten Knoten, wenn Sie Weblate horizontal skalieren.

WSGI-Server

Ein WSGI-Server, der Benutzern Webseiten bereitstellt.

Verwenden Sie einen dedizierten Knoten, wenn Sie Weblate horizontal skalieren.

Datenbank

PostgreSQL-Datenbankserver zum Speichern aller Inhalte, siehe Datenbankeinrichtung für Weblate.

Verwenden Sie einen dedizierten Datenbankknoten für Websites mit Hunderten Millionen gehosteter Wörter.

Datenspeicher

Schlüssel-Werte-Datenspeicher wie Valkey oder Redis-Server für Cache und Aufgabenwarteschlange, siehe Hintergrundaufgaben mit Celery.

Verwenden Sie einen dedizierten Knoten, wenn Sie Weblate horizontal skalieren.

Dateisystem

Dateisystemspeicher zum Speichern von VCS-Repositorys und hochgeladenen Benutzerdaten. Dieser wird von allen Prozessen gemeinsam genutzt.

Verwenden Sie einen Netzwerkspeicher, wenn Sie Weblate horizontal skalieren.

E-Mail-Server

SMTP-Server für ausgehende E-Mails, siehe Ausgehende E-Mails konfigurieren. Er kann extern bereitgestellt werden.

Hinweis

Installation über Docker enthält PostgreSQL und Valkey, was die Installation erleichtert.

Softwareanforderungen

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.

Siehe auch

Architekturübersicht beschreibt die allgemeine Weblate-Architektur und die erforderlichen Dienste.

Python-Abhängigkeiten

Weblate ist in Python geschrieben und unterstützt Python 3.12 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

Bezeichner der optionalen Abhängigkeiten

Python-Pakete

Weblate-Funktion

amazon
boto3

Amazon Translate

gelf
logging-gelf

Graylog-Protokollverwaltung

gerrit
git-review

Gerrit review requests

google
google-cloud-storage
google-cloud-translate

Google Cloud Translation Advanced mit Glossarunterstützung

ldap
django-auth-ldap

LDAP-Authentifizierung

mercurial
mercurial

Mercurial

postgres
psycopg

PostgreSQL, siehe Datenbankeinrichtung für Weblate

rollbar
rollbar

Fehlerberichte sammeln und Leistung überwachen

saml
python3-saml

SAML-Authentifizierung

saml2idp
djangosaml2idp2

Integration von SAML 2 IDP in Weblate

sphinx
Sphinx

Erforderlich für POT-Datei aktualisieren (Sphinx)

wllegal
wllegal

Hosted-Weblate-Integration

wsgi
granian

WSGI-Server für Weblate

zxcvbn
django-zxcvbn-password-validator

Passwort-Authentifizierung

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

uv pip install "weblate[Postgres,Amazon,SAML]"

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

uv pip install "weblate[all]"

Oder Sie können Weblate ohne optionale Funktionen installieren:

uv pip install weblate

Fehlerbehebung bei pip install

ERROR: Dependency 'gobject-introspection-2.0' is required but not found.

Das installierte PyGobject Paket kann keine passende GObject-Introspection-Bibliothek finden – gobject-introspection-2.0.

Ältere Versionen werden von Weblate nicht mehr unterstützt.

ffi_prep_closure(): bad user_data (it seems that the version of the libffi library seen at runtime is different from the 'ffi.h' file seen at compile-time)

Dies wird durch die Inkompatibilität von Binärpaketen verursacht, die über PyPI mit der Distribution verteilt werden. Um dies zu beheben, müssen Sie das Paket auf Ihrem System neu erstellen:

uv pip install --force-reinstall --no-binary :all: cffi
error: ‘xmlSecKeyDataFormatEngine’ undeclared (first use in this function); did you mean ‘xmlSecKeyDataFormat’?

Dies ist ein bekanntes Problem des xmlsec-Pakets, siehe https://github.com/xmlsec/python-xmlsec/issues/314.

lxml & xmlsec libxml2 library version mismatch

Die Pakete lxml und xmlsec müssen mit libxml2 gebaut werden. Um dieses Problem zu vermeiden, sollten Sie sie lokal erstellen:

uv pip install --force-reinstall --no-binary xmlsec --no-binary lxml lxml xmlsec

Weitere Systemvoraussetzungen

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://www.gtk.org/docs/architecture/pango, siehe Pango und Kairo

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 (nur erforderlich, wenn keine Binary-Wheels von tesserocr für das System verfügbar sind)

https://github.com/tesseract-ocr/tesseract

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 berücksichtigen Sie bitte die Dokumentation der einzelnen Pakete. Diese werden nicht benötigt, wenn Sie das vorgefertigte Wheels beim Installieren von pip verwenden oder wenn Sie Distributionspakete verwenden.

Pango und Kairo

Weblate verwendet Pango und Cairo für die Darstellung von Bitmap-Widgets (siehe Die Übersetzungscommunity aufbauen) 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.

Siehe auch

Hardwareanforderungen

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

  • 3 GB Arbeitsspeicher

  • 2 CPU-Kerne

  • 1 GB Speicherplatz

Bemerkung

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

RAM-Auslastung

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

Hinweis

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

CPU-Auslastung

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

Speichernutzung

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

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

Knoten

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

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

Veröffentlichungssignaturen überprüfen

Weblate-Versionen sind kryptografisch signiert mit Sigstore-Signaturen. Die Signaturen sind der GitHub-Veröffentlichung beigefügt.

Die Verifizierung kann mit dem Sigstore-Paket durchgeführt werden. Das folgende Beispiel verifiziert die Signatur der Version 5.4:

sigstore verify github \
   --cert-identity https://github.com/WeblateOrg/weblate/.github/workflows/setup.yml@refs/tags/weblate-5.4 \
   --bundle Weblate-5.4-py3-none-any.whl.sigstore \
   Weblate-5.4-py3-none-any.whl

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.

The configured CACHE_DIR also has to be writable by the Weblate process and has to allow executing generated helper files. Do not mount CACHE_DIR with the noexec option.

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

Statische Dateien bereitstellen

Datenbankeinrichtung für Weblate

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

PostgreSQL 13 und höher wird unterstützt. PostgreSQL 15 oder neuer wird empfohlen.

Siehe auch

Datenbankverbindungen

In der Standardkonfiguration behält jeder Weblate-Prozess eine dauerhafte Verbindung zur Datenbank bei. Dauerhafte Verbindungen verbessern die Reaktionsfähigkeit von Weblate, erfordern jedoch möglicherweise mehr Ressourcen für den Datenbankserver. Bitte lesen Sie CONN_MAX_AGE und Persistent connections für weitere Informationen.

Weblate benötigt mindestens die folgende Anzahl an Verbindungen:

  • \((4 \times \mathit{nCPUs}) + 2\) für Celery-Prozesse

  • \(\mathit{nCPUs} + 1\) für WSGI-Worker

Dies gilt für die Docker-Container-Standardwerte und die Beispielkonfigurationen in dieser Dokumentation, jedoch werden sich die Zahlen ändern, wenn Sie die Anzahl der WSGI-Worker anpassen oder die Parallelität von Celery einstellen.

Der tatsächliche Grenzwert für die Anzahl der Datenbankverbindungen muss höher sein, um folgende Situationen zu berücksichtigen:

  • Verwaltungsbefehle benötigen ebenfalls ihre Verbindung.

  • Wenn ein Case-Prozess beendet wird (z. B. durch einen OOM-Killer), kann er die bestehende Verbindung bis zur Zeitüberschreitung blockieren.

Siehe auch

Hintergrundaufgaben mit Celery, Beispielkonfiguration für NGINX und uWSGI, WEBLATE_WORKERS

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

Eine Datenbank in PostgreSQL erstellen

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;
CREATE EXTENSION IF NOT EXISTS btree_gin;

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",
        # Configures name of the PostgreSQL role to alter during the database migration
        # "ALTER_ROLE": "weblate",
        # Database password
        "PASSWORD": "password",
        # Set to empty string for localhost
        "HOST": "database.example.com",
        # Set to empty string for default
        "PORT": "",
        # Persistent connections
        "CONN_MAX_AGE": None,
        "CONN_HEALTH_CHECKS": True,
    }
}

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 Einrichtungen weicht der Rollenname vom Benutzernamen ab und Sie erhalten während der Datenbankmigration eine Fehlermeldung über eine nicht vorhandene Rolle (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 Einsatzumgebung beschränkt. Bitte setzen Sie ALTER_ROLE, um den Namen der Rolle zu ändern, die Weblate während der Datenbankmigration ändern soll.

Siehe auch

Datenbankverbindungen

Andere Konfigurationen

Ausgehende E-Mails konfigurieren

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.

Die Mailserver-Einrichtung 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

Hinter einem Reverse-Proxy ausführen

Mehrere Funktionen in Weblate sind davon abhängig, dass korrekte HTTP-Header an Weblate übergeben werden. Wenn Sie einen Reverse-Proxy verwenden, stellen Sie bitte sicher, dass die benötigten Informationen korrekt übermittelt werden.

Um diese Konfiguration zu debuggen, können Sie sich HTTP-Umgebung in Leistungsbericht ansehen.

Client-IP-Adresse

Dies wird für Ratenbegrenzung oder Auditprotokoll benötigt.

Weblate analysiert die IP-Adresse von REMOTE_ADDR, die vom WSGI-Handler gesetzt wird. Diese kann leer sein (bei Verwendung von Socket für WSGI) oder eine Reverse-Proxy-Adresse enthalten, so dass Weblate einen zusätzlichen HTTP-Header mit der IP-Adresse des Clients benötigt.

Das Aktivieren von IP_BEHIND_REVERSE_PROXY sollte für die meisten üblichen Einrichtungen ausreichen, aber es muss möglicherweise auch IP_PROXY_HEADER und IP_PROXY_OFFSET angepasst werden (WEBLATE_IP_PROXY_HEADER und WEBLATE_IP_PROXY_OFFSET im Docker-Container verwenden).

Hinweis

Diese Konfiguration kann nicht standardmäßig aktiviert werden, da sie das Vortäuschen von IP-Adressen auf Installationen ermöglichen würde, die keinen ordnungsgemäß konfigurierten Reverse-Proxy haben.

Server-Hostname

Der Host-Header 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).

Hinweis

Fehler bei der CSRF-Verifizierung werden häufig durch eine Nichtübereinstimmung zwischen dem Host -Header und dem konfigurierten SITE_DOMAIN verursacht.

Client-Protokoll

Wenn nicht das richtige Protokoll übergeben wird, kann Weblate beim Versuch, den Client auf HTTPS umzustellen, in einer Weiterleitungssschleife steckenbleiben. Vergewissern Sie sich, dass der Reverse-Proxy das Protokoll korrekt als X-Forwarded-Proto bereitstellt.

Dieser Header muss dann in SECURE_PROXY_SSL_HEADER (settings.py) oder WEBLATE_SECURE_PROXY_SSL_HEADER (Docker-Umgebung) konfiguriert werden.

Wichtig

In der Konfiguration wird zwischen Groß- und Kleinschreibung unterschieden, so dass WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,https und WEBLATE_SECURE_PROXY_SSL_HEADER=HTTP_X_FORWARDED_PROTO,HTTPS nicht austauschbar sind.

Hinweis

Wenn Sie die Fehlermeldung „Too many redirects“ (zu viele Weiterleitungen) vom Browser erhalten, liegt dies höchstwahrscheinlich an einer Diskrepanz zwischen dem tatsächlichen Protokoll (HTTPS) und dem von Weblate beobachteten Protokoll.

Geändert in Version 5.13: Die Protokoll-Proxy-Header werden in der Standardkonfiguration automatisch von gunicorn verarbeitet, aber andere WSGI-Server haben eine sicherere Konfiguration und erfordern eine explizite Einstellung dieses Parameters.

Seit Weblate 5.13 verwendet der Docker-Container granian und erfordert nun die explizite Konfiguration von WEBLATE_SECURE_PROXY_SSL_HEADER.

Siehe auch

HTTP-Proxy

Weblate führt VCS-Befehle aus und diese akzeptieren die Proxy-Konfiguration aus der Einsatzumgebung. 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

Konfiguration anpassen

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.

Das Kontaktformular sendet auch an diese eine E-Mail, es sei denn, ADMINS_CONTACT ist konfiguriert.

Siehe auch

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

SESSION_ENGINE

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

Wenn Sie Valkey oder Redis als Cache verwenden (siehe Cache konfigurieren), empfiehlt es sich, diesen auch für Sitzungen zu verwenden:

SESSION_ENGINE = "django.contrib.sessions.backends.cache"

Siehe auch

DATABASES

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

Siehe auch

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 Weblate auch, da Django in diesem Fall intern viel mehr Informationen speichert.

Siehe auch

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

Die Datenbank füllen

Nachdem Ihre Konfiguration fertig ist, können Sie migrate ausführen, um die Datenbankstruktur zu erstellen. Nun sollten Sie in der Lage sein, Übersetzungsprojekte über die Adminoberfläche zu 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

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:

../_images/admin-wrench.webp

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 unter Leistungsbericht in der Verwaltungsoberfläche überprüfen.

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

Konfiguration anpassen

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

Konfiguration anpassen

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

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

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

Cache konfigurieren

Wenn möglich, verwenden Sie Valkey oder 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 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

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

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

Zulässige Hosts einrichten

Django benötigt ALLOWED_HOSTS, um eine Liste von Domainnamen 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

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 der Beispieleinrichtung zu verwenden.

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

Siehe auch

SECRET_KEY

Wartungsaufgaben ausführen

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

  • Konfigurationsintegritätsprüfung (stündlich).

  • Committen ausstehender Änderungen (stündlich), siehe Lazy Commits und commit_pending.

  • Aktualisieren von Komponentenwarnungen (täglich).

  • Remote-Branches aktualisieren (nachts), siehe AUTO_UPDATE.

  • Übersetzungsspeicher-Sicherung in JSON (täglich), siehe dump_memory.

  • Volltext- und Datenbankwartungsaufgaben (tägliche und wöchentliche Aufgaben), siehe cleanuptrans.

System-Sprachumgebungen und -Codierung

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'

Eigene Zertifizierungsstelle verwenden

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

Hinweis

Der Weblate-Container nimmt das nicht in den Suchpfad auf, Sie müssen den vollständigen Pfad angeben, um ihn auszuführen. Zum Beispiel:

docker compose exec -u root weblate /usr/sbin/update-ca-certificates

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

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:

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

Das Ausführen von Weblate unterscheidet sich nicht von anderen Django-basierten Programmen. Django wird normalerweise als WSGI oder fcgi ausgeführt (siehe Beispiele für verschiedene Webserver unten).

Bemerkung

The sample configuration files shown below are maintained in the Weblate source tree under weblate/examples/. They are included in source distributions and in this documentation, but Python wheels only install runtime files. When installing Weblate from PyPI, get the matching source distribution or source checkout before copying these examples.

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 beachten Sie bitte die WSGI-Einstellungen:

Statische Dateien bereitstellen

Geändert in Version 5.15.2: /media/ wird nicht mehr für das Bereitstellen von Bildschirmfotos verwendet.

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 CACHE_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 die Adminoberfläche bereit (definiert durch STATIC_ROOT).

/favicon.ico

Sollte umgeschrieben werden, um eine Regel zur Bereitstellung von /static/favicon.ico umzuschreiben.

Siehe auch

Richtlinie zur Inhaltssicherheit

In der Standardkonfiguration von Weblate ist die Middleware weblate.middleware.SecurityMiddleware aktiviert, die sicherheitsrelevante 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, müssen aber möglicherweise für Ihre Einsatzumgebung angepasst werden.

Siehe auch

Beispielkonfiguration für NGINX und Granian

Die folgende Konfiguration führt Weblate mit dem NGINX-Webserver Granian aus:

weblate/examples/weblate.nginx.granian.conf
#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 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$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

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

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://127.0.0.1:8888;
        proxy_read_timeout 3600;
    }
}

Siehe auch

Beispielkonfiguration für NGINX und Gunicorn

The following configuration runs Weblate using Gunicorn under the NGINX webserver (weblate/examples/weblate.nginx.gunicorn.conf in the source tree):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 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$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

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

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        proxy_pass http://unix:/run/gunicorn.sock;
        proxy_read_timeout 3600;
    }
}

Siehe auch

Beispielkonfiguration für NGINX und uWSGI

Um einen produktiven Webserver zu betreiben, verwenden Sie den mit Weblate installierten WSGI-Wrapper (beim Verwenden einer Python-Umgebung wird er als ~/weblate-env/lib/python3.14/site-packages/weblate/wsgi.py installiert). Vergessen Sie nicht, den Python-Suchpfad auch auf die Python-Einsatzumgebung einzustellen (zum Beispiel mit virtualenv = /home/user/weblate-env in uWSGI).

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

Configuration for NGINX (weblate/examples/weblate.nginx.conf in the source tree):

#
# nginx configuration for Weblate
#
# You will want to change:
#
# - server_name
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change python3.12 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$ {
        # CACHE_DIR/static/favicon.ico
        alias /home/weblate/data/cache/static/favicon.ico;
        expires 30d;
    }

    location /static/ {
        # CACHE_DIR/static/
        alias /home/weblate/data/cache/static/;
        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;
    }
}

Configuration for uWSGI (weblate/examples/weblate.uwsgi.ini in the source tree):

#
# uWSGI configuration for Weblate
#
# You will want to change:
#
# - change /home/weblate/weblate-env to location where Weblate Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change python3.12 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.12/site-packages/weblate/wsgi.py

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

# Path to the Python environment
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.

The following configuration runs Weblate as WSGI, you need to have enabled mod_wsgi (weblate/examples/apache.conf in the source tree):

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

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

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

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

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

    <Directory /home/weblate/weblate-env/lib/python3.12/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.

Verwenden Sie die passende Python-Version, um Weblate zu installieren.

Siehe auch

Beispielkonfiguration für Apache und Gunicorn

The following configuration runs Weblate in Gunicorn and Apache 2.4 (weblate/examples/apache.gunicorn.conf in the source tree):

#
# 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 Python environment is placed
# - change /home/weblate/data to match your DATA_DIR
# - change /home/weblate/data/cache to match your CACHE_DIR
# - change weblate user to match your Weblate user
#
<VirtualHost *:443>
    ServerAdmin admin@weblate.example.org
    ServerName weblate.example.org

    # CACHE_DIR/static/favicon.ico
    Alias /favicon.ico /home/weblate/data/cache/static/favicon.ico

    # CACHE_DIR/static/
    Alias /static/ /home/weblate/data/cache/static/
    <Directory /home/weblate/data/cache/static/>
        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 / http://localhost:8000/
    ProxyPassReverse / http://localhost:8000/
    ProxyPreserveHost On
</VirtualHost>

Siehe auch

Beispielkonfiguration zum Starten von Granian

Weblate hat eine optionale wsgi-Abhängigkeit (siehe Python-Abhängigkeiten), die alles installiert, was zum Betrieb von Granian benötigt wird. Bei der Installation von Weblate können Sie dies wie folgt angeben:

uv pip install Weblate[all,wsgi]

Sobald Sie Granian installiert haben, können Sie es ausführen. Dies geschieht normalerweise auf der Systemebene. Die folgenden Beispiele zeigen den Start über systemd:

/etc/systemd/system/granian.service
[Unit]
Description=granian daemon
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
RuntimeDirectory=granian
ExecStart=/home/weblate/weblate-env/bin/granian \
    --no-ws \
    --workers-max-rss 350 \
    --interface wsgi \
    --workers 2 \
    --backpressure 16 \
    --runtime-threads 8 \
    --runtime-mode mt \
    --port 8888 \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target
~

Siehe auch

Beispielkonfiguration zum Starten von Gunicorn

Gunicorn muss separat installiert werden:

uv pip install gunicorn

Sobald Sie Gunicorn installiert haben, können Sie es ausführen. Dies geschieht normalerweise auf der Systemebene. Die folgenden Beispiele zeigen den Start über systemd:

/etc/systemd/system/gunicorn.socket
[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target
/etc/systemd/system/gunicorn.service
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=weblate
Group=weblate
WorkingDirectory=/home/weblate/weblate-env/
Environment="DJANGO_SETTINGS_MODULE=weblate.settings"
ExecStart=/home/weblate/weblate-env/bin/gunicorn \
    --preload \
    --timeout 3600 \
    --graceful-timeout 3600 \
    --worker-class=gthread \
    --workers=2 \
    --threads=16 \
    --bind unix:/run/gunicorn.sock \
    weblate.wsgi:application

[Install]
WantedBy=multi-user.target

Siehe auch

How to use Django with Gunicorn

Weblate unter Pfad ausführen

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

A sample Apache configuration to serve Weblate under /weblate. Again using mod_wsgi (weblate/examples/apache-path.conf in the source tree):

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

    # CACHE_DIR/static/favicon.ico
    Alias /weblate/favicon.ico /home/weblate/data/cache/static/favicon.ico

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

    # Path to your Weblate Python environment
    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.12/site-packages/weblate/wsgi.py process-group=weblate
    WSGIPassAuthorization On

    <Directory /home/weblate/weblate-env/lib/python3.12/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

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

Eine typische Einrichtung mit Valkey oder 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

You should also start the Celery worker to process the tasks and start scheduled tasks. For debugging or development, this can be done directly on the command-line:

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup

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 Laufender Server.

Celery-Aufgaben in der WSGI im Eager-Modus ausführen

Bemerkung

Dies hat schwerwiegende Auswirkungen auf die Leistung der Weboberfläche und beeinträchtigt Funktionen, die von regelmäßigen Triggern abhängen (z. B. das Committen ausstehender Änderungen, Zusammenfassungsbenachrichtigungen oder Sicherungen).

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

Most likely you will want to run Celery as a daemon and that is covered by Daemonization. For the most common Linux setup using systemd, adapt the example files listed below. These examples are maintained in the Weblate source tree under weblate/examples/; Python wheels do not install these deployment samples.

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 /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. You might need to customize
# concurrency depending on the available resources and Weblate usage. Increase
# the concurrency if you get weblate.E019 error, decrease it if you are on a
# low-resource system.
CELERYD_OPTS="--beat:celery --queues:celery=celery --concurrency:celery=2 --prefetch-multiplier:celery=4 \
    --queues:notify=notify --concurrency:notify=2 --prefetch-multiplier:notify=10 \
    --queues:memory=memory --concurrency:memory=2 --prefetch-multiplier:memory=10 \
    --queues:translate=translate --concurrency:translate=4 --prefetch-multiplier:translate=4 \
    --queues:backup=backup  --concurrency:backup=1 --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 verfügt über integrierte Einrichtungen für geplante Aufgaben. Der Aufgabenplan wird in der Datenbank gespeichert und die Aufgaben werden vom Celery-Beat-Daemon ausgeführt.

Hinweis

Sie können zusätzliche Aufgaben in settings.py definieren, siehe zum Beispiel Lazy Commits.

Celery-Status überwachen

Sie können die aktuelle Länge der Celery-Aufgabenwarteschlangen in der Verwaltungsoberfläche finden oder Sie können celery_queues auf der Befehlszeile verwenden. Falls die Warteschlange zu lang wird, erhalten Sie auch einen Konfigurationsfehler in der Adminoberflä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, Fehlerberichte sammeln und Leistung überwachen zu konfigurieren.

Siehe auch

Celery-Einzelprozess einrichten

Wenn Sie über sehr wenig Speicher verfügen, sollten Sie die Anzahl der Weblate-Prozesse reduzieren. Alle Celery-Aufgaben können in einem einzigen Prozess ausgeführt werden:

celery --app=weblate.utils worker --beat --queues=celery,notify,memory,translate,backup --pool=solo

Eine Installation, die Docker verwendet, kann durch CELERY_SINGLE_PROCESS so konfiguriert werden, dass sie eine Celery-Einrichtung mit nur einem Prozess verwendet.

Warnung

Dies wird sich spürbar auf die Leistung von Weblate auswirken.

Weblate überwachen

Weblate stellt die URL /healthz/ zur Verfügung, die für einfache Integritätsprüfungen, zum Beispiel mit Kubernetes, verwendet werden kann. Der Docker-Container verfügt über eine integrierte Integritätsprüfung unter dieser URL.

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

Siehe auch

Fehlerberichte sammeln und Leistung überwachen

Weblate kann, wie jede andere Software auch, ausfallen. Um nützliche Fehlermeldungen zu sammeln, empfehlen wir die Nutzung von Drittanbieter-Diensten, 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:

E-Mail

Die Standardkonfiguration von Weblate veranlasst Django, bei Serverfehlern E-Mails über django.utils.log.AdminEmailHandler zu versenden. Dies ist die Konfiguration mit dem geringsten Aufwand, aber Sie sollten aus Gründen des Datenschutzes andere Optionen in Betracht ziehen, da die E-Mails bei Fehlern sensible Daten enthalten können. Sie können mehr darüber in Security implications lesen.

Um dieses Verhalten zu deaktivieren, entfernen Sie mail_admins aus LOGGING in den Weblate-Einstellungen, oder deaktivieren Sie WEBLATE_ADMIN_NOTIFY_ERROR in der Einsatzumgebung von Docker.

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

Sentry kann auch verwendet werden, um die Leistung von Weblate zu überwachen, indem Traces und Profile für einen bestimmten Prozentsatz von Operationen gesammelt werden. Dies kann mit SENTRY_TRACES_SAMPLE_RATE und SENTRY_PROFILES_SAMPLE_RATE konfiguriert werden.

Siehe auch

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",
    "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.

Bemerkung

Die Fehlerprotokollierung umfasst auch Ausnahmen, die zwar anstandslos behandelt wurden, aber auf ein Problem hinweisen könnten, wie z. B. das fehlgeschlagene Analysieren einer hochgeladenen Datei.

Graylog-Protokollverwaltung

Added in version 5.9.

Weblate kann so konfiguriert werden, dass es mit dem GELF-TCP-Protokoll protokolliert. Dies wurde für die Graylog-Integration entwickelt, kann aber mit jeder kompatiblen Protokollierungsplattform verwendet werden.

Die Konfigurationsvorlage ist in Beispielkonfiguration enthalten, für Docker kann dies mit WEBLATE_LOG_GELF_HOST konfiguriert werden.

Weblate auf einen anderen Server migrieren

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.

Datenbank migrieren

Der einfachste Ansatz ist das Verwenden datenbankeigener Tools, da diese normalerweise am effektivsten sind (z. B. pg_dump). Alternativ können Sie auch die Replikation verwenden, falls Ihre Datenbank dies unterstützt.

Siehe auch

Migration zwischen Datenbanken, beschrieben in Von anderen Datenbanken zu PostgreSQL migrieren.

VCS-Repositorys migrieren

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 Valkey, Redis, Cron-Jobs oder benutzerdefinierte Authentifizierungs-Backends.