Optionale Weblate-Module

Für Ihre Einrichtung sind mehrere optionale Module verfügbar.

Git-Exporter

Ermöglicht Ihnen den Nur-Lese-Zugriff auf das zugrunde liegende Git-Repository über HTTP(S).

Installation

  1. weblate.gitexport zu den installierten Anwendungen in settings.py hinzufügen:

    INSTALLED_APPS += ("weblate.gitexport",)

  2. Vorhandene Repositorys exportieren, indem Sie Ihre Datenbank nach der Installation migrieren:

    weblate migrate

Hinweis

Der Git-Exporter ist in unserem offiziellen Docker-Image aktiviert. Um ihn auszuschalten, verwenden Sie:

WEBLATE_REMOVE_APPS=weblate.gitexport

Anwendung

Das Modul klinkt sich automatisch in Weblate ein und setzt die exportierte Repository-URL in der Komponentenkonfiguration. Die Repositorys sind unter dem /git/-Teil der Weblate-URL zugänglich, zum Beispiel https://example.org/git/weblate/main/.

Repositorys für öffentlich zugängliche Projekte können ohne Authentifizierung geklont werden:

git clone 'https://example.org/git/weblate/main/'

Um die Repositorys mit eingeschränktem Zugriff zu durchsuchen (mit Projektzugriffssteuerung auf Privat oder wenn REQUIRE_LOGIN aktiviert ist), ist ein API-Token erforderlich, das Sie in Ihrem Benutzerprofil erhalten können:

git clone 'https://user:KEY@example.org/git/weblate/main/'

Bemerkung

Weblate serves the Git repository itself, but it does not serve Git LFS objects. For repositories using Git LFS, clone from the upstream repository and add Weblate as another remote. If you only need Git-tracked files, you can clone from Weblate with GIT_LFS_SKIP_SMUDGE=1 to skip downloading Git LFS objects.

Hinweis

Standardmäßig haben Mitglieder der Gruppe Benutzer und anonyme Benutzer über die Rollen Auf Repository zugreifen und Hauptbenutzer Zugriff auf die Repositorys für öffentliche Projekte.

Abrechnung

Dies wird auf Hosted Weblate verwendet, um Abrechnungspläne festzulegen, Rechnungen und Nutzungsgrenzen nachzuverfolgen.

Installation

1. Add weblate.billing to installed apps in settings.py:

INSTALLED_APPS += ("weblate.billing",)

  1. Die Datenbankmigration ausführen, um optional zusätzliche Datenbankstrukturen für das Modul zu installieren:

weblate migrate

Abrechnungsmodell erstellen und zuweisen

Um die Abrechnung zu aktivieren, müssen Sie zunächst ein Abrechnungsmodell erstellen. Navigieren Sie zum Abschnitt Verwaltung (dargestellt durch das Schraubenschlüssel-Symbol) und öffnen Sie den Bildschirm Werkzeuge. Von dort aus gelangen Sie zur Adminoberfläche von Django.

Suchen Sie in der Adminoberfläche von Django den Abschnitt BILLING und fügen Sie ein Abrechnungsmodell hinzu. Sie können zum Beispiel ein kostenloses Modell hinzufügen.

Wenn Sie einem bestehenden Projekt ein Abrechnungsmodell zuweisen möchten, können Sie dies auch im Django admin interface mit der Option Customer billings tun.

Schließlich bietet das Django admin interface die Option Invoice, um die Zahlungen Ihrer Kunden zu protokollieren.

Anwendung

Nach der Installation können Sie die Abrechnung in der Adminoberfläche steuern. Benutzer mit aktivierter Abrechnung erhalten einen neuen Reiter Abrechnung in ihrem Benutzerprofil.

Das Abrechnungsmodul ermglicht es Benutzern außerdem, neue Projekte und Komponenten zu erstellen, ohne Superuser zu sein (siehe Übersetzungsprojekte und Komponenten hinzufügen). Dies ist möglich, wenn die folgenden Bedingungen erfüllt sind:

  • Die Abrechnung liegt innerhalb der konfigurierten Grenzen (jede Überschreitung führt zu einer Sperrung der Projekt-/Komponentenerstellung) und ist bezahlt (wenn der Preis nicht Null ist)

  • Der Benutzer hat die Berechtigung Projekte zum Arbeitsbereich hinzufügen für den Arbeitsbereich, der unter das Abrechnungsmodell fällt.

Bei der Projekterstellung kann der Benutzer auswählen, in welchem Arbeitsbereich das Projekt angelegt werden soll. Projekte, die in einem Arbeitsbereich mit Abrechnung erstellt werden, werden auf das diesem Arbeitsbereich zugewiesenen Abrechnungsmodell angerechnet. Benutzer mit der Berechtigung Arbeitsbereicheinstellungen bearbeiten können das Abrechnungsmodell einsehen und bezahlen; an diese Benutzer werden Benachrichtigungs-E-Mails für die Abrechnung verschickt. Siehe Abrechnung für weitere Informationen.

Avatare

Avatare werden standardmäßig heruntergeladen und serverseitig zwischengespeichert, um Informationslecks zu den Websites, die sie anbieten, zu reduzieren. Die integrierte Unterstützung für das Abrufen von Avataren von E-Mail-Adressen, die dafür konfiguriert sind, kann mit ENABLE_AVATARS deaktiviert werden.

Weblate unterstützt derzeit:

Siehe auch

Lokalisierungs-CDN

Die Erweiterungen JavaScript-Lokalisierungs-CDN und Übersetzungsdateien-CDN schreiben Dateien auf LOCALIZE_CDN_PATH; Weblate stellt diese nicht bereit. Konfigurieren Sie den Webserver oder das CDN, das LOCALIZE_CDN_URL bereitstellt, als öffentlichen, schreibgeschützten Host für statische Dateien.

Behandeln Sie jede veröffentlichte CDN-Datei als öffentlich. Die spezifische UUID der Erweiterung in der URL ist kein Mechanismus zur Zugriffssteuerung. Aktivieren Sie keine CDN-Erweiterungen für Komponenten, die private Zeichenketten, unveröffentlichte Produkttexte, Kundendaten, interne URLs, API-Beispiele, Repository-Pfade, Übersetzerkommentare oder Dateiformat-Metadaten enthalten, die nicht offengelegt werden sollten.

Die Erweiterung Übersetzungsdateien-CDN veröffentlicht rohe Übersetzungsdateien in von Weblate unterstützten Formaten. Einige Formate können von Browsern oder anderen Clients als HTML, SVG, XML, JavaScript, YAML oder anwendungsspezifische Konfiguration interpretiert werden. Stellen Sie das CDN über eine eigene Domain bereit, die von Weblate und der Anwendung, welche die Übersetzungen nutzt, getrennt ist. Geben Sie keine Authentifizierungs-Cookies an die CDN-Domain weiter.

Empfohlene Serverkonfiguration:

  • Nur das von LOCALIZE_CDN_PATH konfigurierte Verzeichnis bereitstellen; keine Repositorys, Sicherungen, Medien, Konfigurationen oder das gesamte Datenverzeichnis von Weblate offenlegen.

  • Verzeichnisauflistung deaktivieren.

  • HTTPS verwenden und den CDN-Host vom Webserver als schreibgeschützt einrichten.

  • X-Content-Type-Options mit nosniff senden.

  • Konservative MIME-Typen konfigurieren. Unbekannte Übersetzungsformate als text/plain oder application/octet-stream bereitstellen; nur weblate.js als JavaScript bereitstellen.

  • Für rohe Übersetzungsformate, die nicht für die Darstellung in einem Browser vorgesehen sind, sollte Content-Disposition mit attachment hinzugefügt werden.

  • Access-Control-Allow-Origin nur für Seiten konfigurieren, die Browserzugriff auf die Dateien benötigen.

  • Cache-Lebensdauern festlegen, die den Erwartungen hinsichtlich der Aktualisierung entsprechen, und CDN-Caches leeren, wenn veraltete Übersetzungen schnell entfernt werden müssen.

Der folgende nginx-Ausschnitt stellt nur das konfigurierte CDN-Verzeichnis bereit und wendet konservative Standardwerte für rohe Übersetzungsdateien an:

weblate/examples/weblate.nginx.cdn.conf
#
# nginx configuration for the Weblate localization CDN
#
# You will want to change:
#
# - server_name to match the host configured in LOCALIZE_CDN_URL
# - root to match LOCALIZE_CDN_PATH
# - Access-Control-Allow-Origin to the sites that need browser access
# - TLS configuration if HTTPS is not terminated before nginx
#
server {
    listen 80;
    server_name cdn.example.com;

    # LOCALIZE_CDN_PATH
    root /home/weblate/data/l10n-cdn;

    autoindex off;
    disable_symlinks on;

    location = / {
        return 404;
    }

    # The JavaScript localization add-on publishes this loader.
    location ~ "^/[0-9a-f]{32}/weblate\.js$" {
        try_files $uri =404;

        types {
            application/javascript js;
        }
        default_type application/javascript;

        add_header X-Content-Type-Options nosniff always;
        # add_header Access-Control-Allow-Origin "https://www.example.com" always;

        expires 1h;
    }

    # Other CDN files are translation files. Serve them conservatively so raw
    # formats are not interpreted as active browser content.
    location / {
        try_files $uri =404;

        types {
        }
        default_type text/plain;

        add_header X-Content-Type-Options nosniff always;
        add_header Content-Disposition "attachment" always;
        # add_header Access-Control-Allow-Origin "https://www.example.com" always;

        expires 1h;
    }
}

Siehe auch

Git-Commits mit GnuPG signieren

Alle Commits können mit dem GnuPG-Schlüssel der Weblate-Instanz signiert werden.

  • Schalten Sie WEBLATE_GPG_IDENTITY ein. (Weblate erzeugt bei Bedarf einen GnuPG-Schlüssel und verwendet ihn zum Signieren aller Commits von Übersetzungen.)

    Für diese Funktion muss GnuPG 2.1 oder neuer installiert sein.

    Sie finden den Schlüssel in DATA_DIR und der öffentliche Schlüssel wird auf der „Über Weblate“-Seite angezeigt:

    ../_images/about-gpg.webp

  • Alternativ können Sie auch bestehende Schlüssel in Weblate importieren, indem Sie beim Aufruf von gpg HOME=$DATA_DIR/home setzen.

Hinweis

Das Schlüsselmaterial wird von Weblate über einen längeren Zeitraum zwischengespeichert. Falls Sie Weblate einen Schlüssel mit WEBLATE_GPG_IDENTITY erzeugen lassen und dann einen Schlüssel mit der gleichen Identität importieren, um einen bestehenden Schlüssel zu verwenden, wird empfohlen, den Redis-Cache zu leeren, um die Auswirkungen einer solchen Änderung zu sehen.

Bemerkung

Wenn Sie DATA_DIR zwischen mehreren Rechnern teilen, befolgen Sie bitte die Anweisungen unter https://wiki.gnupg.org/NFS, damit das Signieren mit GnuPG zuverlässig funktioniert.

Siehe auch

WEBLATE_GPG_IDENTITY

Ratenbegrenzung

Geändert in Version 4.6: Die Ratenbegrenzung gilt nicht mehr für angemeldete Superuser.

Mehrere Vorgänge in Weblate sind ratenbegrenzt. Innerhalb von RATELIMIT_WINDOW Sekunden sind maximal RATELIMIT_ATTEMPTS Versuche erlaubt. Danach wird der Benutzer für RATELIMIT_LOCKOUT gesperrt. Es gibt auch bereichsspezifische Einstellungen, zum Beispiel RATELIMIT_CONTACT_ATTEMPTS oder RATELIMIT_TRANSLATE_ATTEMPTS. Die nachstehende Tabelle enthält eine vollständige Liste der verfügbaren Bereiche.

Die folgenden Vorgänge unterliegen der Ratenbegrenzung:

Bezeichnung

Bereich

Erlaubte Versuche

Ratenbegrenzungsfenster

Sperrdauer

Registrierung

REGISTRATION

5

300

600

Nachricht an Administratoren senden

MESSAGE

2

300

600

Passwort-Authentifizierung beim Anmelden

LOGIN

5

300

600

Zwei-Faktor-Authentifizierung

SECOND_FACTOR

5

300

600

Plattformweite Suche

SEARCH

6

60

60

Übersetzen

TRANSLATE

30

60

600

Zum Glossar hinzufügen

GLOSSARY

30

60

600

Beginn der Übersetzung in eine neue Sprache

LANGUAGE

2

300

600

Neues Projekt erstellen

PROJECT

5

600

600

Die Ratenbegrenzung basiert auf Sitzungen, wenn der Benutzer angemeldet ist, und andernfalls auf der IP-Adresse.

Wenn die Anmeldung eines Benutzers nicht innerhalb von AUTH_LOCK_ATTEMPTS erfolgt, wird die Passwortauthentifizierung für das Konto deaktiviert, bis das Passwort zurückgesetzt wurde.

Die Einstellungen können auch im Docker-Container angewandt werden, indem der Präfix WEBLATE_ an den Einstellungsnamen angehängt wird, z. B. wird RATELIMIT_ATTEMPTS zu WEBLATE_RATELIMIT_ATTEMPTS.

Die API verfügt über separate Einstellungen zur Ratenbegrenzung, siehe API-Ratenbegrenzung.

Siehe auch