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.

Troubleshooting repository URLs¶

Weblate validates repository and push URLs before connecting. HTTPS and SSH are permitted by default; instance administrators can adjust this using VCS_ALLOW_SCHEMES.

Repository hostnames have to resolve from the Weblate server. When VCS_RESTRICT_PRIVATE is enabled, Weblate also rejects destinations which resolve to internal or otherwise non-public addresses. Use a publicly reachable repository URL where possible. For an intentionally private repository on a trusted network, ask the instance administrator to add its hostname to VCS_ALLOW_HOSTS.

Git over HTTPS and SSH can bind connections to addresses approved during validation. Backends which cannot do this safely, including Mercurial and Subversion, require the trusted repository hostname in VCS_ALLOW_HOSTS while private-address restrictions are enabled.

Configure the final repository URL directly when possible. Weblate can automatically accept a permanent HTTP redirect only when it stays on the same host and the target is successfully validated. Redirects to another host or protocol have to be configured manually.

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.

For GitHub repositories on Hosted Weblate, use the Hosted Weblate app from Weblate’s Connect GitHub account flow whenever possible. The App grants repository access, receives incoming notifications, pushes translation branches, and creates pull requests without inviting the Hosted Weblate weblate user. See GitHub-Repository-Zugriff for the full setup.

For direct SSH access outside the GitHub App workflow, and for Bitbucket, Codeberg, and GitLab repositories, Hosted Weblate has a dedicated push user (with the username weblate, e-mail hosted@weblate.org, and a name or profile description 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.

The weblate user on GitHub accepts invitations automatically within five minutes when you intentionally use direct SSH access there. Manual processing might be needed on the other services, so please be patient.

For this direct SSH-user setup, once the weblate user is added to your repository, you can configure Quellcode-Repository and Repository-Push-URL using the SSH protocol, for example git@example.com:group/project.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, a single private repository is often easiest to set up using an HTTPS repository URL with an access token, see Code-Hosting-Integrationen.

For multiple repositories, create a dedicated code-hosting user associated with a Weblate SSH key (see Weblate-SSH-Schlüssel). This way you associate Weblate SSH key with a single user, because platforms frequently enforce single use of an SSH key. Grant this user access to the repositories, and use SSH URLs to access them (see SSH-Repositorys).

SSH-Repositorys¶

One common method to access private repositories is based on SSH. Authorize the public Weblate SSH key (see Weblate-SSH-Schlüssel) to access the upstream repository this way.

Warnung

Auf GitHub kann jeder Schlüssel nur einmal verwendet werden, siehe GitHub-Repository-Zugriff und 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.

When VCS_RESTRICT_PRIVATE is enabled, Weblate resolves and validates the repository host before scanning its key and connects ssh-keyscan only to the approved addresses. The stored key remains associated with the original hostname.

For Git connections, Weblate also applies HostName and Port from DATA_DIR/ssh/config before validating and pinning the effective destination. SSH configuration and SSH_EXTRA_ARGS are trusted administrator-controlled inputs. They can alter connection routing, and SSH_EXTRA_ARGS can override Weblate’s address pinning; administrators are responsible for their effects.

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 möchten (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¶

Weblate suppresses the OpenSSH warning about connections without post-quantum key exchange so that it does not obscure repository errors. This does not change algorithm negotiation: post-quantum key exchange is still used when supported by both the client and server. Other SSH warnings remain enabled. Upgrade or configure the SSH server to support post-quantum key exchange to protect against „store now, decrypt later“ attacks.

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¶

Ausführliche Informationen zum GitHub-Repository-Zugriff finden Sie unter GitHub-Repository-Zugriff.

GitLab-Repositorys¶

Ausführliche Informationen zum GitLab-Repository-Zugriff finden Sie unter GitLab-Repository-Zugriff.

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.

Linked components share the complete repository checkout; the link does not isolate them to particular files or directories. Users allowed to administer a linked component can configure operations affecting files anywhere in the shared checkout. For example, they can change file masks, formats, and templates, or install and configure add-ons that read, generate, or modify repository files. Weblate can commit and push resulting changes using the main component’s repository configuration.

Only link components when the repository owner trusts the administrators of every linked component with the complete checkout. Use separate repositories when components require file-level isolation.

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 über einen Proxy-Server per HTTPS auf Git-Repositorys zugreifen müssen, konfigurieren Sie die protokollspezifischen Umgebungsvariablen, die unter HTTP-Proxy beschrieben sind.

Versionsverwaltungsparameter¶

Added in version 2026.9.

Versionsverwaltungsparameter legen fest, wie eine Komponente mit ihrem Repository interagiert, ohne dass eine andere Versionsverwaltung gewählt werden muss. Sie werden pro Komponente in Versionsverwaltungsparameter konfiguriert, und es werden nur die Parameter angezeigt, die für die ausgewählte Versionsverwaltung relevant sind.

Liste der Versionsverwaltungsparameter¶

Parametername	Versionsverwaltungen	Label	Hilfetext
create_merge_request	`azure_devops` `bitbucketcloud` `bitbucketserver` `gitea` `github` `github-app` `gitlab` `pagure`	Merge Requests erstellen	Erstellen Sie einen Pull oder Merge Request für die Übersetzungsänderungen. Ist dies deaktiviert, pusht Weblate die Änderungen direkt in den übersetzten Branch, wofür Schreibzugriff auf diesen erforderlich ist.
git_force_push	`git`	Push erzwingen	Überschreiben Sie den Remote-Branch, anstatt das Pushen von Änderungen, die nicht im Fast-Forward-Modus erfolgen, abzulehnen. Verwenden Sie diese Option nur bei einem Repository, das ausschließlich für Übersetzungen vorgesehen ist, da dabei Upstream Commits verworfen werden, die in Weblate nicht vorhanden sind.
merge_request_automerge	`github` `github-app`	Pull Requests automatisch zusammenführen	Aktivieren Sie das automatische Zusammenführen auf GitHub für von Weblate erstellte Pull Requests, damit diese zusammengeführt werden, sobald die erforderlichen Qualitätsprüfungen bestanden sind. Pull Requests, bei denen keine Wartezeiten anfallen, werden sofort zusammengeführt.
merge_request_merge_method	`github` `github-app`	Merge-Methode	Methode, die beim automatischen Zusammenführen von Pull Requests verwendet wird. Das Repository muss dies zulassen. Verfügbare Auswahlmöglichkeiten: `merge` – Einen Merge Commit erstellen `squash` – Zusammenfassen und zusammenführen `rebase` – Umbasieren und zusammenführen

Git¶

Hinweis

Weblate benötigt Git 2.46 oder neuer.

Bemerkung

Weblate überprüft permanente HTTP-Weiterleitungen, die innerhalb des Repository-Hostnamens bleiben, und speichert automatisch die kanonische Repository-URL. Die Änderung wird im Komponentenverlauf als Repository-Wartung erfasst. Weiterleitungen zu einem anderen Hostnamen müssen manuell konfiguriert werden.

Siehe auch

Siehe Auf Repositorys zugreifen für Informationen darüber, wie man auf verschiedene Arten von Repositorys zugreifen kann.

Git LFS¶

Weblate does not support files tracked by Git LFS as translation files. It does not download or upload Git LFS objects. Git LFS smudging and pre-push uploads are disabled for Weblate-managed repositories, so LFS-tracked files remain pointer files. This behavior applies to every Git hosting provider.

A repository can use Git LFS for files that Weblate does not need to read or modify. The upstream repository remains the authoritative source for these LFS objects. Clone from upstream when you need the actual files rather than their pointers because repositories served by Weblate do not include LFS objects.

For the GitLab merge request workflow, Weblate disables Git LFS in its managed fork. This prevents GitLab from rejecting pointer-only translation branches when the upstream repository added LFS objects after the fork was created. Existing managed forks are reconfigured on their next push. This does not change the Git LFS configuration of the upstream project.

Git-Submodule¶

Weblate does not populate Git submodules when cloning repositories. It does not initialize or update submodules, and it does not recurse into submodule repositories during file discovery or translation updates. Files stored inside a submodule are therefore not available to file masks when Weblate is connected to the parent repository.

If translation files live in a submodule, add the submodule repository to Weblate as its own component instead of reaching it through the parent repository. Weblate can then clone, update, commit, and push to the repository that actually stores the translation files. The parent repository only records the submodule commit pointer, so updating that pointer has to happen outside Weblate, for example in your normal development workflow or CI.

Pushen erzwingen¶

Aktivieren Sie den Versionsverwaltungsparameter git_force_push, damit Weblate immer einen Push 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.

Geändert in Version 2026.9: Früher handelte es sich hierbei um ein eigenständiges Git-Push erzwingen der Versionsverwaltung. Die bestehenden Komponenten wurden zu Git migriert, wobei der Parameter git_force_push aktiviert wurde.

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¶

Ausführliche Informationen zur GitHub-Pull-Request-Einrichtung finden Sie unter GitHub-Pull-Requests.

GitLab-Merge-Requests¶

Ausführliche Informationen zur GitLab-Merge-Request-Einrichtung finden Sie unter GitLab-Merge-Requests.

Gitea-Pull-Requests¶

Ausführliche Informationen zur Gitea-Pull-Request-Einrichtung finden Sie unter Gitea-Pull-Requests.

Bitbucket-Data-Center-Pull-Requests¶

Ausführliche Informationen zur Bitbucket-Data-Center-Pull-Request-Einrichtung finden Sie unter Bitbucket-Data-Center-Pull-Requests.

Bitbucket-Cloud-Pull-Requests¶

Ausführliche Informationen zur Bitbucket-Cloud-Pull-Request-Einrichtung finden Sie unter Bitbucket-Cloud-Pull-Requests.

Pagure-Merge-Requests¶

Ausführliche Informationen zur Pagure-Merge-Request-Einrichtung finden Sie unter Pagure-Merge-Requests.

Gerrit¶

Ausführliche Informationen zur Gerrit-Review-Request-Einrichtung finden Sie unter Gerrit-Review-Requests.

Azure-DevOps-Pull-Requests¶

Ausführliche Informationen zur Azure-DevOps-Pull-Request-Einrichtung finden Sie unter 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

DATA_DIR

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.