Konfiguration#

Alle Einstellungen werden in settings.py gespeichert (wie bei Django üblich).

Bemerkung

Nachdem Sie eine dieser Einstellungen geändert haben, müssen Sie Weblate neu starten – sowohl WSGI- als auch Celery-Prozesse.

Wenn es als mod_wsgi ausgeführt wird, müssen Sie Apache neu starten, um die Konfiguration neu zu laden.

Siehe auch

Bitte lesen Sie auch die Django-Dokumentation für Parameter zur Konfiguration von Django selbst.

AKISMET_API_KEY#

Weblate kann Akismet verwenden, um eingehende anonyme Vorschläge auf Spam zu überprüfen. Besuchen Sie akismet.com, um einen API-Schlüssel zu erwerben und ihn mit einer Website zu verknüpfen.

ANONYMOUS_USER_NAME#

Benutzername von Benutzern, die nicht angemeldet sind.

Siehe auch

Zugriffssteuerung

AUDITLOG_EXPIRY#

Wie viele Tage Weblate Audit-Protokolle (die Informationen über Kontoaktivitäten enthalten) aufbewahren soll.

Der Standardwert ist 180 Tage.

AUTH_LOCK_ATTEMPTS#

Maximale Anzahl von fehlgeschlagenen Authentifizierungsversuchen, bevor die Ratenbegrenzung angewendet wird.

Dies wird derzeit an den folgenden Standorten angewandt:

  • Anmelden. Löscht das Passwort des Kontos und verhindert, dass sich der Benutzer anmelden kann, ohne ein neues Passwort anzufordern.

  • Passwort zurücksetzen. Verhindert, dass neue E-Mails gesendet werden, damit die Benutzer nicht mit zu vielen Versuchen, ihr Passwort zurückzusetzen, belästigt werden.

Der Standardwert ist 10.

Siehe auch

Ratenbegrenzung

AUTO_UPDATE#

Tägliche Aktualisierung aller Repositorys.

Hinweis

Nützlich, wenn Sie Benachrichtigungs-Hooks nicht verwenden, um Weblate-Repositorys automatisch zu aktualisieren.

Bemerkung

Aus Gründen der Abwärtskompatibilität gibt es neben der Auswahl der Zeichenkette auch Ein/Aus-Optionen.

Die Optionen sind:

"none"

Keine täglichen Aktualisierungen.

"remote" auch False

Nur Remote-Repositorys aktualisieren.

"full" auch True

Remote-Repositorys aktualisieren und Arbeitskopien zusammenführen.

Bemerkung

Dies setzt voraus, dass Hintergrundaufgaben mit Celery funktioniert, und wird nach einem Neustart wirksam.

AVATAR_URL_PREFIX#

Präfix für den Aufbau von Avatar-URLs als: ${AVATAR_URL_PREFIX}/avatar/${MAIL_HASH}?${PARAMS}. Die folgenden Dienste sind dafür bekannt, dass sie funktionieren:

Gravatar (Standard), wie unter https://gravatar.com/

AVATAR_URL_PREFIX = 'https://www.gravatar.com/'

Libravatar, wie unter https://www.libravatar.org/

AVATAR_URL_PREFIX = 'https://www.libravatar.org/'

Siehe auch

Avatar-Caching, ENABLE_AVATARS, Avatare

AUTH_TOKEN_VALID#

Dauer der Gültigkeit des Authentifizierungstokens und des temporären Passworts aus E-Mails zum Passwort zurücksetzen. Wird in Sekunden angegeben, Standardwert ist 172800 (2 Tage).

AUTH_PASSWORD_DAYS#

Für wie viele Tage Weblate die Wiederverwendung eines zuvor verwendeten Passworts für einen Benutzer ablehnt.

Die Überprüfung basiert auf dem Audit-Protokoll, AUDITLOG_EXPIRY muss mindestens so hoch sein wie diese Einstellung.

Bemerkung

Passwortänderungen, die vor Weblate 2.15 vorgenommen wurden, werden in dieser Richtlinie nicht berücksichtigt.

Der Standardwert ist 180 Tage.

AUTOFIX_LIST#

Liste der automatischen Korrekturen, die beim Speichern einer Zeichenkette anzuwenden sind.

Bemerkung

Geben Sie einen vollqualifizierten Pfad zu der Python-Klasse an, welche die Autofixer-Schnittstelle implementiert.

Verfügbare Korrekturen:

weblate.trans.autofixes.whitespace.SameBookendingWhitespace

Passt Leerzeichen am Anfang und Ende der Zeichenkette an die Ausgangszeichenkette an.

weblate.trans.autofixes.chars.ReplaceTrailingDotsWithEllipsis

Ersetzt nachgestellte Punkte (…), wenn die Ausgangszeichenkette entsprechende Auslassungspunkte (…) enthält.

weblate.trans.autofixes.chars.RemoveZeroSpace

Entfernt Leerzeichen ohne Breite, wenn die Ausgangszeichenkette keine enthält.

weblate.trans.autofixes.chars.RemoveControlChars

Entfernt Steuerzeichen, wenn die Ausgangszeichenkette keine enthält.

weblate.trans.autofixes.chars.DevanagariDanda

Ersetzt den Satzpunkt in Bangla durch das Devanagari-Danda-Zeichen.

weblate.trans.autofixes.html.BleachHTML

Entfernt unsichere HTML-Auszeichnungen von Zeichenketten, die als safe-html markiert sind (siehe Unsicheres HTML).

Sie können auswählen, welche verwendet werden sollen:

AUTOFIX_LIST = (
    "weblate.trans.autofixes.whitespace.SameBookendingWhitespace",
    "weblate.trans.autofixes.chars.ReplaceTrailingDotsWithEllipsis",
)

Siehe auch

Automatische Korrekturen, Benutzerdefinierte automatische Korrekturen

BACKGROUND_TASKS#

Neu in Version 4.5.2.

Legt fest, wie oft langwierige Wartungsmaßnahmen für eine Komponente ausgelöst werden sollen.

Im Moment steuert dies:

Mögliche Auswahlmöglichkeiten:

  • monthly (dies ist die Standardeinstellung)

  • weekly

  • daily

  • never

Bemerkung

Es wird nicht empfohlen, die Häufigkeit zu erhöhen, wenn Weblate Tausende von Komponenten enthält.

BASIC_LANGUAGES#

Neu in Version 4.4.

Liste der Sprachen, die den Benutzern für den Start einer neuen Übersetzung angeboten werden. Wenn nichts angegeben ist, wird eine integrierte Liste verwendet (die alle gängigen Sprachen enthält, aber keine länderspezifischen Varianten).

Dies schränkt nur nicht-berechtigte Benutzer ein, unerwünschte Sprachen hinzuzufügen. Den Projektadministratoren steht nach wie vor die gesamte Auswahl der in Weblate definierten Sprachen zur Verfügung.

Bemerkung

Damit werden keine neuen Sprachen für Weblate definiert – es werden nur die in der Datenbank vorhandenen gefiltert.

Beispiel:

BASIC_LANGUAGES = {"cs", "it", "ja", "en"}

Siehe auch

Sprachdefinitionen

BORG_EXTRA_ARGS#

Neu in Version 4.9.

Es können zusätzliche Argumente an borg create übergeben werden, wenn integrierte Backups ausgelöst werden.

Beispiel:

BORG_EXTRA_ARGS = ["--exclude", "vcs/"]

Siehe auch

Sichern und Verschieben von Weblate, borg create

CACHE_DIR#

Neu in Version 4.16.

Das Verzeichnis, in dem Weblate Cache-Dateien speichert. Standardmäßig ist dies der Unterordner cache in DATA_DIR.

Ändern Sie dies in lokales oder temporäres Dateisystem, wenn DATA_DIR auf einem Netzwerk-Dateisystem liegt.

Der Docker-Container verwendet dafür ein eigenes Volume, siehe Docker-Container-Volumes.

Üblicherweise existieren folgende Unterverzeichnisse:

fonts

font-config-Cache für Schriftarten verwalten.

avatar

Zwischengespeicherte Benutzer-Avatare, siehe Avatare.

static

Standardspeicherort für statische Django-Dateien, angegeben durch STATIC_ROOT. Siehe Bereitstellung statischer Dateien.

tesseract

OCR-trainierte Daten für Visueller Kontext für Zeichenketten.

CSP_SCRIPT_SRC, CSP_IMG_SRC, CSP_CONNECT_SRC, CSP_STYLE_SRC, CSP_FONT_SRC#

Passt den Content-Security-Policy-Header für Weblate an. Der Header wird automatisch auf der Grundlage aktivierter Integrationen mit Drittanbieterdiensten (Matomo, Google Analytics, Sentry, …) erzeugt.

Alle diese Listen sind standardmäßig leer.

Beispiel:

# Enable Cloudflare Javascript optimizations
CSP_SCRIPT_SRC = ["ajax.cloudflare.com"]

Siehe auch

Richtlinie zur Inhaltssicherheit, Content Security Policy (CSP)

CHECK_LIST#

Liste der an einer Übersetzung durchzuführenden Qualitätsprüfungen.

Bemerkung

Geben Sie einen vollqualifizierten Pfad zu der Python-Klasse an, die die Prüfschnittstelle implementiert.

Passen Sie die Liste der Qualitätsprüfungen an die für Sie relevanten Prüfungen an.

Alle integrierten Qualitätsprüfungen sind standardmäßig eingeschaltet, von wo aus Sie diese Einstellungen ändern können. Standardmäßig sind sie in der Beispielkonfiguration auskommentiert, so dass Standardwerte verwendet werden. Für jede neue Weblate-Version werden dann neue Qualitätsprüfungen durchgeführt.

Sie können alle Qualitätsprüfungen deaktivieren:

CHECK_LIST = ()

Sie können nur einige wenige einschalten:

CHECK_LIST = (
    "weblate.checks.chars.BeginNewlineCheck",
    "weblate.checks.chars.EndNewlineCheck",
    "weblate.checks.chars.MaxLengthCheck",
)

Bemerkung

Eine Änderung dieser Einstellung wirkt sich nur auf neu geänderte Übersetzungen aus. Bestehende Qualitätsprüfungen werden weiterhin in der Datenbank gespeichert. Um auch Änderungen an den gespeicherten Übersetzungen vorzunehmen, führen Sie updatechecks aus.

Siehe auch

Qualitätsprüfungen, Anpassen des Verhaltens mit Markierungen

COMMENT_CLEANUP_DAYS#

Anzahl der Tage bis Kommentare gelöscht werden. Der Standardwert ist None, was bedeutet, dass überhaupt nicht gelöscht wird.

COMMIT_PENDING_HOURS#

Anzahl der Stunden zwischen Commits von ausstehenden Änderungen durch die Hintergrundaufgabe.

Siehe auch

Komponentenkonfiguration, Alter der Änderungen, bis ein Commit erfolgt, Ausführen von Wartungsaufgaben, commit_pending

CONTACT_FORM#

Neu in Version 4.6.

Legt fest, wie E-Mails aus dem Kontaktformular gesendet werden sollen. Wählen Sie eine Konfiguration, die der Konfiguration Ihres Mailservers entspricht.

"reply-to"

Der Absender wird in Reply-To verwendet, dies ist das Standardverhalten.

"from"

Der Absender wird in From verwendet. Ihr Mailserver muss den Versand solcher E-Mails erlauben.

DATA_DIR#

Der Ordner, in dem Weblate alle Daten speichert. Er enthält Links zu VCS-Repositorys, einen Volltextindex und verschiedene Konfigurationsdateien für externe Tools.

Üblicherweise existieren folgende Unterverzeichnisse:

home

Basisverzeichnis, das zum Aufrufen von Skripts verwendet wird.

ssh

SSH-Schlüssel und Konfiguration.

media

Standardspeicherort für Django-Mediendateien, angegeben durch MEDIA_ROOT. Enthält hochgeladene Bildschirmfotos, siehe Visueller Kontext für Zeichenketten.

vcs

Versionsverwaltungs-Repositorys für Übersetzungen.

backups

Tägliche Sicherungsdaten. Für Details sehen Sie sich bitte Ausgegebene Daten für Backups an.

fonts:

Vom Benutzer hochgeladene Schriftarten, siehe Schriftarten verwalten.

cache

Verschiedene Caches. Kann mit CACHE_DIR an anderer Stelle platziert werden.

Der Docker-Container verwendet dafür ein eigenes Volume, siehe Docker-Container-Volumes.

Bemerkung

Dieses Verzeichnis muss von Weblate beschreibbar sein. Die Ausführung als uWSGI bedeutet, dass der Benutzer www-data Schreibzugriff darauf haben sollte.

Der einfachste Weg, dies zu erreichen, ist, den Benutzer zum Eigentümer des Verzeichnisses zu machen:

sudo chown www-data:www-data -R $DATA_DIR

Die Standardeinstellung ist /home/weblate/data, aber es wird erwartet, dass sie konfiguriert wird.

Siehe auch

Dateisystemberechtigungen, Sichern und Verschieben von Weblate, CACHE_DIR

DATABASE_BACKUP#

Ob die Datenbanksicherungen als reiner Text oder komprimiert gespeichert, oder übersprungen werden sollen. Die zulässigen Werte sind:

  • "plain"

  • "compressed"

  • "none"

Siehe auch

Sichern und Verschieben von Weblate

DEFAULT_ACCESS_CONTROL#

Die Standardeinstellung der Zugriffssteuerung für neue Projekte:

0

Öffentlich

1

Geschützt

100

Privat

200

Benutzerdefiniert

Verwenden Sie Benutzerdefiniert, wenn Sie die Zugriffssteuerungsliste manuell verwalten, d. h. sich nicht auf die interne Weblate-Verwaltung verlassen.

Siehe auch

Projekt-Zugriffssteuerung, Zugriffssteuerung

DEFAULT_AUTO_WATCH#

Neu in Version 4.5.

Konfiguriert, ob Projekte nach Beitrag automatisch beobachten für neue Benutzer aktiviert werden soll. Der Standardwert ist True.

Siehe auch

Benachrichtigungen

DEFAULT_RESTRICTED_COMPONENT#

Neu in Version 4.1.

Der Standardwert für die Komponenteneinschränkung.

Siehe auch

Eingeschränkter Zugriff, Umfang der Teams

DEFAULT_ADD_MESSAGE, DEFAULT_ADDON_MESSAGE, DEFAULT_COMMIT_MESSAGE, DEFAULT_DELETE_MESSAGE, DEFAULT_MERGE_MESSAGE#

Voreingestellte Commit-Nachrichten für verschiedene Operationen, siehe Komponentenkonfiguration für Details.

Siehe auch

Auszeichnungsvorlage, Komponentenkonfiguration, Commit-, Add-, Delete-, Merge-, Erweiterungs- und Merge-Request-Nachrichten

DEFAULT_ADDONS#

Standarderweiterungen, die für jede erstellte Komponente installiert werden.

Bemerkung

Diese Einstellung wirkt sich nur auf neu erstellte Komponenten aus.

Beispiel:

DEFAULT_ADDONS = {
    # Add-on with no parameters
    "weblate.flags.target_edit": {},
    # Add-on with parameters
    "weblate.autotranslate.autotranslate": {
        "mode": "suggest",
        "filter_type": "todo",
        "auto_source": "mt",
        "component": "",
        "engines": ["weblate-translation-memory"],
        "threshold": "80",
    },
}

Siehe auch

install_addon, Erweiterungen, WEBLATE_ADDONS

DEFAULT_COMMITER_EMAIL#

E-Mail-Adresse des Committers, standardmäßig noreply@weblate.org.

Siehe auch

DEFAULT_COMMITER_NAME

DEFAULT_COMMITER_NAME#

Name des Committers, standardmäßig Weblate.

Siehe auch

DEFAULT_COMMITER_EMAIL

DEFAULT_LANGUAGE#

Neu in Version 4.3.2.

Ausgangssprache für alle neuen Komponenten.

Der Standardwert ist en. Das entsprechende Sprachobjekt muss in der Datenbank vorhanden sein.

Siehe auch

Sprachdefinitionen, Ausgangssprache

DEFAULT_MERGE_STYLE#

Git-Strategie für alle neuen Komponenten.

  • rebase – Standard

  • merge

Siehe auch

Komponentenkonfiguration, Git-Strategie

DEFAULT_SHARED_TM#

Konfiguriert den Standardwert von Gemeinsamen Übersetzungsspeicher verwenden und Zu einem gemeinsamen Übersetzungsspeicher beitragen.

DEFAULT_TRANSLATION_PROPAGATION#

Standardeinstellung für die Übersetzungsweitergabe, ist standardmäßig True.

Siehe auch

Komponentenkonfiguration, Weitergabe von Übersetzungen erlauben

DEFAULT_PULL_MESSAGE#

Konfiguriert den Standardtitel und die Standardnachricht für Pull Requests.

ENABLE_AVATARS#

Ob Gravatar-basierte Avatare für Benutzer aktiviert werden sollen. Standardmäßig eingeschaltet.

Avatare werden abgerufen und auf dem Server zwischengespeichert, wodurch das Risiko des Durchsickerns privater Informationen verringert und das Benutzererlebnis beschleunigt wird.

Siehe auch

Avatar-Caching, AVATAR_URL_PREFIX, Avatare

ENABLE_HOOKS#

Ob anonyme Remote-Hooks eingeschaltet werden sollen.

Siehe auch

Benachrichtigungs-Hooks

ENABLE_HTTPS#

Ob Links per HTTPS oder HTTP an Weblate gesendet werden sollen. Diese Einstellung wirkt sich auf gesendete E-Mails und erzeugte absolute URLs aus.

In der Grundeinstellung wird dies auch für viele Django-Einstellungen im Rahmen von HTTPS verwendet – es aktiviert sichere Cookies, schaltet HSTS um oder aktiviert die Weiterleitung zu einer HTTPS-URL.

Die HTTPS-Weiterleitung könnte in einigen Fällen problematisch sein und Sie könnten auf ein Problem mit unendlicher Weiterleitung stoßen, wenn Sie einen Reverse-Proxy verwenden, der eine SSL-Terminierung durchführt und Protokoll-Header nicht korrekt an Django weitergibt. Bitte passen Sie Ihre Reverse-Proxy-Konfiguration so an, dass X-Forwarded-Proto- oder Forwarded-Header ausgegeben werden oder konfigurieren Sie SECURE_PROXY_SSL_HEADER, damit Django den SSL-Status korrekt erkennt.

Siehe auch

SESSION_COOKIE_SECURE, CSRF_COOKIE_SECURE, SECURE_SSL_REDIRECT, SECURE_PROXY_SSL_HEADER Seitendomain richtig einstellen

ENABLE_SHARING#

Schaltet das Menü Teilen ein oder aus, damit Benutzer den Übersetzungsfortschritt in sozialen Netzwerken teilen können.

EXTRA_HTML_HEAD#

Neu in Version 4.15.

Fügt eine zusätzliche Auszeichnung in den HTML-Header ein. Kann zum Beispiel für die Überprüfung der Eigentümerschaft einer Website verwendet werden:

EXTRA_HTML_HEAD = '<link href="https://fosstodon.org/@weblate" rel="me">'

Warnung

Die Zeichenkette wird nicht bereinigt, sondern unverändert in den HTML-Header eingefügt.

GET_HELP_URL#

Neu in Version 4.5.2.

URL, unter der Unterstützung für Ihre Weblate-Instanz zu finden ist.

GITEA_CREDENTIALS#

Neu in Version 4.12.

Liste der Zugangsdaten für Gitea-Server.

GITEA_CREDENTIALS = {
    "try.gitea.io": {
        "username": "weblate",
        "token": "your-api-token",
    },
}

Das Konfigurationswörterbuch besteht aus Anmeldeinformationen, die für jeden API-Host definiert sind. Der API-Host kann sich von dem unterscheiden, den Sie im Webbrowser verwenden, z. B. wird auf die GitHub-API als api.github.com zugegriffen.

Die folgende Konfiguration ist für jeden Host verfügbar:

username

API-Benutzer, erforderlich.

token

API-Token für den API-Benutzer, erforderlich.

scheme

Neu in Version 4.18.

Schema überschreiben. Weblate versucht, das Schema aus der URL des Repositorys zu analysieren und greift auf https zurück. Wenn Sie den API-Server intern betreiben, können Sie stattdessen http verwenden, aber beachten Sie die Sicherheit.

Hinweis

In the Docker container, the credentials can be configured in three variables and the credentials are built out of that. An example configuration for GitHub might look like:

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

Wird verwendet als:

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

Alternatively the Python dictonary can be provided as a string:

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

Or the path to a file containing the Python dictionary:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

Siehe auch

Gitea-Pull-Requests, Erstellen eines persönlichen Gitea-Zugangstokens

GITLAB_CREDENTIALS#

Neu in Version 4.3.

Liste der Zugangsdaten für GitLab-Server.

GITLAB_CREDENTIALS = {
    "gitlab.com": {
        "username": "weblate",
        "token": "your-api-token",
    },
}

Das Konfigurationswörterbuch besteht aus Anmeldeinformationen, die für jeden API-Host definiert sind. Der API-Host kann sich von dem unterscheiden, den Sie im Webbrowser verwenden, z. B. wird auf die GitHub-API als api.github.com zugegriffen.

Die folgende Konfiguration ist für jeden Host verfügbar:

username

API-Benutzer, erforderlich.

token

API-Token für den API-Benutzer, erforderlich.

scheme

Neu in Version 4.18.

Schema überschreiben. Weblate versucht, das Schema aus der URL des Repositorys zu analysieren und greift auf https zurück. Wenn Sie den API-Server intern betreiben, können Sie stattdessen http verwenden, aber beachten Sie die Sicherheit.

Hinweis

In the Docker container, the credentials can be configured in three variables and the credentials are built out of that. An example configuration for GitHub might look like:

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

Wird verwendet als:

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

Alternatively the Python dictonary can be provided as a string:

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

Or the path to a file containing the Python dictionary:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

Siehe auch

GitLab-Merge-Requests, GitLab: Persönliche Zugangstoken

GITHUB_CREDENTIALS#

Neu in Version 4.3.

Liste der Zugangsdaten für GitHub-Server.

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

Das Konfigurationswörterbuch besteht aus Anmeldeinformationen, die für jeden API-Host definiert sind. Der API-Host kann sich von dem unterscheiden, den Sie im Webbrowser verwenden, z. B. wird auf die GitHub-API als api.github.com zugegriffen.

Die folgende Konfiguration ist für jeden Host verfügbar:

username

API-Benutzer, erforderlich.

token

API-Token für den API-Benutzer, erforderlich.

scheme

Neu in Version 4.18.

Schema überschreiben. Weblate versucht, das Schema aus der URL des Repositorys zu analysieren und greift auf https zurück. Wenn Sie den API-Server intern betreiben, können Sie stattdessen http verwenden, aber beachten Sie die Sicherheit.

Hinweis

In the Docker container, the credentials can be configured in three variables and the credentials are built out of that. An example configuration for GitHub might look like:

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

Wird verwendet als:

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

Alternatively the Python dictonary can be provided as a string:

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

Or the path to a file containing the Python dictionary:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

Siehe auch

GitHub-Pull-Requests, Erstellen eines persönlichen GitHub-Zugangstokens

BITBUCKETSERVER_CREDENTIALS#

Neu in Version 4.16.

Liste der Zugangsdaten für Bitbucket-Server.

BITBUCKETSERVER_CREDENTIALS = {
    "git.self-hosted.com": {
        "username": "weblate",
        "token": "http-access-token",
    },
}

Das Konfigurationswörterbuch besteht aus Anmeldeinformationen, die für jeden API-Host definiert sind. Der API-Host kann sich von dem unterscheiden, den Sie im Webbrowser verwenden, z. B. wird auf die GitHub-API als api.github.com zugegriffen.

Die folgende Konfiguration ist für jeden Host verfügbar:

username

API-Benutzer, erforderlich.

token

API-Token für den API-Benutzer, erforderlich.

scheme

Neu in Version 4.18.

Schema überschreiben. Weblate versucht, das Schema aus der URL des Repositorys zu analysieren und greift auf https zurück. Wenn Sie den API-Server intern betreiben, können Sie stattdessen http verwenden, aber beachten Sie die Sicherheit.

Hinweis

In the Docker container, the credentials can be configured in three variables and the credentials are built out of that. An example configuration for GitHub might look like:

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

Wird verwendet als:

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

Alternatively the Python dictonary can be provided as a string:

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

Or the path to a file containing the Python dictionary:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

Siehe auch

Bitbucket-Server-Pull-Request, Bitbucket: HTTP-Zugangstoken

GOOGLE_ANALYTICS_ID#

Google Analytics-ID, um die Überwachung von Weblate mit Google Analytics zu aktivieren.

HIDE_REPO_CREDENTIALS#

Blendet die Repository-Zugangsdaten auf der Weboberfläche aus. Falls Sie eine Repository-URL mit Benutzer und Passwort haben, wird Weblate diese ausblenden, wenn zugehörige Informationen den Benutzern angezeigt werden.

Zum Beispiel wird anstelle von https://Benutzer:Passwort@git.beispiel.de/repo.git nur https://git.beispiel.de/repo.git angezeigt. In ähnlicher Weise versucht es auch, VCS-Fehlermeldungen zu bereinigen.

Bemerkung

Standardmäßig eingeschaltet.

HIDE_VERSION#

Neu in Version 4.3.1.

Versteckt Versionsinformationen vor nicht authentifizierten Benutzern. Dies führt auch dazu, dass alle Links zur Dokumentation auf die neueste Version verweisen, anstatt auf die Dokumentation, die der aktuell installierten Version entspricht.

Das Verstecken der Version ist in einigen Unternehmen eine empfohlene Sicherheitspraxis, es verhindert aber nicht, dass ein Angreifer die Version durch Ausprobieren des Verhaltens herausfinden kann.

Bemerkung

Diese Funktion ist standardmäßig ausgeschaltet.

INTERLEDGER_PAYMENT_POINTERS#

Neu in Version 4.12.1.

Liste der Interledger Payment Pointers (ILPs) für Web-Monetarisierung.

Wenn mehrere angegeben werden, wird eine probabilistische Aufteilung der Einnahmen durch zufällige Auswahl erreicht.

Weitere Einzelheiten finden Sie unter <https://webmonetization.org/>.

Hinweis

Mit dem Standardwert können Benutzer Weblate selbst finanzieren.

IP_BEHIND_REVERSE_PROXY#

Gibt an, ob Weblate hinter einem Reverse-Proxy ausgeführt wird.

Wenn auf True gesetzt, bezieht Weblate die IP-Adresse aus einem Header, der durch IP_PROXY_HEADER definiert ist.

Warnung

Vergewissern Sie sich, dass Sie tatsächlich einen Reverse-Proxy verwenden und dass dieser diesen Header setzt, da die Benutzer sonst die IP-Adresse fälschen können.

Bemerkung

Diese Funktion ist nicht standardmäßig eingeschaltet.

Siehe auch

Hinter einem Reverse-Proxy ausführen, Ratenbegrenzung, IP_PROXY_HEADER, IP_PROXY_OFFSET

IP_PROXY_HEADER#

Gibt an, aus welchem Header Weblate die IP-Adresse beziehen soll, wenn IP_BEHIND_REVERSE_PROXY eingeschaltet ist.

Die Standardeinstellung ist HTTP_X_FORWARDED_FOR.

Siehe auch

Hinter einem Reverse-Proxy ausführen, Ratenbegrenzung, SECURE_PROXY_SSL_HEADER, IP_BEHIND_REVERSE_PROXY, IP_PROXY_OFFSET

IP_PROXY_OFFSET#

Geändert in Version 5.0.1: Der Standardwert wurde von 1 auf -1 geändert.

Gibt an, welcher Teil von IP_PROXY_HEADER als Client-IP-Adresse verwendet wird.

Je nach Ihrer Einrichtung kann dieser Header aus mehreren IP-Adressen bestehen (z. B. X-Forwarded-For: client-ip, proxy-a, proxy-b) und Sie können hier konfigurieren, welche Adresse aus dem Header als Client-IP-Adresse verwendet wird.

Warnung

Diese Einstellung wirkt sich auf die Sicherheit Ihrer Installation aus. Sie sollten sie nur so konfigurieren, dass vertrauenswürdige Proxys zur Ermittlung der IP-Adresse verwendet werden. Weitere Einzelheiten finden Sie unter <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For#security_and_privacy_concerns>.

Der Standardwert ist -1.

Siehe auch

Hinter einem Reverse-Proxy ausführen, Ratenbegrenzung, SECURE_PROXY_SSL_HEADER, IP_BEHIND_REVERSE_PROXY, IP_PROXY_HEADER

LICENSE_EXTRA#

Zusätzliche Lizenzen, die in die Lizenzauswahl einbezogen werden sollen.

Bemerkung

Jede Lizenzdefinition sollte ein Tupel aus einem Kurznamen, einem Langnamen und einer URL sein.

Zum Beispiel:

LICENSE_EXTRA = [
    (
        "AGPL-3.0",
        "GNU Affero General Public License v3.0",
        "https://www.gnu.org/licenses/agpl-3.0-standalone.html",
    ),
]

LICENSE_FILTER#

Geändert in Version 4.3: Wenn Sie diesen Wert auf einen leeren Wert setzen, wird die Lizenzwarnung deaktiviert.

Filtert die Liste der anzuzeigenden Lizenzen. Dadurch wird auch die Lizenzwarnung deaktiviert, wenn sie auf leer gesetzt ist.

Bemerkung

Dieser Filter verwendet die kurzen Lizenznamen.

Zum Beispiel:

LICENSE_FILTER = {"AGPL-3.0", "GPL-3.0-or-later"}

Folgendes deaktiviert die Lizenzwarnung:

LICENSE_FILTER = set()

Siehe auch

Warnungen der Übersetzungskomponente

LICENSE_REQUIRED#

Legt fest, ob das Lizenzattribut in Komponentenkonfiguration erforderlich ist.

Bemerkung

Diese Funktion ist standardmäßig deaktiviert.

LIMIT_TRANSLATION_LENGTH_BY_SOURCE_LENGTH#

Ob die Länge einer bestimmten Übersetzung begrenzt werden soll. Die Beschränkung ist die Länge der Ausgangszeichenkette × 10 Zeichen.

Hinweis

Setzen Sie dies auf False, um längere Übersetzungen (bis zu 10.000 Zeichen) unabhängig von der Länge der Ausgangszeichenkette zu ermöglichen.

Bemerkung

Der Standardwert ist True.

LOCALIZE_CDN_URL und LOCALIZE_CDN_PATH#

Diese Einstellungen konfigurieren die JavaScript-Lokalisierung CDN-Erweiterung. LOCALIZE_CDN_URL definiert die Root-URL, unter der das Lokalisierungs-CDN verfügbar ist und LOCALIZE_CDN_PATH definiert den Pfad, unter dem Weblate die erzeugten Dateien speichern soll, die unter der LOCALIZE_CDN_URL ausgeliefert werden.

Hinweis

Hosted Weblate verwendet https://weblate-cdn.com/.

Siehe auch

JavaScript-Lokalisierung CDN

LOGIN_REQUIRED_URLS#

Eine Liste von URLs, für die eine Anmeldung erforderlich sein soll. (Neben den in Weblate integrierten Standardregeln).

Hinweis

Damit können Sie eine ganze Installation mit einem Passwort schützen:

LOGIN_REQUIRED_URLS = (r"/(.*)$",)
REST_FRAMEWORK["DEFAULT_PERMISSION_CLASSES"] = [
    "rest_framework.permissions.IsAuthenticated"
]

Hinweis

Es ist wünschenswert, auch den API-Zugang zu sperren, wie im obigen Beispiel gezeigt.

Siehe auch

REQUIRE_LOGIN

LOGIN_REQUIRED_URLS_EXCEPTIONS#

Liste der Ausnahmen für LOGIN_REQUIRED_URLS. Wenn nicht angegeben, können Benutzer auf die Anmeldeseite zugreifen.

Einige Ausnahmen, die Sie möglicherweise einschließen möchten:

LOGIN_REQUIRED_URLS_EXCEPTIONS = (
    r"/accounts/(.*)$",  # Required for sign-in
    r"/static/(.*)$",  # Required for development mode
    r"/widget/(.*)$",  # Allowing public access to widgets
    r"/data/(.*)$",  # Allowing public access to data exports
    r"/hooks/(.*)$",  # Allowing public access to notification hooks
    r"/api/(.*)$",  # Allowing access to API
    r"/js/i18n/$",  # JavaScript localization
)

MATOMO_SITE_ID#

ID der Website in Matomo (ehemals Piwik), die Sie für die Nachverfolgung von Weblate verwenden möchten.

Bemerkung

Diese Integration unterstützt den Matomo Tag Manager nicht.

Siehe auch

MATOMO_URL

MATOMO_URL#

Vollständige URL (einschließlich nachgestelltem Schrägstrich) einer Matomo (ehemals Piwik)-Installation, um die Nutzung von Weblate nachzuverfolgen. Weitere Einzelheiten finden Sie unter <https://matomo.org/>.

Hinweis

Diese Integration unterstützt den Matomo Tag Manager nicht.

Zum Beispiel:

MATOMO_SITE_ID = 1
MATOMO_URL = "https://example.matomo.cloud/"

Siehe auch

MATOMO_SITE_ID

NEARBY_MESSAGES#

Wie viele Zeichenketten um die aktuell übersetzte Zeichenkette herum angezeigt werden sollen. Dies ist nur ein Standardwert, Benutzer können dies im Benutzerprofil anpassen.

DEFAULT_PAGE_LIMIT#

Neu in Version 4.7.

Standardanzahl der Elemente, die bei aktivem Seitenumbruch angezeigt werden.

PAGURE_CREDENTIALS#

Neu in Version 4.3.2.

Liste der Zugangsdaten für Pagure-Server.

PAGURE_CREDENTIALS = {
    "pagure.io": {
        "username": "weblate",
        "token": "your-api-token",
    },
}

Das Konfigurationswörterbuch besteht aus Anmeldeinformationen, die für jeden API-Host definiert sind. Der API-Host kann sich von dem unterscheiden, den Sie im Webbrowser verwenden, z. B. wird auf die GitHub-API als api.github.com zugegriffen.

Die folgende Konfiguration ist für jeden Host verfügbar:

username

API-Benutzer, erforderlich.

token

API-Token für den API-Benutzer, erforderlich.

scheme

Neu in Version 4.18.

Schema überschreiben. Weblate versucht, das Schema aus der URL des Repositorys zu analysieren und greift auf https zurück. Wenn Sie den API-Server intern betreiben, können Sie stattdessen http verwenden, aber beachten Sie die Sicherheit.

Hinweis

In the Docker container, the credentials can be configured in three variables and the credentials are built out of that. An example configuration for GitHub might look like:

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

Wird verwendet als:

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

Alternatively the Python dictonary can be provided as a string:

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

Or the path to a file containing the Python dictionary:

echo '{ "api.github.com": { "username": "api-user", "token": "api-token", } }' > /path/to/github-credentials
WEBLATE_GITHUB_CREDENTIALS_FILE='/path/to/github-credentials'

Siehe auch

Pagure-Merge-Requests, Pagure-API

PRIVACY_URL#

Neu in Version 4.8.1.

URL, unter der Ihre Weblate-Instanz ihre Datenschutzrichtlinie anzeigt.

Hinweis

Nützlich, wenn Sie Ihre rechtlichen Dokumente außerhalb von Weblate hosten, um sie in Weblate einzubetten. Bitte schauen Sie sich Rechtliche Grundlagen für Details an.

Beispiel:

PRIVACY_URL = "https://weblate.org/terms/"

Siehe auch

LEGAL_URL

PRIVATE_COMMIT_EMAIL_OPT_IN#

Neu in Version 4.15.

Legt fest, ob es sich bei der privaten Commit-E-Mail um eine Opt-In- oder Opt-Out-E-Mail handelt (standardmäßig ist sie Opt-In).

Siehe auch

Benutzerprofil, PRIVATE_COMMIT_EMAIL_TEMPLATE

PRIVATE_COMMIT_EMAIL_TEMPLATE#

Neu in Version 4.15.

Vorlage zur Erstellung einer privaten E-Mail für einen Benutzer. Der Standardwert ist "{username}@users.noreply.{site_domain}".

Zum Deaktivieren ein leere Zeichenkette einsetzen.

Bemerkung

Die Verwendung anderer Commit-E-Mails ist für Benutzer freiwillig, es sei denn, sie werden durch PRIVATE_COMMIT_EMAIL_OPT_IN konfiguriert. Benutzer können Commit-E-Mails im Profil konfigurieren.

PROJECT_BACKUP_KEEP_COUNT#

Neu in Version 4.14.

Legt fest, wie viele Sicherungen pro Projekt auf dem Server gespeichert werden. Der Standardwert ist 3.

Siehe auch

Sicherungen auf Projektebene

PROJECT_BACKUP_KEEP_DAYS#

Neu in Version 4.14.

Legt fest, wie lange die Projekt-Backups auf dem Server aufbewahrt werden sollen. Die Standardeinstellung ist 30 Tage.

Siehe auch

Sicherungen auf Projektebene

PROJECT_NAME_RESTRICT_RE#

Neu in Version 4.15.

Definiert einen regulären Ausdruck zur Einschränkung der Projektbenennung. Alle übereinstimmenden Namen werden abgelehnt.

Siehe auch

Projektname

PROJECT_WEB_RESTRICT_HOST#

Neu in Version 4.16.2.

Verhindert das Benutzen von gewissen Hosts auf der Projektwebsite. Jede Subdomain wird abgeglichen, d. h. beim Blockieren von example.com wird auch test.example.com blockiert. Die Liste sollte nur kleingeschriebene Zeichenfolgen enthalten, die zu vergleichende Domain wird vor dem Prüfen kleingeschrieben.

Standardkonfiguration:

PROJECT_WEB_RESTRICT_HOST = {"localhost"}

Siehe auch

Projektseite PROJECT_WEB_RESTRICT_NUMERIC, PROJECT_WEB_RESTRICT_RE,

PROJECT_WEB_RESTRICT_NUMERIC#

Neu in Version 4.16.2.

Verhindert die Nutzung von numerischen IP-Adressen auf der Projektwebsite. Standardmäßig eingeschaltet.

Siehe auch

Projektseite PROJECT_WEB_RESTRICT_HOST, PROJECT_WEB_RESTRICT_RE,

PROJECT_WEB_RESTRICT_RE#

Neu in Version 4.15.

Definiert einen regulären Ausdruck zur Einschränkung von Projekt-Websites. Alle übereinstimmenden URLs werden abgelehnt.

Siehe auch

Projektseite PROJECT_WEB_RESTRICT_HOST, PROJECT_WEB_RESTRICT_NUMERIC

RATELIMIT_ATTEMPTS#

Maximale Anzahl von Authentifizierungsversuchen, bevor die Ratenbegrenzung angewendet wird.

Der Standardwert ist 5.

Siehe auch

Ratenbegrenzung, RATELIMIT_WINDOW, RATELIMIT_LOCKOUT

RATELIMIT_WINDOW#

Wie lange die Authentifizierung nach angewendeter Ratenbegrenzung akzeptiert wird.

Eine Anzahl von Sekunden, standardmäßig 300 (5 Minuten).

Siehe auch

Ratenbegrenzung, RATELIMIT_ATTEMPTS, RATELIMIT_LOCKOUT

RATELIMIT_LOCKOUT#

Wie lange die Authentifizierung nach angewendeter Ratenbegrenzung gesperrt ist.

Eine Anzahl von Sekunden, standardmäßig 600 (10 Minuten).

Siehe auch

Ratenbegrenzung, RATELIMIT_ATTEMPTS, RATELIMIT_WINDOW

REGISTRATION_ALLOW_BACKENDS#

Neu in Version 4.1.

Liste der Authentifizierungs-Backends, von denen aus die Registrierung erlaubt werden soll. Dies schränkt nur neue Registrierungen ein, Benutzer können sich weiterhin über alle konfigurierten Authentifizierungs-Backends authentifizieren und Authentifizierungen hinzufügen.

Es wird empfohlen, REGISTRATION_OPEN eingeschaltet zu lassen, während man die Registrierungs-Backends einschränkt. Andernfalls können sich Benutzer zwar registrieren, aber Weblate zeigt keine Links zur Registrierung in der Bedienoberfläche an.

Beispiel:

REGISTRATION_ALLOW_BACKENDS = ["azuread-oauth2", "azuread-tenant-oauth2"]

Hinweis

Die Backend-Namen entsprechen den in der URL für die Authentifizierung verwendeten Namen.

Siehe auch

REGISTRATION_OPEN, Authentifizierung

REGISTRATION_CAPTCHA#

Ob die Registrierung von neuen Konten durch ein CAPTCHA geschützt ist. Standardmäßig aktiviert.

Wenn diese Option aktiviert ist, wird ein CAPTCHA zu allen Seiten hinzugefügt, auf denen ein Benutzer seine E-Mail-Adresse eingibt:

  • Registrierung eines neuen Kontos.

  • Passwortwiederherstellung.

  • E-Mail zu einem Konto hinzufügen.

  • Kontaktformular für nicht angemeldete Benutzer.

REGISTRATION_EMAIL_MATCH#

Hier können Sie filtern, welche E-Mail-Adressen sich registrieren können.

Die Standardeinstellung ist .*, sodass sich jede beliebige E-Mail-Adresse registrieren kann.

Sie können damit die Registrierung auf eine einzige E-Mail-Domäne beschränken:

REGISTRATION_EMAIL_MATCH = r"^.*@weblate\.org$"

REGISTRATION_OPEN#

Ob die Registrierung von neuen Konten derzeit erlaubt ist. Standardmäßig aktiviert.

Diese Einstellung wirkt sich auf die integrierte Authentifizierung per E-Mail-Adresse oder über Python Social Auth aus (Sie können bestimmte Backends mit REGISTRATION_ALLOW_BACKENDS auf eine Positivliste setzen).

Bemerkung

Bei der Verwendung von Authentifizierungsmethoden von Drittanbietern, wie z. B. LDAP-Authentifizierung, wird lediglich das Registrierungsformular ausgeblendet, aber neue Benutzer können sich möglicherweise trotzdem anmelden und Konten erstellen.

Siehe auch

REGISTRATION_ALLOW_BACKENDS, REGISTRATION_EMAIL_MATCH, Authentifizierung

REGISTRATION_REBIND#

Neu in Version 4.16.

Erlaubt das erneute Binden von Authentifizierungs-Backends für bestehende Benutzer. Aktivieren Sie dies, wenn Sie zwischen Authentifizierungsanbietern migrieren.

Bemerkung

Standardmäßig ausgeschaltet, um das Hinzufügen anderer Authentifizierungs-Backends zu einem bestehenden Konto zu verhindern. Eine erneute Bindung kann zu einer Kompromittierung des Kontos führen, wenn mehr Authentifizierungs-Backends von Drittanbietern verwendet werden.

REPOSITORY_ALERT_THRESHOLD#

Neu in Version 4.0.2.

Schwellenwert für die Auslösung einer Warnung bei veralteten Repositorys oder zu viele Änderungen enthaltende Repositorys. Der Standardwert ist 25.

Siehe auch

Warnungen der Übersetzungskomponente

REQUIRE_LOGIN#

Neu in Version 4.1.

Dies aktiviert LOGIN_REQUIRED_URLS und konfiguriert das REST-Framework so, dass eine Authentifizierung für alle API-Endpunkte erforderlich ist.

Bemerkung

Dies ist in der Beispielkonfiguration implementiert. Für Docker, verwenden Sie WEBLATE_REQUIRE_LOGIN.

SENTRY_DSN#

Sentry-DSN zur Verwendung für das Sammeln von Fehlerberichten.

Siehe auch

Django-Integration für Sentry

SIMPLIFY_LANGUAGES#

Um einfache Sprachcodes für Standard-Sprach/Länder-Kombinationen zu verwenden. Zum Beispiel wird eine fr_FR-Übersetzung den fr Sprachcode verwenden. Dies ist normalerweise das gewünschte Verhalten, da es die Auflistung von Sprachen für diese Standardkombinationen vereinfacht.

Deaktivieren Sie diese Option, wenn Sie für jede Variante eine andere Übersetzung wünschen.

SITE_DOMAIN#

Konfiguriert die Site-Domäne. Notwendig, um in vielen Bereichen (z. B. Aktivierungs-E-Mails, Benachrichtigungen oder RSS-Feeds) korrekte absolute Links zu erzeugen.

Wenn Weblate auf einem Nicht-Standard-Port läuft, geben Sie ihn hier ebenfalls an.

Beispiele:

# Production site with domain name
SITE_DOMAIN = "weblate.example.com"

# Local development with IP address and port
SITE_DOMAIN = "127.0.0.1:8000"

Bemerkung

Diese Einstellung sollte nur den Domänennamen enthalten. Für die Konfiguration des Protokolls (Einschalten und Erzwingen von HTTPS) verwenden Sie ENABLE_HTTPS und zum Ändern der URL verwenden Sie URL_PREFIX.

Hinweis

In einem Docker-Container wird die Site-Domäne über WEBLATE_ALLOWED_HOSTS konfiguriert.

Siehe auch

Seitendomain richtig einstellen, Einrichtung zulässiger Hosts, HTTPS richtig konfigurieren WEBLATE_SITE_DOMAIN, ENABLE_HTTPS

SITE_TITLE#

Seitentitel, der für die Website und gesendete E-Mails verwendet werden soll.

SPECIAL_CHARS#

Zusätzliche Zeichen, die in die visuelle Tastatur aufgenommen werden sollen, Visuelle Tastatur.

Der Standardwert ist:

SPECIAL_CHARS = ("\t", "\n", "\u00a0", "…")

SINGLE_PROJECT#

Leitet Benutzer direkt zu einem Projekt oder einer Komponente um, anstatt die Übersichtsseite anzuzeigen. Sie können es entweder auf True setzen, so dass es nur funktioniert, wenn es tatsächlich nur ein einziges Projekt in Weblate gibt. Alternativ können Sie auch den Projekt-Slug angeben, dann wird bedingungslos zu diesem Projekt umgeleitet.

Beispiel:

SINGLE_PROJECT = "test"

SSH_EXTRA_ARGS#

Neu in Version 4.9.

Ermöglicht das Hinzufügen benutzerdefinierter Parameter, wenn Weblate SSH aufruft. Nützlich, wenn Sie sich mit Servern verbinden, die eine ältere Verschlüsselung oder andere nicht standardisierte Funktionen verwenden.

Wenn zum Beispiel die SSH-Verbindung in Weblate mit der Meldung Unable to negotiate with legacyhost: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1, können Sie dies aktivieren mit:

SSH_EXTRA_ARGS = "-oKexAlgorithms=+diffie-hellman-group1-sha1"

Hinweis

Die Zeichenkette wird von der Shell ausgewertet, also achten Sie darauf, dass alle Leer- und Sonderzeichen in Anführungszeichen gesetzt werden.

Siehe auch

OpenSSH-Legacy-Optionen

STATUS_URL#

Die URL, unter der Ihre Weblate-Instanz ihren Status meldet.

SUGGESTION_CLEANUP_DAYS#

Löscht Vorschläge automatisch nach einer bestimmten Anzahl von Tagen. Der Standardwert ist None, was bedeutet, dass keine Löschungen vorgenommen werden.

UNUSED_ALERT_DAYS#

Neu in Version 4.17.

Legt fest, wann die Warnung Die Komponente scheint nicht verwendet zu werden ausgelöst wird.

Standardmäßig 365 Tage, zum Ausschalten auf 0 setzen.

UPDATE_LANGUAGES#

Neu in Version 4.3.2.

Steuert, ob die Sprachdatenbank bei der Datenbankmigration aktualisiert werden soll und ist standardmäßig eingeschaltet. Diese Einstellung hat keinen Einfluss auf den Aufruf von setuplang.

Warnung

Die Anzeige der Sprachen kann dadurch inkonsistent werden. Die Sprachdefinitionen von Weblate werden im Laufe der Zeit erweitert und es werden keine Sprachcodes für die definierten Sprachen angezeigt.

Siehe auch

Integrierte Sprachdefinitionen

URL_PREFIX#

Mit dieser Einstellung können Sie Weblate unter einem bestimmten Pfad ausführen (andernfalls muss es vom Webserver-Root aus gestartet werden).

Bemerkung

Um diese Einstellung zu verwenden, müssen Sie auch Ihren Server so konfigurieren, dass er dieses Präfix entfernt. Bei WSGI kann dies zum Beispiel durch die Einstellung WSGIScriptAlias erreicht werden.

Hinweis

Das Präfix sollte mit einem / beginnen.

Beispiel:

URL_PREFIX = "/translations"

Bemerkung

Diese Einstellung funktioniert nicht mit dem in Django integrierten Server, Sie müssen urls.py so anpassen, dass es dieses Präfix enthält.

VCS_API_DELAY#

Neu in Version 4.15.1.

Konfiguriert die minimale Verzögerung in Sekunden zwischen API-Aufrufen von Drittanbietern in GitHub-Pull-Requests, GitLab-Merge-Requests, Gitea-Pull-Requests, und Pagure-Merge-Requests.

Dadurch werden die API-Aufrufe von Weblate an diese Dienste begrenzt, um sie nicht zu überlasten.

Wenn Sie durch den sekundären Ratenbegrenzer bei GitHub eingeschränkt sind, könnte eine Erhöhung dieses Wertes helfen.

Der Standardwert ist 10.

VCS_BACKENDS#

Konfiguration der verfügbaren VCS-Backends.

Bemerkung

Weblate versucht, alle unterstützten Backends zu verwenden, für die Sie die Werkzeuge haben.

Hinweis

Sie können damit die Auswahl einschränken oder eigene VCS-Backends hinzufügen.

VCS_BACKENDS = ("weblate.vcs.git.GitRepository",)

Siehe auch

Integration der Versionsverwaltung

VCS_CLONE_DEPTH#

Legt fest, wie tief das Klonen von Repositorys in Weblate gehen soll.

Bemerkung

Derzeit wird dies nur in Git unterstützt. Standardmäßig führt Weblate flache Klone der Repositorys aus, um das Klonen zu beschleunigen und Speicherplatz zu sparen. Je nach Nutzung (z. B. bei der Verwendung von benutzerdefinierten Erweiterungen) kann es sinnvoll sein, die Tiefe zu erhöhen oder flache Klone komplett abzuschalten, indem man den Wert 0 setzt.

Hinweis

Falls Sie beim Pushen von Weblate die Fehlermeldung fatal: protocol error: expected old/new/ref, got 'shallow <commit hash>' erhalten, schalten Sie flache Klone komplett aus, durch Einstellung von:

VCS_CLONE_DEPTH = 0

WEBLATE_ADDONS#

Liste der zur Verwendung verfügbaren Erweiterungen. Um sie zu verwenden, müssen sie für eine bestimmte Übersetzungskomponente aktiviert werden. Standardmäßig sind alle integrierten Erweiterungen enthalten. Wenn Sie die Liste erweitern, werden Sie wahrscheinlich vorhandene Erweiterungen aktiviert lassen wollen, z. B.:

WEBLATE_ADDONS = (
    # Built-in add-ons
    "weblate.addons.gettext.GenerateMoAddon",
    "weblate.addons.gettext.UpdateLinguasAddon",
    "weblate.addons.gettext.UpdateConfigureAddon",
    "weblate.addons.gettext.MsgmergeAddon",
    "weblate.addons.gettext.GettextCustomizeAddon",
    "weblate.addons.gettext.GettextAuthorComments",
    "weblate.addons.cleanup.CleanupAddon",
    "weblate.addons.consistency.LangaugeConsistencyAddon",
    "weblate.addons.discovery.DiscoveryAddon",
    "weblate.addons.flags.SourceEditAddon",
    "weblate.addons.flags.TargetEditAddon",
    "weblate.addons.flags.SameEditAddon",
    "weblate.addons.flags.BulkEditAddon",
    "weblate.addons.generate.GenerateFileAddon",
    "weblate.addons.json.JSONCustomizeAddon",
    "weblate.addons.xml.XMLCustomizeAddon",
    "weblate.addons.properties.PropertiesSortAddon",
    "weblate.addons.git.GitSquashAddon",
    "weblate.addons.removal.RemoveComments",
    "weblate.addons.removal.RemoveSuggestions",
    "weblate.addons.resx.ResxUpdateAddon",
    "weblate.addons.autotranslate.AutoTranslateAddon",
    "weblate.addons.yaml.YAMLCustomizeAddon",
    "weblate.addons.cdn.CDNJSAddon",
    # Add-on you want to include
    "weblate.addons.example.ExampleAddon",
)

Bemerkung

Wenn Sie die Erweiterung aus der Liste entfernen, wird es nicht aus den Komponenten deinstalliert. Weblate wird in diesem Fall abstürzen. Bitte deinstallieren Sie die Erweiterung aus allen Komponenten, bevor Sie es aus dieser Liste entfernen.

Siehe auch

Erweiterungen, DEFAULT_ADDONS

WEBLATE_EXPORTERS#

Neu in Version 4.2.

Liste der verfügbaren Exporter, die das Herunterladen von Übersetzungen oder Glossaren in verschiedenen Dateiformaten anbieten.

Siehe auch

Unterstützte Dateiformate

WEBLATE_FORMATS#

Liste der Dateiformate, die verwendet werden können.

Bemerkung

Die Standardliste enthält bereits die gängigen Formate.

Siehe auch

Unterstützte Dateiformate

WEBLATE_MACHINERY#

Neu in Version 4.13.

Liste der zur Verfügung stehenden Maschinendienste.

Siehe auch

Automatische Vorschläge konfigurieren

WEBLATE_GPG_IDENTITY#

Identität, die von Weblate zum Signieren von Git-Commits verwendet wird, zum Beispiel:

WEBLATE_GPG_IDENTITY = "Weblate <weblate@example.com>"

Der Weblate-GPG-Keyring wird nach einem passenden Schlüssel durchsucht (home/.gnupg unter DATA_DIR). Wenn er nicht gefunden wird, wird ein Schlüssel generiert, siehe Git-Commits mit GnuPG signieren für weitere Details.

Siehe auch

Git-Commits mit GnuPG signieren

WEBSITE_REQUIRED#

Legt fest, ob Projektseite beim Erstellen eines Projekts angegeben werden muss. Standardmäßig eingeschaltet, da dies für öffentliche Serverkonfigurationen geeignet ist.