Code hosting integrations¶
Weblate integrates with code hosting sites in several separate places: repository access, incoming notifications, and pushing translations back. The exact setup depends on whether you use Hosted Weblate or run your own Weblate instance, and on whether Weblate should push directly or create pull requests.
Use this page as a provider-oriented checklist. The individual setting pages remain the canonical reference for setting syntax.
Setup overview¶
Grant Weblate access to the repository.
For Hosted Weblate, add the hosted weblate user where it is available, see Tárolók elérése a Hosted Weblate szolgáltatásból.
For self-hosted Weblate, create a dedicated code hosting user and grant access using Weblate’s SSH key or an HTTPS token, see Tárolók elérése kódtároló szolgáltatásokon (GitHub, GitLab, Bitbucket, Azure DevOps, …).
Configure Forráskód tároló so Weblate can clone the repository.
Configure incoming notifications so Weblate pulls changes soon after a push. The repository webhook or app must point to the matching Weblate hook URL, and the project must have Hookok engedélyezése enabled.
Decide how Weblate should push translations back:
Use Git or Mercurial and Tároló feltöltési URL to push directly.
Use a provider-specific VCS backend, such as GitHub or GitLab, to create pull or merge requests. These backends need API credentials in the Weblate settings.
Optionally set Feltöltési ág when Weblate should push to a branch in the upstream repository instead of using a fork where supported.
Változások feltöltése Weblate-ből¶
Each translation component can have a push URL set up (see Tároló feltöltési URL), and in that case Weblate will be able to push changes to the remote repository. Weblate can also be configured to automatically push changes on every commit; this is enabled by default, see Feltöltés véglegesítéskor (Push on commit).
If you do not want changes to be pushed automatically, you can push manually
under Repository maintenance or using the API via
wlc push.
In case you do not want direct pushes by Weblate, there is support for GitHub módosítási kérelmek (pull request), GitLab egyesítési kérelmek (merge request), Gitea módosítási kérelmek (pull request), Pagure egyesítési kérelmek (merge request), Azure DevOps egyesítési kérelmek (pull request), or Gerrit review requests reviews. You can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as Verziókezelő rendszer in Összetevőkonfiguráció.
Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center and Bitbucket Cloud:
Kívánt beállítás |
|||
|---|---|---|---|
Nincs feltöltés (No push) |
üres |
üres |
|
Közvetlen feltöltés (Push directly) |
SSH URL |
üres |
|
Feltöltés külön ágra (Push to separate branch) |
SSH URL |
Ágnév megadása (Branch name) |
|
Nincs feltöltés (No push) |
üres |
üres |
|
Közvetlen feltöltés (Push directly) |
SSH URL |
üres |
|
GitHub módosítási kérelem külső másolatból (pull request from fork) |
üres |
üres |
|
GitHub módosítási kérelem saját ágról (pull request from branch) |
SSH URL [1] |
Ágnév megadása (Branch name) |
|
GitLab egyesítési kérelem külső másolatból (merge request from fork) |
üres |
üres |
|
GitLab egyesítési kérelem saját ágról (merge request from branch) |
SSH URL [1] |
Ágnév megadása (Branch name) |
|
Gitea egyesítési kérelem külső másolatból (merge request from fork) |
üres |
üres |
|
Gitea egyesítési kérelem saját ágról (merge request from branch) |
SSH URL [1] |
Ágnév megadása (Branch name) |
|
Pagure egyesítési kérelem külső másolatból (merge request from fork) |
üres |
üres |
|
Pagure egyesítési kérelem saját ágról (merge request from branch) |
SSH URL [1] |
Ágnév megadása (Branch name) |
|
Azure DevOps módosítási kérelem külső másolatból (pull request from fork) |
üres |
üres |
|
Azure DevOps módosítási kérelem saját ágról (pull request from branch) |
SSH URL [1] |
Ágnév megadása (Branch name) |
|
Gerrit review |
SSH URL |
Target branch name (optional) |
|
Bitbucket Data Center módosítási kérelem külső másolatból (pull request from fork) |
üres |
üres |
|
Bitbucket Data Center módosítási kérelem saját ágról (pull request from branch) |
SSH URL [1] |
Ágnév megadása (Branch name) |
|
Bitbucket Cloud módosítási kérelem külső másolatból (pull request from fork) |
üres |
üres |
|
Bitbucket Cloud módosítási kérelem saját ágról (pull request from branch) |
SSH URL [1] |
Ágnév megadása (Branch name) |
GitHub¶
GitHub repository access¶
There are two main approaches to accessing GitHub repositories with Weblate:
Option 1: HTTPS with personal access token
Use HTTPS authentication with a personal access token and your GitHub account. This works for both read-only access and read-write access.
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 are starting with Weblate or working with a single repository.
Option 2: SSH with a dedicated user
For setups with multiple repositories, 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, for example
weblate-bot.Add Weblate’s public SSH key to this user, see Weblate SSH-kulcs.
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.
Megjegyzés
When using GitHub for pull requests, the Feltöltési ág 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.
GitHub notifications¶
A Weblate natív támogatást nyújt a GitHubhoz.
If you are using Hosted Weblate, the recommended approach is to install the Weblate app. The app delivers GitHub notifications to Hosted Weblate, so you do not need to configure a separate Webhook in GitHub. However, it does not by itself grant Hosted Weblate write access to the repository. To push changes back, you still need to add the Hosted Weblate weblate GitHub user as a collaborator with write access, see Tárolók elérése a Hosted Weblate szolgáltatásból.
If you are not using the app, add the Weblate webhook in the repository settings (Webhooks) to receive notifications on every push to a GitHub repository, as shown on the image below:
A Payload URL (adatküldési URL) a Weblate címe után /hooks/github/ útvonallal bővül, például Hosted Weblate esetén: https://hosted.weblate.org/hooks/github/.
You can leave other values at default settings. Weblate can handle both content types and consumes just the push event.
GitHub módosítási kérelmek (pull request)¶
Ez egy vékony réteget ad a Git fölé, a GitHub API segítségével, amely lehetővé teszi, hogy a fordítási változások módosítási kérelemként kerüljenek feltöltésre, ne közvetlenül a tárolóba.
Git pushes changes directly to a repository, while the GitHub backend creates pull requests. The latter is not needed for merely accessing Git repositories.
To create pull requests, select GitHub as
Verziókezelő rendszer and configure GITHUB_CREDENTIALS. For
GitHub.com, use
api.github.com as the API host. The token must allow Weblate to read and
write repository contents and create pull requests. If Weblate should fork
private repositories, the token might also need administration access.
GitLab¶
GitLab repository access¶
Access via SSH is possible, see SSH-tárolók, but if you need to access more than one repository, you will hit a GitLab limitation on allowed SSH key usage because each key can be used only once.
Ha a Feltöltési ág nincs beállítva, a projekt egy másolatba (fork) kerül, és a módosítások ezen a másolaton keresztül kerülnek feltöltésre. Ha be van állítva, a módosítások közvetlenül a forrás tárolóba és a megadott ágra lesznek feltöltve.
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 a username. For a 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 a non-blank value:
https://example:project_access_token@gitlab.com/example/example.git.
Megjegyzés
The rules for using project access tokens have 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.
GitLab notifications¶
Weblate has support for GitLab hooks. Add a project webhook with destination
to /hooks/gitlab/ URL on your Weblate installation, for example
https://hosted.weblate.org/hooks/gitlab/.
Hibaelhárítás
Check GitLab webhook request history if webhooks are delivered.
The response payload contains information about matched components.
GitLab egyesítési kérelmek (merge request)¶
This adds a thin layer atop Git using the GitLab API to allow pushing translation changes as merge requests instead of pushing directly to the repository.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while the GitLab backend creates a merge request.
To create merge requests, select GitLab as
Verziókezelő rendszer and configure GITLAB_CREDENTIALS.
Gitea, Forgejo, and Codeberg¶
For Hosted Weblate repositories on Codeberg, add the hosted weblate user where write access is needed, see Tárolók elérése a Hosted Weblate szolgáltatásból.
Gitea notifications¶
Weblate has support for Gitea webhooks. Add a Gitea Webhook for
Push events event with destination to /hooks/gitea/ URL on your
Weblate installation, for example https://hosted.weblate.org/hooks/gitea/.
This can be done in Webhooks under repository Settings.
Forgejo notifications¶
Weblate has support for Forgejo webhooks. Add a Forgejo Webhook
for Push events event with destination to /hooks/forgejo/ URL
on your Weblate installation, for example
https://hosted.weblate.org/hooks/forgejo/. This can be done in
Webhooks under repository Settings.
Gitea módosítási kérelmek (pull request)¶
Added in version 4.12.
This adds a thin layer atop Git using the Gitea API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while the Gitea backend creates pull requests.
To create pull requests, select Gitea as
Verziókezelő rendszer and configure GITEA_CREDENTIALS.
Bitbucket¶
Hosted Weblate has a dedicated weblate user for Bitbucket access, see Tárolók elérése a Hosted Weblate szolgáltatásból.
To push directly, use Git or Mercurial with Tároló feltöltési URL.
Bitbucket notifications¶
Weblate has support for Bitbucket webhooks. Add a webhook which triggers upon
repository push, with destination to /hooks/bitbucket/ URL on your Weblate
installation, for example https://hosted.weblate.org/hooks/bitbucket/.
Bitbucket Data Center módosítási kérelmek (pull request)¶
Added in version 4.16.
This adds a thin layer atop Git using the Bitbucket Data Center API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Figyelem
Ez nem támogatja a Bitbucket Cloud API-t.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while the Bitbucket Data Center backend creates a pull request.
To create pull requests, select Bitbucket Data Center as
Verziókezelő rendszer and configure BITBUCKETSERVER_CREDENTIALS.
Bitbucket Cloud módosítási kérelmek (pull request)¶
Added in version 5.8.
This adds a thin layer atop Git using the Bitbucket Cloud API to allow pushing translation changes as pull requests instead of pushing directly to the repository.
Figyelem
Ez eltér a Bitbucket Data Center API-tól.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while the Bitbucket Cloud backend creates a pull request.
To create pull requests, select Bitbucket Cloud as
Verziókezelő rendszer and configure BITBUCKETCLOUD_CREDENTIALS.
Azure DevOps¶
Azure Repos notifications¶
Weblate has support for Azure Repos webhooks. Add a webhook for
Code pushed event with destination to /hooks/azure/ URL on your
Weblate installation, for example https://hosted.weblate.org/hooks/azure/.
This can be done in Service hooks under Project
settings.
Azure DevOps egyesítési kérelmek (pull request)¶
Ez egy vékony réteget ad a Git fölé, az Azure DevOps API használatával, hogy a fordítási módosításokat közvetlen feltöltés helyett, egyesítési kérelemként lehessen beküldeni.
Git pushes changes directly to a repository, while the Azure DevOps backend creates pull requests. The latter is not needed for merely accessing Git repositories.
To create pull requests, select Azure DevOps as
Verziókezelő rendszer and configure AZURE_DEVOPS_CREDENTIALS.
Pagure¶
Pagure notifications¶
Weblate has support for Pagure hooks. Add a webhook with destination to
/hooks/pagure/ URL on your Weblate installation, for example
https://hosted.weblate.org/hooks/pagure/. This can be done in
Activate Web-hooks under Project options:
Pagure egyesítési kérelmek (merge request)¶
Added in version 4.3.2.
This adds a thin layer atop Git using the Pagure API to allow pushing translation changes as merge requests instead of pushing directly to the repository.
There is no need to use this to access Git repositories, ordinary Git works the same, the only difference is how pushing to a repository is handled. With Git changes are pushed directly to the repository, while the Pagure backend creates a merge request.
To create merge requests, select Pagure as
Verziókezelő rendszer and configure PAGURE_CREDENTIALS.
Other workflows¶
Gitee notifications¶
Weblate has support for Gitee webhooks. Add a WebHook for
Push event with destination to /hooks/gitee/ URL on your
Weblate installation, for example https://hosted.weblate.org/hooks/gitee/.
This can be done in WebHooks under repository
Management.
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 Feltöltési ág setting selects the target branch for
the Gerrit review. Leave it empty to use Tároló ág. Use the short
branch name, such as main; Weblate and git-review push the review to
refs/for/<branch> automatically. Do not include Gerrit push options such as
%submit or %l=Code-Review+2 in the branch name.
The Gerrit documentation has the details on the configuration necessary to set up such repositories. There is no separate code hosting credential setting for this backend.
Docker credentials¶
For Docker installations, code hosting API credentials can also be provided through environment variables, see Kódtároló oldalak hitelesítő adatai.