Integration der Versionsverwaltung¶
Weblate unterstützt derzeit Git (mit erweiterter Unterstützung für GitHub-Pull-Requests, GitLab-Merge-Requests, Gitea-Pull-Requests, Gerrit, Subversion, Bitbucket-Cloud-Pull-Requests, Bitbucket-Data-Center-Pull-Requests und Azure-DevOps-Pull-Requests) und Mercurial als Versionsverwaltung-Backends.
Zugriff auf Repositorys¶
Das VCS-Repository, das Sie verwenden möchten, muss für Weblate zugänglich sein. Bei einem öffentlich zugänglichen Repository müssen Sie nur die korrekte URL eingeben (z. B. https://github.com/WeblateOrg/weblate.git), aber für private Repositorys oder für Push-URLs ist die Einrichtung komplexer und erfordert eine Authentifizierung.
Zugriff auf Repositorys über Hosted Weblate¶
Bemerkung
This section applies only to Hosted Weblate (hosted.weblate.org). If you are running your own self-hosted Weblate instance, please see the next section instead.
Für Hosted Weblate gibt es einen dedizierten Push-Benutzer, der auf GitHub, Bitbucket, Codeberg und GitLab registriert ist (mit dem Benutzernamen weblate, der E-Mail-Adresse hosted@weblate.org und einem Namen oder einer Profilbeschreibung Weblate push user).
Hinweis
Auf den Plattformen kann es weitere Benutzer von Weblate geben, die für andere Weblate-Instanzen bestimmt sind. Es wird empfohlen, nach der E-Mail-Adresse hosted@weblate.org zu suchen, um den richtigen Benutzer für Hosted Weblate zu finden.
Sie müssen diesen Benutzer als Mitwirkenden hinzufügen und ihm die entsprechenden Berechtigungen für Ihr Repository erteilen (für das Klonen reicht ein Lesezugriff aus, für das Pushen ist ein Schreibzugriff erforderlich). Je nach Dienst und den Einstellungen Ihrer Organisation geschieht dies sofort oder erfordert eine Bestätigung auf der Weblate-Seite.
Der Benutzer weblate auf GitHub nimmt Einladungen automatisch innerhalb von fünf Minuten an. Bei den anderen Diensten kann eine manuelle Bearbeitung erforderlich sein, also haben Sie bitte etwas Geduld.
Sobald der Benutzer weblate zu Ihrem Repository hinzugefügt wurde, können Sie das Quellcode-Repository und die Repository-Push-URL über das SSH-Protokoll konfigurieren (zum Beispiel git@github.com:WeblateOrg/weblate.git).
Zugriff auf Repositorys von Code-Hosting-Sites (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Bemerkung
This section applies to self-hosted Weblate instances. If you are using Hosted Weblate (hosted.weblate.org), see Zugriff auf Repositorys über Hosted Weblate instead.
For self-hosted Weblate, accessing repositories on code hosting sites is typically done by creating a dedicated user who is associated with a Weblate SSH key (see Weblate-SSH-Schlüssel). This way you associate Weblate SSH key with a single user (platforms frequently enforce single use of a SSH key) and grant this user access to the repository. You can then use SSH URL to access the repository (see SSH-Repositorys).
SSH-Repositorys¶
Die am häufigsten verwendete Methode, um auf private Repositorys zuzugreifen, basiert auf SSH. Autorisieren Sie den öffentlichen Weblate-SSH-Schlüssel (siehe Weblate-SSH-Schlüssel), um auf diese Weise auf das Upstream-Repository zuzugreifen.
Warnung
Auf GitHub kann jeder Schlüssel nur einmal verwendet werden, siehe GitHub-Repositorys und Zugriff auf Repositorys über Hosted Weblate.
Weblate speichert auch den Fingerabdruck des Host-Schlüssels bei der ersten Verbindung und stellt keine Verbindung zum Host her, wenn er später geändert wird (siehe SSH-Hostschlüssel überprüfen).
Falls eine Anpassung erforderlich ist, nehmen Sie diese über die Weblate-Adminoberfläche vor:
Weblate-SSH-Schlüssel¶
Geändert in Version 4.17: Weblate erzeugt jetzt sowohl RSA- als auch Ed25519-SSH-Schlüssel. Die Verwendung von Ed25519 wird für neue Installationen empfohlen.
Der öffentliche Schlüssel von Weblate ist für alle Benutzer sichtbar, welche die Seite Über Weblate besuchen.
Administratoren können den öffentlichen Schlüssel, der aktuell von Weblate in der Verbindung verwendet wird (aus SSH-Schlüssel), auf der Einstiegsseite der Adminoberfläche erzeugen oder anzeigen.
Bemerkung
Der entsprechende private SSH-Schlüssel darf derzeit kein Passwort haben, stellen Sie daher sicher, dass er gut geschützt ist.
Hinweis
Erstellen Sie eine Sicherungskopie des erzeugten privaten Weblate-SSH-Schlüssels.
SSH-Hostschlüssel überprüfen¶
Weblate speichert die SSH-Hostschlüssel beim ersten Zugriff automatisch und merkt sie sich für die weitere Verwendung.
Wenn Sie den Fingerabdruck des Schlüssels vor der Verbindung mit dem Repository überprüfen möchten, fügen Sie die SSH-Schlüssel der Server, auf die Sie zugreifen möchten, unter Hostschlüssel hinzufügen im selben Abschnitt der Adminoberfläche hinzu. Geben Sie den Rechnernamen ein, auf den Sie zugreifen wollen (z. B. gitlab.com), und drücken Sie Absenden. Überprüfen Sie, ob der Fingerabdruck mit dem von Ihnen hinzugefügten Server übereinstimmt.
Die hinzugefügten Schlüssel mit Fingerabdrücken werden in der Bestätigungsnachricht angezeigt:
Verbindung zu älteren SSH-Servern¶
Aktuelle OpenSSH-Versionen (z. B. die im Weblate-Docker-Container verwendete) deaktivieren standardmäßig RSA-Signaturen mit dem SHA-1-Hash-Algorithmus. Diese Änderung wurde vorgenommen, da der SHA-1-Hash-Algorithmus kryptografisch gebrochen ist und es möglich ist, Hash-Kollisionen mit gewählten Präfixen für unter USD$ 50k zu erstellen.
Für die meisten Benutzer sollte diese Änderung unsichtbar sein und es besteht keine Notwendigkeit, SSH-RSA-Schlüssel zu ersetzen. OpenSSH unterstützt RFC8332-RSA/SHA-256/512-Signaturen seit Version 7.2 und existierende SSH-RSA-Schlüssel werden automatisch den stärkeren Algorithmus verwenden, wenn möglich.
Inkompatibilität ist wahrscheinlicher, wenn eine Verbindung zu älteren SSH-Implementierungen hergestellt wird, die nicht aktualisiert wurden oder die Verbesserungen des SSH-Protokolls nicht genau verfolgt haben. Die SSH-Verbindung zu einem solchen Server schlägt fehl mit:
no matching host key type found. Their offer: ssh-rsa
In diesen Fällen kann es notwendig sein, RSA/SHA1 selektiv wieder zu aktivieren, um die Authentifizierung von Verbindungen und/oder Benutzern über die Optionen HostkeyAlgorithms und PubkeyAcceptedAlgorithms zu ermöglichen. Der folgende Dreizeiler in DATA_DIR/ssh/config aktiviert beispielsweise RSA/SHA1 für die Host- und Benutzer-Authentifizierung für einen einzelnen Ziel-Host:
Host legacy-host
HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
Wir empfehlen, RSA/SHA1 nur als Überbrückungsmaßnahme zu aktivieren, bis veraltete Implementierungen aktualisiert oder mit einem anderen Schlüsseltyp (wie ECDSA oder Ed25519) neu konfiguriert werden können.
GitHub-Repositorys¶
There are two main approaches to accessing GitHub repositories with Weblate:
Option 1: HTTPS with Personal Access Token (simpler for getting started)
Use HTTPS authentication with a personal access token and your GitHub account. This works for both read-only access (cloning) and read-write access (pushing changes or creating pull requests).
To use this approach:
Create a personal access token as described in Creating an access token for command-line use.
Include the token in your repository URL:
https://username:token@github.com/owner/repo.git
This is suitable when you’re starting with Weblate or working with a single repository.
Option 2: SSH with Dedicated User (recommended for multiple repositories)
For setups with multiple repositories, it is recommended to create a dedicated user for Weblate. This avoids GitHub’s limitation that each SSH key can only be used once per platform.
To use this approach:
Create a dedicated GitHub user account (e.g.,
weblate-bot)Add Weblate’s public SSH key to this user (see Weblate-SSH-Schlüssel)
Grant this user access to all repositories you want to translate
Use SSH URLs for your repositories:
git@github.com:owner/repo.git
This approach is also used for Hosted Weblate, which has a dedicated weblate user for that purpose.
Bemerkung
When using GitHub-Pull-Requests for pull requests, the Push-Branch configuration affects the behavior: if not set, the project is forked and changes are pushed through a fork. If set, changes are pushed to the upstream repository and the chosen branch.
GitLab-Repositorys¶
Der Zugriff über SSH ist möglich (siehe SSH-Repositorys), aber falls Sie auf mehr als ein Repository zugreifen müssen, stoßen Sie auf eine GitLab-Beschränkung für die Verwendung von SSH-Schlüsseln (da jeder Schlüssel nur einmal verwendet werden kann).
Falls der Push-Branch nicht gesetzt ist, wird das Projekt geforkt und die Änderungen durch einen Fork gepusht. Ist er gesetzt, werden die Änderungen an das vorgelagerte Repository und den gewählten Branch gepusht.
Using personal or project access tokens is possible as well. The token needs write_repository scope to be able to push changes to the repository. The project access token requires Developer role for pushing.
The URL needs to contain an username, for personal access token it is the
actual username (
https://user:personal_access_token@gitlab.com/example/example.git) for
project access tokens it can be non-blank value
(https://example:project_access_token@gitlab.com/example/example.git).
Bemerkung
The rules for using project access tokens has changed between GitLab releases, the non-blank value is the current requirement, but older versions had different expectations (project name, bot user name). Check GitLab documentation matching your version if unsure.
Weblate-interne URLs¶
Teilen Sie eine Repository-Einrichtung zwischen verschiedenen Komponenten, indem Sie auf seine Platzierung als weblate://project/component in anderen (verlinkten) Komponenten verweisen. Auf diese Weise verwenden verlinkte Komponenten die VCS-Repository-Konfiguration der (referenzierten) Hauptkomponente.
Warnung
Beim Entfernen der Hauptkomponente werden auch die verlinkten Komponenten entfernt.
Weblate passt die Repository-URL beim Erstellen einer Komponente automatisch an, wenn es eine Komponente mit einem passenden Repository-Setup findet. Sie können dies im letzten Schritt der Konfiguration der Komponente außer Kraft setzen.
Gründe dafür:
Spart Speicherplatz auf dem Server, das Repository wird nur einmal gespeichert.
Beschleunigt die Aktualisierungen, da nur ein Repository aktualisiert wird.
Es gibt nur ein einziges exportiertes Repository mit Weblate-Übersetzungen (siehe Git-Exporter).
Einige Erweiterungen können mit mehreren Komponenten arbeiten, die sich ein Repository teilen, zum Beispiel Git-Commits zusammenfassen.
HTTPS-Repositorys¶
Siehe auch
Um auf geschützte HTTPS-Repositorys zuzugreifen, geben Sie den Benutzernamen und das Passwort in der URL an. Keine Sorge, Weblate entfernt diese Informationen, wenn die URL den Benutzern angezeigt wird (wenn sie die URL des Repositorys überhaupt sehen dürfen).
Die GitHub-URL mit hinzugefügter Authentifizierung könnte zum Beispiel so aussehen: https://user:your_access_token@github.com/WeblateOrg/weblate.git.
Wenn Sie in der URL keine Zugangsdaten angeben und das Repository diese verlangt, schlägt Git mit einer Fehlermeldung fehl:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
Geändert in Version 5.10.2: Weblate verwendet eine proaktive Authentifizierung mit Git 2.46.0 und neuer, wenn HTTP-Zugangsdaten angegeben werden.
Dies ermöglicht den Zugriff auf Azure-DevOps-Repositorys und beschleunigt den Zugriff auf authentifizierte Repositorys.
Bemerkung
Wenn Ihr Benutzername oder Ihr Passwort Sonderzeichen enthält, müssen diese URL-kodiert sein, zum Beispiel https://user%40example.com:%24password%23@bitbucket.org/….
Verwendung eines Proxys¶
Wenn Sie auf HTTP/HTTPS-VCS-Repositorys über einen Proxyserver zugreifen müssen, konfigurieren Sie das VCS so, dass es diesen verwendet.
Dies kann mit Hilfe der Umgebungsvariablen http_proxy, https_proxy und all_proxy geschehen (wie in der cURL-Dokumentation beschrieben) oder z. B. in der VCS-Konfiguration erzwungen werden:
git config --global http.proxy http://user:password@proxy.example.com:80
Bemerkung
Die Proxy-Konfiguration muss unter dem Benutzer erfolgen, unter dem Weblate läuft (siehe auch Dateisystemberechtigungen) und mit HOME=$DATA_DIR/home (siehe DATA_DIR), sonst wird Git, das von Weblate ausgeführt wird, es nicht nutzen.
Siehe auch
Git¶
Hinweis
Weblate benötigt Git 2.28 oder neuer.
Siehe auch
Siehe Zugriff auf Repositorys für Informationen darüber, wie man auf verschiedene Arten von Repositorys zugreifen kann.
Git Push erzwingen¶
Dies verhält sich genau wie Git selbst, mit dem einzigen Unterschied, dass es immer Pushes erzwingt. Dies ist nur für den Fall vorgesehen, dass ein separates Repository für Übersetzungen verwendet wird.
Warnung
Seien Sie vorsichtig, da dies leicht zu verlorenen Commits in Ihrem Upstream-Repository führt.
Git-Konfiguration anpassen¶
Weblate ruft alle VCS-Befehle mit HOME=$DATA_DIR/home auf (siehe DATA_DIR), daher muss das Bearbeiten der Benutzer-Konfiguration in DATA_DIR/home/.git erfolgen.
GitHub-Pull-Requests¶
Dies fügt eine dünne Schicht über Git unter Verwendung der GitHub API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Git pusht Änderungen direkt in ein Repository, während GitHub-Pull-Requests Pull Requests erstellt. Letzteres wird für den bloßen Zugriff auf Git-Repositorys nicht benötigt.
Damit dies funktioniert, müssen die API-Zugangsdaten (GITHUB_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option GitHub sichtbar, wenn Versionsverwaltung ausgewählt wird.
GitLab-Merge-Requests¶
Dies fügt eine dünne Schicht über Git unter Verwendung der GitLab API hinzu, um das Pushen von Übersetzungsänderungen als Merge Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, das gewöhnliche Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen zu einem Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während GitLab-Merge-Requests einen Merge Request erstellt.
Damit dies funktioniert, müssen die API-Zugangsdaten (GITLAB_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option GitLab sichtbar, wenn Versionsverwaltung ausgewählt wird.
Gitea-Pull-Requests¶
Added in version 4.12.
Dies fügt eine dünne Schicht über Git unter Verwendung der Gitea API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, das gewöhnliche Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen zu einem Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während Gitea-Pull-Requests Pull Requests erstellt.
Damit dies funktioniert, müssen die API-Zugangsdaten (GITEA_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Gitea sichtbar, wenn Versionsverwaltung ausgewählt wird.
Bitbucket-Data-Center-Pull-Requests¶
Added in version 4.16.
Dies fügt eine dünne Schicht über Git unter Verwendung der Bitbucket-Data-Center-API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Warnung
Dies unterstützt die Bitbucket-Cloud-API nicht.
Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen in ein Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während Bitbucket-Data-Center-Pull-Requests einen Pull Request erstellt.
Damit dies funktioniert, müssen die API-Zugangsdaten (BITBUCKETSERVER_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Bitbucket Data Center sichtbar, wenn Versionsverwaltung ausgewählt wird.
Bitbucket-Cloud-Pull-Requests¶
Added in version 5.8.
Dies fügt eine dünne Schicht auf Git unter Verwendung der Bitbucket-Cloud-API hinzu, um das Pushen von Übersetzungsänderungen als Pull-Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Warnung
Dies unterscheidet sich von der Bitbucket-Data-Center-API.
Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen in ein Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während Bitbucket-Cloud-Pull-Requests einen Pull Request erstellt.
Damit dies funktioniert, müssen die API-Zugangsdaten (BITBUCKETCLOUD_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Bitbucket Cloud sichtbar, wenn Versionsverwaltung ausgewählt wird.
Pagure-Merge-Requests¶
Added in version 4.3.2.
Dies fügt eine dünne Schicht über Git unter Verwendung der Pagure API hinzu, um das Pushen von Übersetzungsänderungen als Merge Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Für den Zugriff auf Git-Repositorys ist dies nicht notwendig, das gewöhnliche Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen zu einem Repository gehandhabt wird. Mit Git werden Änderungen direkt in das Repository gepusht, während Pagure-Merge-Requests einen Merge Request erstellt.
Damit dies funktioniert, müssen die API-Zugangsdaten (PAGURE_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Pagure sichtbar, wenn Versionsverwaltung ausgewählt wird.
Gerrit¶
Dies fügt eine dünne Schicht über Git mit dem Werkzeug git-review hinzu, um das Pushen von Übersetzungsänderungen als Gerrit-Review-Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Die Gerrit-Dokumentation enthält Einzelheiten zur Konfiguration, die für die Einrichtung solcher Repositorys erforderlich ist.
Azure-DevOps-Pull-Requests¶
Dies fügt eine dünne Schicht über Git unter Verwendung der Azure DevOps API hinzu, um das Pushen von Übersetzungsänderungen als Pull Requests zu ermöglichen, anstatt sie direkt in das Repository zu pushen.
Git pusht Änderungen direkt in ein Repository, während Azure-DevOps-Pull-Requests Pull Requests erstellt. Letzteres wird für den bloßen Zugriff auf Git-Repositorys nicht benötigt.
Damit dies funktioniert, müssen die API-Zugangsdaten (AZURE_DEVOPS_CREDENTIALS) in den Weblate-Einstellungen konfiguriert werden. Nach der Konfiguration ist die Option Azure DevOps sichtbar, wenn Versionsverwaltung ausgewählt wird.
Mercurial¶
Mercurial ist eine weitere Versionsverwaltung, die Sie direkt in Weblate verwenden können.
Bemerkung
Es sollte mit jeder Mercurial-Version funktionieren, aber es gibt manchmal inkompatible Änderungen an der Befehlszeile, welche die Weblate-Integration stören.
Siehe auch
Siehe Zugriff auf Repositorys für Informationen darüber, wie man auf verschiedene Arten von Repositorys zugreifen kann.
Subversion¶
Weblate verwendet git-svn zur Interaktion mit subversion-Repositorys. Es handelt sich um ein Perl-Skript, mit dem Subversion von einem Git-Client verwendet werden kann, so dass Benutzer einen vollständigen Klon des internen Repositorys pflegen und lokal Commits durchführen können.
Bemerkung
Weblate versucht, das Layout des Subversion-Repositorys automatisch zu erkennen – es unterstützt sowohl direkte URLs für Branches als auch Repositorys mit Standardlayout (branches/, tags/ und trunk/). Mehr Informationen dazu finden Sie in der git-svn-Dokumentation. Wenn Ihr Repository kein Standardlayout hat und Sie auf Fehler stoßen, versuchen Sie, den Namen des Branches in die Repository-URL aufzunehmen und den Branch leer zu lassen.
Subversion-Zugangsdaten¶
Ihre Weblate-Installation erwartet, dass Sie das Zertifikat (und ggf. Ihre Zugangsdaten) im Voraus akzeptiert haben. Es wird versuchen, sie in das Verzeichnis DATA_DIR einzufügen. Akzeptieren Sie das Zertifikat, indem Sie einmal svn verwenden, wobei die Einsatzumgebungsvariable $HOME auf DATA_DIR gesetzt ist:
# Use DATA_DIR as configured in Weblate settings.py, it is /app/data in the Docker
HOME=${DATA_DIR}/home svn co https://svn.example.com/example
Siehe auch
Lokale Dateien¶
Hinweis
Darunter verwendet es Git. Es erfordert die Installation von Git und ermöglicht es Ihnen, Git nativ mit einem vollständigen Verlauf Ihrer Übersetzungen zu verwenden.
Weblate kann auch ohne ein Remote-VCS betrieben werden. Die ersten Übersetzungen werden durch Hochladen importiert. Später können Sie einzelne Dateien durch Dateiupload ersetzen oder Zeichenketten direkt aus Weblate hinzufügen (aktuell nur für einsprachige Übersetzungen verfügbar).
Im Hintergrund erstellt Weblate ein Git-Repository für Sie, in dem alle Änderungen nachverfolgt werden. Falls Sie sich später entscheiden, ein VCS zur Speicherung der Übersetzungen zu verwenden, haben Sie bereits ein Repository in Weblate, auf das Sie Ihre Integration stützen können.