Integration der Versionsverwaltung¶
Weblate currently supports Git (with extended support for GitHub-Pull-Requests, GitLab-Merge-Requests, Gitea-Pull-Requests, Gerrit review requests, Subversion, Bitbucket-Cloud-Pull-Requests, Bitbucket-Data-Center-Pull-Requests, and Azure-DevOps-Pull-Requests) and Mercurial as version control back-ends.
For provider-specific setup steps that combine repository access, incoming notifications, and pushing translations back, see Code-Hosting-Integrationen.
Auf Repositorys zugreifen¶
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.
Auf Repositorys von Hosted Weblate zugreifen¶
Bemerkung
Dieser Abschnitt gilt nur für Hosted Weblate (hosted.weblate.org). Wenn Sie Ihre eigene, selbst gehostete Weblate-Instanz betreiben, lesen Sie bitte stattdessen den nächsten Abschnitt.
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.
On GitHub, you need to add or invite the Hosted Weblate weblate user with write access even when you use the Hosted Weblate GitHub app. The app handles incoming notifications from GitHub, but pushing changes back still uses the Hosted Weblate weblate user.
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).
Auf Repositorys von Code-Hosting-Sites zugreifen (GitHub, GitLab, Bitbucket, Azure DevOps, …)¶
Bemerkung
Dieser Abschnitt gilt für selbst gehostete Weblate-Instanzen. Wenn Sie Hosted Weblate (hosted.weblate.org) verwenden, lesen Sie stattdessen Auf Repositorys von Hosted Weblate zugreifen.
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 an 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
On GitHub, each key can only be used once, see GitHub repository access and Auf Repositorys von Hosted Weblate zugreifen.
Weblate speichert auch den Fingerabdruck des Hostschlü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¶
Detailed GitHub repository access is covered in GitHub repository access.
GitLab-Repositorys¶
Detailed GitLab repository access is covered in GitLab repository access.
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 einer passenden Repository-Einrichtung 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/….
Proxy verwenden¶
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 Auf Repositorys zugreifen 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¶
Detailed GitHub pull request setup is covered in GitHub-Pull-Requests.
GitLab-Merge-Requests¶
Detailed GitLab merge request setup is covered in GitLab-Merge-Requests.
Gitea-Pull-Requests¶
Detailed Gitea pull request setup is covered in Gitea-Pull-Requests.
Bitbucket-Data-Center-Pull-Requests¶
Detailed Bitbucket Data Center pull request setup is covered in Bitbucket-Data-Center-Pull-Requests.
Bitbucket-Cloud-Pull-Requests¶
Detailed Bitbucket Cloud pull request setup is covered in Bitbucket-Cloud-Pull-Requests.
Pagure-Merge-Requests¶
Detailed Pagure merge request setup is covered in Pagure-Merge-Requests.
Gerrit¶
Detailed Gerrit review request setup is covered in Gerrit review requests.
Azure-DevOps-Pull-Requests¶
Detailed Azure DevOps pull request setup is covered in Azure-DevOps-Pull-Requests.
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 Auf Repositorys zugreifen 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.