Code-Hosting-Integrationen¶

Weblate lässt sich an mehreren Stellen mit Code-Hosting-Sites integrieren: Repository-Zugriff, eingehende Benachrichtigungen und Zurückpushen von Übersetzungen. Die genaue Einrichtung hängt davon ab, ob Sie Hosted Weblate nutzen oder eine eigene Weblate-Instanz betreiben, und davon, ob Weblate direkt pushen oder Pull Requests erstellen soll.

Verwenden Sie diese Seite als Checkliste für Anbieter. Die einzelnen Einstellungsseiten bleiben die maßgebliche Referenz für die Einstellungssyntax.

Einrichtungsübersicht¶

Weblate Zugriff auf das Repository gewähren.
- Für Hosted Weblate den gehosteten weblate-Benutzer hinzufügen, wenn er verfügbar ist, siehe Auf Repositorys von Hosted Weblate zugreifen.
- Für ein selbst gehostetes Weblate einen dedizierten Code-Hosting-Benutzer erstellen und ihm Zugriff mit dem SSH-Schlüssel von Weblate oder einem HTTPS-Token gewähren, siehe Auf Repositorys von Code-Hosting-Sites zugreifen (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Quellcode-Repository konfigurieren, damit Weblate das Repository klonen kann.
Eingehende Benachrichtigungen so konfigurieren, dass Weblate Änderungen kurz nach einem Push zieht. Der Repository-Webhook oder die App muss auf die entsprechende Weblate-Hook-URL verweisen, und für das Projekt muss Hooks aktivieren eingeschaltet sein.
Wie Weblate Übersetzungen zurückpushen soll:
- Git oder Mercurial und Repository-Push-URL verwenden, um direkt zu pushen.
- Ein anbieterspezifisches VCS-Backend, wie GitHub oder GitLab verwenden, um Pull oder Merge Requests zu erstellen. Diese Backends benötigen API-Zugangsdaten in den Weblate-Einstellungen.
Optional Push-Branch einsetzen, wenn Weblate zu einem Branch im Upstream-Repository pushen soll, anstatt einen Fork zu verwenden, sofern unterstützt.

Änderungen aus Weblate pushen¶

Für jede Übersetzungskomponente kann eine Push-URL eingerichtet werden (siehe Repository-Push-URL), und in diesem Fall kann Weblate Änderungen an das Remote-Repository pushen. Weblate kann auch so konfiguriert werden, dass Änderungen automatisch bei jedem Commit gepusht werden; dies ist standardmäßig aktiviert, siehe Bei Commit gleichzeitig Pushen.

Wenn Sie nicht möchten, dass Änderungen automatisch gepusht werden, können Sie manuell unter Repository-Wartung oder über die API via wlc push pushen.

Falls Sie kein direktes Pushen durch Weblate möchten, gibt es Unterstützung für GitHub-Pull-Requests, GitLab-Merge-Requests, Gitea-Pull-Requests, Pagure-Merge-Requests, Azure-DevOps-Pull-Requests oder Gerrit-Review-Requests. Sie können diese aktivieren, indem Sie GitHub, GitLab, Gitea, Gerrit, Azure DevOps oder Pagure als Versionsverwaltung in der Komponentenkonfiguration auswählen.

Insgesamt sind folgende Optionen mit Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center und Bitbucket Cloud verfügbar:

Gewünschte Einrichtung	Versionsverwaltung	Repository-Push-URL	Push-Branch
Kein Push	Git	leer	leer
Direkt pushen	Git	SSH-URL	leer
Push zu separatem Branch	Git	SSH-URL	Branch-Name
Kein Push	Mercurial	leer	leer
Direkt pushen	Mercurial	SSH-URL	leer
GitHub-Pull-Request vom Fork	GitHub-Pull-Requests	leer	leer
GitHub-Pull-Request vom Branch	GitHub-Pull-Requests	SSH-URL [1]	Branch-Name
GitLab-Merge-Request vom Fork	GitLab-Merge-Requests	leer	leer
GitLab-Merge-Request vom Branch	GitLab-Merge-Requests	SSH-URL [1]	Branch-Name
Gitea-Merge-Request vom Fork	Gitea-Pull-Requests	leer	leer
Gitea-Merge-Request vom Branch	Gitea-Pull-Requests	SSH-URL [1]	Branch-Name
Pagure-Merge-Request vom Fork	Pagure-Merge-Requests	leer	leer
Pagure-Merge-Request vom Branch	Pagure-Merge-Requests	SSH-URL [1]	Branch-Name
Azure-DevOps-Pull-Request vom Fork	Azure-DevOps-Pull-Requests	leer	leer
Azure-DevOps-Pull-Request vom Branch	Azure-DevOps-Pull-Requests	SSH-URL [1]	Branch-Name
Gerrit-Review	Gerrit-Review-Requests	SSH-URL	Ziel-Branch-Name (optional)
Bitbucket-Data-Center-Pull-Request vom Fork	Bitbucket-Data-Center-Pull-Requests	leer	leer
Bitbucket-Data-Center-Pull-Request vom Branch	Bitbucket-Data-Center-Pull-Requests	SSH-URL [1]	Branch-Name
Bitbucket-Cloud-Pull-Request vom Fork	Bitbucket-Cloud-Pull-Requests	leer	leer
Bitbucket-Cloud-Pull-Request vom Branch	Bitbucket-Cloud-Pull-Requests	SSH-URL [1]	Branch-Name

GitHub¶

GitHub-Repository-Zugriff¶

HTTPS mit persönlichem Zugangstoken¶

For a single private repository, HTTPS access with an access token is usually the simplest setup when the provider supports Git over HTTPS. Use the provider-required username and token in Quellcode-Repository.

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

Um diesen Ansatz zu verwenden:

Ein persönliches Zugangstoken erstellen, wie in Creating an access token for command-line use beschrieben.
Das Token in die Repository-URL einfügen: https://username:token@github.com/owner/repo.git.

Dies eignet sich, wenn Sie mit Weblate beginnen oder mit einem einzelnen Repository arbeiten.

SSH mit einem eigenen Benutzer¶

For setups with multiple repositories, use SSH access with a dedicated code hosting user for Weblate. Add Weblate’s public SSH key to that user, grant the user access to the repositories, and use SSH URLs in Quellcode-Repository, for example git@example.com:group/project.git.

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

This also avoids provider restrictions on SSH key reuse. Some code hosting sites allow a public SSH key to be added only once, or only to a single user or deploy key entry. Keeping Weblate’s SSH key on a dedicated user lets that user be granted access to multiple repositories without reusing the key in several places.

This keeps personal, project, or API access tokens out of repository URLs. Provider API credentials are still needed when using a provider-specific VCS backend to create pull or merge requests; those credentials are configured separately from the Git repository URL.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Auf Repositorys von Hosted Weblate zugreifen.

Für GitHub erstellen Sie einen eigenen Benutzer, z. B. weblate-bot, und verwenden Sie GitHub-SSH-URLs für Ihre Repositorys, z. B. git@github.com:owner/repo.git.

Dieser Ansatz wird auch für Hosted Weblate verwendet, das zu diesem Zweck einen eigenen Benutzer weblate hat.

Bemerkung

Beim Verwenden von GitHub für Pull Requests wirkt sich die Push-Branch-Konfiguration auf das Verhalten aus: Wenn sie nicht gesetzt ist, wird das Projekt geforkt und die Änderungen werden durch einen Fork gepusht. Wenn sie gesetzt ist, werden die Änderungen in das Upstream-Repository und den ausgewählten Branch gepusht.

GitHub-Benachrichtigungen¶

Weblate bietet native Unterstützung für GitHub.

Wenn Sie Hosted Weblate verwenden, empfiehlt sich die Installation der Weblate-App. Die App liefert GitHub-Benachrichtigungen an Hosted Weblate, so dass Sie keinen separaten Webhook in GitHub konfigurieren müssen. Allerdings gewährt sie Hosted Weblate nicht von sich aus Schreibzugriff auf das Repository. Um Änderungen zurückzupushen, müssen Sie immer noch den Hosted-Weblate-GitHub-Benutzer weblate als Mitwirkenden mit Schreibzugriff hinzufügen, siehe Auf Repositorys von Hosted Weblate zugreifen.

Wenn Sie die App nicht verwenden, fügen Sie den Weblate-Webhook in den Repository-Einstellungen hinzu (Webhooks), um bei jedem Pushen eines GitHub-Repositorys Benachrichtigungen zu erhalten, wie auf dem Bild unten gezeigt:

Die Payload URL besteht aus Ihrer Weblate-URL, an die /hooks/github/ angehängt wird, für den Hosted-Weblate-Dienst ist dies zum Beispiel https://hosted.weblate.org/hooks/github/.

Sie können die anderen Werte auf den Standardeinstellungen belassen. Weblate kann beide Inhaltstypen verarbeiten und verwendet nur das Push-Ereignis.

Siehe auch

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 das GitHub-Backend Pull Requests erstellt. Letzteres wird für den bloßen Zugriff auf Git-Repositorys nicht benötigt.

Um Pull Requests zu erstellen, wählen Sie GitHub als Versionsverwaltung aus und konfigurieren Sie GITHUB_CREDENTIALS. Für GitHub.com, verwenden Sie api.github.com als API-Host. Das Token muss Weblate erlauben, Repository-Inhalte zu lesen und zu schreiben und Pull Requests zu erstellen. Wenn Weblate private Repositorys forken soll, benötigt das Token eventuell auch Administrationszugriff.

GitLab¶

GitLab-Repository-Zugriff¶

HTTPS mit persönlichem oder projektbezogenem Zugangstoken¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

Für GitLab benötigt das Token die Berechtigung write_repository, um Änderungen in das Repository pushen zu können. Das Projekt-Zugangstoken erfordert die Rolle Developer, um Änderungen pushen zu können.

Die URL muss einen Benutzernamen enthalten. Für ein persönliches Zugangstoken ist es der tatsächliche Benutzername: https://user:personal_access_token@gitlab.com/example/example.git. Für Projekt-Zugangstoken kann es ein nicht leerer Wert sein: https://example:project_access_token@gitlab.com/example/example.git.

Bemerkung

Die Regeln für das Verwenden von Projekt-Zugangstoken haben sich zwischen den verschiedenen GitLab-Versionen geändert. Der nicht-leere Wert ist die aktuelle Anforderung, aber ältere Versionen hatten andere Erwartungen (Projektname, Bot-Benutzername). Prüfen Sie im Zweifelsfall die zu Ihrer Version passende GitLab-Dokumentation.

SSH mit einem eigenen Benutzer¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Auf Repositorys von Hosted Weblate zugreifen.

Für GitLab erstellen Sie einen eigenen Benutzer und verwenden GitLab-SSH-URLs, z. B. git@gitlab.com:group/project.git.

GitLab-Benachrichtigungen¶

Weblate unterstützt GitLab-Hooks. Fügen Sie einen Projekt-Webhook mit der Ziel-URL /hooks/gitlab/ auf Ihrer Weblate-Installation hinzu, zum Beispiel https://hosted.weblate.org/hooks/gitlab/.

Fehlerbehebung

Überprüfen Sie den GitLab-Webhook-Request-Verlauf darauf, ob Webhooks geliefert werden.
Die Nutzdaten der Antwort enthalten Informationen über übereinstimmende Komponenten.

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.

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 das GitLab-Backend einen Merge Request erstellt.

Um Merge Requests zu erstellen, wählen Sie GitLab als Versionsverwaltung aus und konfigurieren Sie GITLAB_CREDENTIALS.

Die Push-Branch-Konfiguration beeinflusst, wohin Weblate Änderungen pusht, bevor der Merge Request geöffnet wird. Wenn sie nicht gesetzt ist, wird das Projekt geforkt und die Änderungen werden durch einen Fork gepusht. Wenn sie gesetzt ist, werden die Änderungen in das Upstream-Repository und den ausgewählten Branch gepusht.

Gitea, Forgejo, und Codeberg¶

Gitea-, Forgejo-, und Codeberg-Repository-Zugriff¶

HTTPS mit einem Zugangstoken¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH mit einem eigenen Benutzer¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Auf Repositorys von Hosted Weblate zugreifen.

Für Hosted-Weblate-Repositorys auf Codeberg fügen Sie den gehosteten weblate-Benutzer hinzu, wenn Sie Schreibrechte benötigen, siehe Auf Repositorys von Hosted Weblate zugreifen.

Gitea-Benachrichtigungen¶

Weblate unterstützt Gitea-Webhooks. Fügen Sie einen Gitea Webhook für das Push events-Ereignis mit der Ziel-URL /hooks/gitea/ auf Ihrer Weblate-Installation hinzu, zum Beispiel https://hosted.weblate.org/hooks/gitea/. Dies kann in Webhooks unter Repository Settings erfolgen.

Siehe auch

Forgejo-Benachrichtigungen¶

Weblate unterstützt Forgejo-Webhooks. Fügen Sie einen Forgejo Webhook für das Push events-Ereignis mit der Ziel-URL /hooks/gitea/ auf Ihrer Weblate-Installation hinzu, zum Beispiel https://hosted.weblate.org/hooks/forgejo/. Dies kann in Webhooks unter Repository Settings erfolgen.

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.

Um Pull Requests zu erstellen, wählen Sie Gitea als Versionsverwaltung aus und konfigurieren Sie GITEA_CREDENTIALS.

Bitbucket¶

Bitbucket-Repository-Zugriff¶

HTTPS mit einem Zugangstoken¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH mit einem eigenen Benutzer¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Auf Repositorys von Hosted Weblate zugreifen.

Hosted Weblate hat einen eigenen weblate-Benutzer für den Bitbucket-Zugang, siehe Auf Repositorys von Hosted Weblate zugreifen.

Um direkt zu pushen, verwenden Sie Git oder Mercurial mit Repository-Push-URL.

Bitbucket-Benachrichtigungen¶

Weblate unterstützt Bitbucket-Webhooks. Fügen Sie einen Webhook, der bei einem Repository-Push ausgelöst wird, mit der Ziel-URL /hooks/bitbucket/ auf Ihrer Weblate-Installation hinzu, zum Beispiel https://hosted.weblate.org/hooks/bitbucket/.

Siehe auch

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 das Bitbucket Data Center-Backend einen Pull Request erstellt.

Um Pull Requests zu erstellen, wählen Sie Bitbucket Data Center als Versionsverwaltung aus und konfigurieren Sie BITBUCKETSERVER_CREDENTIALS.

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.

Um Pull Requests zu erstellen, wählen Sie Bitbucket Cloud als Versionsverwaltung aus und konfigurieren Sie BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Azure-Repos-Repository-Zugriff¶

HTTPS mit einem Zugangstoken¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

Verwenden Sie die von Azure Repos angezeigte HTTPS-Klon-URL für das Repository.

SSH mit einem eigenen Benutzer¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Auf Repositorys von Hosted Weblate zugreifen.

Verwenden Sie die von Azure Repos angezeigte SSH-URL für das Repository.

Azure-Repos-Benachrichtigungen¶

Weblate unterstützt Azure-Repos-Webhooks. Fügen Sie einen Webhook für das Ereignis Code pushed mit der Ziel-URL /hooks/azure/ auf Ihrer Weblate-Installation hinzu, zum Beispiel https://hosted.weblate.org/hooks/azure/. Dies kann in Service hooks unter Project settings erfolgen.

Siehe auch

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 das Azure DevOps-Backend Pull Requests erstellt. Letzteres wird für den bloßen Zugriff auf Git-Repositorys nicht benötigt.

Um Pull Requests zu erstellen, wählen Sie Azure DevOps als Versionsverwaltung aus und konfigurieren Sie AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Pagure-Repository-Zugriff¶

HTTPS mit einem Zugangstoken¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH mit einem eigenen Benutzer¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Auf Repositorys von Hosted Weblate zugreifen.

Pagure-Benachrichtigungen¶

Weblate unterstützt Pagure-Hooks. Fügen Sie einen Webhook mit der Ziel-URL /hooks/pagure/ auf Ihrer Weblate-Installation hinzu, zum Beispiel https://hosted.weblate.org/hooks/pagure/. Dies kann in Activate Web-hooks unter Project options erfolgen:

Siehe auch

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.

Um Merge Requests zu erstellen, wählen Sie Pagure als Versionsverwaltung aus und konfigurieren Sie PAGURE_CREDENTIALS.

Andere Arbeitsabläufe¶

Gitee-Repository-Zugriff¶

HTTPS mit einem Zugangstoken¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

The token needs read access for cloning and write access for pushing. Provider-specific VCS backends that create pull or merge requests might require separate API credentials.

SSH mit einem eigenen Benutzer¶

Configure Repository-Push-URL only when Weblate should push changes directly or when the chosen workflow requires a push URL, see Änderungen aus Weblate pushen.

On Hosted Weblate, use the hosted weblate user on supported code hosting sites, see Auf Repositorys von Hosted Weblate zugreifen.

Gitee-Benachrichtigungen¶

Weblate unterstützt Gitee-Webhooks. Fügen Sie einen WebHook für das Push-Ereignis mit der Ziel-URL /hooks/gitee/ auf Ihrer Weblate-Installation hinzu, zum Beispiel https://hosted.weblate.org/hooks/gitee/. Dies kann in WebHooks unter Repository Management erfolgen.

Siehe auch

Gerrit-Review-Requests¶

Gerrit support adds a thin layer atop Git using the git-review tool to allow pushing translation changes as Gerrit review requests, instead of pushing them directly to the repository.

The optional Push-Branch setting selects the target branch for the Gerrit review. Leave it empty to use Repository-Branch. Use the short branch name, such as main; Weblate and git-review push the review to refs/for/<branch> automatically. Gerrit push options can be appended after % in either setting, for example main%topic=l10n. Gerrit interprets these options as the configured Weblate Gerrit account and applies its own permissions.

Die Gerrit-Dokumentation enthält Einzelheiten zur Konfiguration, die für die Einrichtung solcher Repositorys erforderlich ist. Für dieses Backend gibt es keine separate Einstellung für Zugangsdaten zum Code-Hosting.

Docker-Zugangsdaten¶

Bei Docker-Installationen können die Zugangsdaten für die Code-Hosting-API auch über Umgebungsvariablen bereitgestellt werden, siehe Zugangsdaten für Code-Hosting-Sites.