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-Server-Pull-Request, und Azure-DevOps-Pull-Request) 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¶
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 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 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, …)¶
Der Zugriff auf Repositorys von Code-Hosting-Sites erfolgt in der Regel durch das Erstellen eines speziellen Benutzers, der mit einem SSH-Schlüssel von Weblate verknüpft ist (siehe Weblate-SSH-Schlüssel). Auf diese Weise verknüpfen Sie den SSH-Schlüssel von Weblate mit einem einzigen Benutzer (dies wird häufig von der Plattform erzwungen) und gewähren diesem Benutzer Zugriff auf das Repository. Sie können dann die SSH-URL für den Zugriff auf das Repository verwenden (siehe SSH-Repositorys).
Hinweis
Bei einem Hosted Weblate ist dies für die meisten öffentlichen Plattformen vorkonfiguriert, siehe Zugriff auf Repositorys über Hosted Weblate.
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¶
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 GitHub-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.
Für kleinere Bereitstellungen verwenden Sie die HTTPS-Authentifizierung mit einem persönlichen Token und Ihrem GitHub-Benutzerkonto, siehe Creating an access token for command-line use.
Bei größeren Installationen ist es in der Regel besser, einen eigenen Benutzer für Weblate zu erstellen, ihm den in Weblate erstellten öffentlichen SSH-Schlüssel zuzuweisen (siehe Weblate-SSH-Schlüssel) und ihm Zugang zu allen Repositorys zu gewähren, die Sie übersetzen wollen. Dieser Ansatz wird auch für Hosted Weblate verwendet, dafür gibt es einen eigenen weblate-Benutzer.
Siehe auch
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 Haupt(referenzierten) Komponente.
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¶
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 „.
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.12 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.
Git-Remote-Helfer¶
Sie können auch Git remote helpers verwenden, um zusätzlich andere Versionsverwaltungen zu unterstützen, aber seien Sie darauf vorbereitet, dass dies zu Problemen bei der Fehlersuche führen kann.
Derzeit sind Hilfsprogramme für Bazaar und Mercurial in separaten Repositorys auf GitHub verfügbar: git-remote-hg und git-remote-bzr. Laden Sie diese manuell herunter und fügen Sie sie irgendwo in Ihren Suchpfad ein (zum Beispiel ~/bin). Stellen Sie sicher, dass Sie die entsprechenden Versionsverwaltungen installiert haben.
Sobald Sie dies installiert haben, können solche Remote-Repositorys verwendet werden, um ein Repository in Weblate anzugeben.
So klonen Sie das Projekt gnuhello von Launchpad mit Bazaar:
bzr::lp:gnuhello
Für das Repository hello von selenic.com mit Mercurial:
hg::http://selenic.com/repo/hello
Warnung
Der Nachteil beim Verwenden von Git-Remote-Helfern ist, dass zum Beispiel bei Mercurial der Remote-Helfer manchmal einen neuen Tipp erstellt, wenn er Änderungen zurückpusht.
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.
Siehe auch
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.
Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, 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.
Siehe auch
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.
Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, 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.
Siehe auch
Bitbucket-Server-Pull-Request¶
Added in version 4.16.
Dies fügt eine dünne Schicht über Git unter Verwendung der Bitbucket Server 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.
Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, das gewöhnliche Git funktioniert genauso, der einzige Unterschied ist, wie das Pushen zu einem Repository gehandhabt wird. Mit Bitbucket-Server-Pull-Request werden Änderungen direkt in das Repository gepusht, während Gitea-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 Server 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.
Es besteht keine Notwendigkeit, dies für den Zugriff auf Git-Repositorys zu verwenden, 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.
Siehe auch
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-Request¶
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-Request 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.