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 புரவலன் செய்யப்பட்ட வலைபெயர்ப்புடிலிருந்து களஞ்சியங்களை அணுகுவது.
- For self-hosted Weblate, create a dedicated code hosting user and grant access using Weblate's SSH key or an HTTPS token, see குறியீடு ஓச்டிங் தளங்களில் களஞ்சியங்களை அணுகுவது (கிதுப், அறிவிலிஆய்வு, பிட்பக்கெட், அசூர் டெவொப்ச், ...).
Configure மூல குறியீடு களஞ்சியம் 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 கொக்கிகள் இயக்கவும் enabled.
Decide how Weblate should push translations back:
- Use அறிவிலி or மெர்குரியல் and களஞ்சியம் புச் முகவரி 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 புச் கிளை when Weblate should push to a branch in the upstream repository instead of using a fork where supported.

வலைபெயர்ப்புடிலிருந்து மாற்றங்களைத் தள்ளுகிறது¶

Each translation component can have a push URL set up (see களஞ்சியம் புச் முகவரி), 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 கமிட் மீது தள்ளுங்கள்.

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 அறிவிலிமையம் கோரிக்கைகள், அறிவிலிஆய்வு கோரிக்கைகளை ஒன்றிணைக்கவும், கிடியா இழுக்கும் கோரிக்கைகள், pagure ஒன்றிணைப்பு கோரிக்கைகள், அசூர் டெவொப்ச் கோரிக்கைகளை இழுக்கிறது, or Gerrit review requests reviews. You can activate these by choosing GitHub, GitLab, Gitea, Gerrit, Azure DevOps, or Pagure as பதிப்பு கட்டுப்பாட்டு அமைப்பு in கூறு உள்ளமைவு.

Overall, following options are available with Git, Mercurial, GitHub, GitLab, Gitea, Pagure, Azure DevOps, Gerrit, Bitbucket Data Center and Bitbucket Cloud:

விரும்பிய அமைப்பு	பதிப்பு கட்டுப்பாட்டு அமைப்பு	களஞ்சியம் புச் முகவரி	புச் கிளை
புச் இல்லை	அறிவிலி	வெற்று	வெற்று
நேரடியாக தள்ளுங்கள்	அறிவிலி	பாஓடு முகவரி	வெற்று
தனி கிளைக்கு தள்ளுங்கள்	அறிவிலி	பாஓடு முகவரி	கிளை பெயர்
புச் இல்லை	மெர்குரியல்	வெற்று	வெற்று
நேரடியாக தள்ளுங்கள்	மெர்குரியல்	பாஓடு முகவரி	வெற்று
ஃபோர்க்கிலிருந்து அறிவிலிமையம் கோரிக்கை	அறிவிலிமையம் கோரிக்கைகள்	வெற்று	வெற்று
கிளையிலிருந்து அறிவிலிமையம் இழுத்தல்	அறிவிலிமையம் கோரிக்கைகள்	பாஓடு முகவரி [1]	கிளை பெயர்
ஃபோர்க்கிலிருந்து அறிவிலிஆய்வு ஒன்றிணைப்பு கோரிக்கையை ஒன்றிணைக்கவும்	அறிவிலிஆய்வு கோரிக்கைகளை ஒன்றிணைக்கவும்	வெற்று	வெற்று
அறிவிலிஆய்வு கிளையிலிருந்து கோரிக்கையை ஒன்றிணைக்கவும்	அறிவிலிஆய்வு கோரிக்கைகளை ஒன்றிணைக்கவும்	பாஓடு முகவரி [1]	கிளை பெயர்
அறிவிலிதேநீர் fork இலிருந்து கோரிக்கையை ஒன்றிணைக்கிறது	கிடியா இழுக்கும் கோரிக்கைகள்	வெற்று	வெற்று
அறிவிலிதேநீர் கிளையில் இருந்து கோரிக்கையை ஒன்றிணைக்கிறது	கிடியா இழுக்கும் கோரிக்கைகள்	பாஓடு முகவரி [1]	கிளை பெயர்
ஃபோர்க்கிலிருந்து pagure ஒன்றிணைப்பு கோரிக்கை	pagure ஒன்றிணைப்பு கோரிக்கைகள்	வெற்று	வெற்று
பேசூர் கிளையிலிருந்து ஒன்றிணைக்கும் கோரிக்கை	pagure ஒன்றிணைப்பு கோரிக்கைகள்	பாஓடு முகவரி [1]	கிளை பெயர்
அசூர் டெவொப்ச் ஃபோர்க்கிலிருந்து கோரிக்கையை இழுக்கிறார்	அசூர் டெவொப்ச் கோரிக்கைகளை இழுக்கிறது	வெற்று	வெற்று
அசூர் டெவொப்ச் கிளையிலிருந்து கோரிக்கையை இழுக்கிறது	அசூர் டெவொப்ச் கோரிக்கைகளை இழுக்கிறது	பாஓடு முகவரி [1]	கிளை பெயர்
Gerrit review	Gerrit review requests	பாஓடு முகவரி	Target branch name (optional)
ஃபோர்க்கிலிருந்து பிட்பக்கெட் தரவு நடுவண் இழுக்க வேண்டும்	பிட்பக்கெட் தரவு நடுவண் கோரிக்கைகளை இழுக்கவும்	வெற்று	வெற்று
பிட்பக்கெட் தரவு நடுவண் கிளையிலிருந்து கோரிக்கை	பிட்பக்கெட் தரவு நடுவண் கோரிக்கைகளை இழுக்கவும்	பாஓடு முகவரி [1]	கிளை பெயர்
ஃபோர்க்கிலிருந்து பிட்பக்கெட் முகில் புல் கோரிக்கை	பிட்பக்கெட் முகில் புல் கோரிக்கைகள்	வெற்று	வெற்று
பிட்பக்கெட் முகில் புல் கோரிக்கை கிளையிலிருந்து	பிட்பக்கெட் முகில் புல் கோரிக்கைகள்	பாஓடு முகவரி [1]	கிளை பெயர்

கிதப்¶

GitHub repository access¶

HTTPS with personal access token¶

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 மூல குறியீடு களஞ்சியம்.

Configure களஞ்சியம் புச் முகவரி only when Weblate should push changes directly or when the chosen workflow requires a push URL, see வலைபெயர்ப்புடிலிருந்து மாற்றங்களைத் தள்ளுகிறது.

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.

இந்த அணுகுமுறையைப் பயன்படுத்த:

கமாண்ட்-லைன் பயன்பாட்டிற்கான அணுகல் கிள்ளாக்கை உருவாக்குதல் இல் விவரிக்கப்பட்டுள்ளபடி தனிப்பட்ட அணுகல் கிள்ளாக்கை உருவாக்கவும்.
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.

SSH with a dedicated user¶

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 மூல குறியீடு களஞ்சியம், for example git@example.com:group/project.git.

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 புரவலன் செய்யப்பட்ட வலைபெயர்ப்புடிலிருந்து களஞ்சியங்களை அணுகுவது.

For GitHub, create a dedicated user, for example weblate-bot, and use GitHub SSH URLs for your repositories, for example git@github.com:owner/repo.git.

இந்த அணுகுமுறை புரவலன் செய்யப்பட்ட வெப்லேட்டிற்கும் பயன்படுத்தப்படுகிறது, அந்த நோக்கத்திற்காக பிரத்யேக weblate பயனரைக் கொண்டுள்ளது.

Note

When using GitHub for pull requests, the புச் கிளை 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¶

வலைபெயர்ப்பு கிதுபுக்கு சொந்த ஆதரவுடன் வருகிறது.

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 புரவலன் செய்யப்பட்ட வலைபெயர்ப்புடிலிருந்து களஞ்சியங்களை அணுகுவது.

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:

Payload URL ஆனது, /hooks/github/ மூலம் இணைக்கப்பட்ட உங்கள் வலைபெயர்ப்பு முகவரி ஐக் கொண்டுள்ளது, எடுத்துக்காட்டாக, புரவலன் செய்யப்பட்ட வலைபெயர்ப்பு சேவைக்கு, இது 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.

See also

அறிவிலிமையம் கோரிக்கைகள்¶

இது நேரடியாக களஞ்சியத்திற்குத் தள்ளுவதற்குப் பதிலாக, இழுக்கும் கோரிக்கைகளாக மொழிபெயர்ப்பு மாற்றங்களைத் தள்ள அனுமதிக்க GitHub API ஐப் பயன்படுத்தி அறிவிலி மேல் ஒரு மெல்லிய அடுக்கைச் சேர்க்கிறது.

அறிவிலி 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 பதிப்பு கட்டுப்பாட்டு அமைப்பு 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 repository access¶

HTTPS with personal or project access token¶

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.

For GitLab, 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.

Note

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.

SSH with a dedicated user¶

For GitLab, create a dedicated user and use GitLab SSH URLs, for example git@gitlab.com:group/project.git.

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/.

சரிசெய்தல்

வெப்ஊக்குகள் டெலிவரி செய்யப்பட்டிருந்தால், GitLab webhook கோரிக்கை வரலாறு ஐச் சரிபார்.
பதில் பேலோடில் பொருந்திய கூறுகள் பற்றிய தகவல்கள் உள்ளன.

See also

அறிவிலிஆய்வு கோரிக்கைகளை ஒன்றிணைக்கவும்¶

This adds a thin layer atop அறிவிலி 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 அறிவிலி works the same, the only difference is how pushing to a repository is handled. With அறிவிலி changes are pushed directly to the repository, while the GitLab backend creates a merge request.

To create merge requests, select GitLab as பதிப்பு கட்டுப்பாட்டு அமைப்பு and configure GITLAB_CREDENTIALS.

The புச் கிளை configuration affects where Weblate pushes changes before opening the merge request. If it is not set, the project is forked and changes are pushed through a fork. If it is set, changes are pushed to the upstream repository and chosen branch.

Gitea, Forgejo, and Codeberg¶

Gitea, Forgejo, and Codeberg repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

For Hosted Weblate repositories on Codeberg, add the hosted weblate user where write access is needed, see புரவலன் செய்யப்பட்ட வலைபெயர்ப்புடிலிருந்து களஞ்சியங்களை அணுகுவது.

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.

See also

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.

See also

கிடியா இழுக்கும் கோரிக்கைகள்¶

Added in version 4.12.

This adds a thin layer atop அறிவிலி using the Gitea API to allow pushing translation changes as pull requests instead of pushing directly to the repository.

To create pull requests, select Gitea as பதிப்பு கட்டுப்பாட்டு அமைப்பு and configure GITEA_CREDENTIALS.

பிட்பக்கெட்¶

Bitbucket repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

Hosted Weblate has a dedicated weblate user for Bitbucket access, see புரவலன் செய்யப்பட்ட வலைபெயர்ப்புடிலிருந்து களஞ்சியங்களை அணுகுவது.

To push directly, use அறிவிலி or மெர்குரியல் with களஞ்சியம் புச் முகவரி.

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/.

See also

பிட்பக்கெட் தரவு நடுவண் கோரிக்கைகளை இழுக்கவும்¶

Added in version 4.16.

This adds a thin layer atop அறிவிலி using the Bitbucket Data Center API to allow pushing translation changes as pull requests instead of pushing directly to the repository.

Warning

இது பிட்பக்கெட் முகில் பநிஇ ஐ ஆதரிக்காது.

To create pull requests, select Bitbucket Data Center as பதிப்பு கட்டுப்பாட்டு அமைப்பு and configure BITBUCKETSERVER_CREDENTIALS.

பிட்பக்கெட் முகில் புல் கோரிக்கைகள்¶

Added in version 5.8.

This adds a thin layer atop அறிவிலி using the Bitbucket Cloud API to allow pushing translation changes as pull requests instead of pushing directly to the repository.

Warning

இது பிட்பக்கெட் தரவு மைய பநிஇ இலிருந்து வேறுபட்டது.

To create pull requests, select Bitbucket Cloud as பதிப்பு கட்டுப்பாட்டு அமைப்பு and configure BITBUCKETCLOUD_CREDENTIALS.

Azure DevOps¶

Azure Repos repository access¶

HTTPS with an access token¶

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.

Use the HTTPS clone URL shown by Azure Repos for the repository.

SSH with a dedicated user¶

Use the SSH URL shown by Azure Repos for the repository.

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.

See also

அசூர் டெவொப்ச் கோரிக்கைகளை இழுக்கிறது¶

இது நேரடியாக களஞ்சியத்திற்குத் தள்ளுவதற்குப் பதிலாக, இழுக்கும் கோரிக்கைகளாக மொழிபெயர்ப்பு மாற்றங்களைத் தள்ள அனுமதிக்க Azure DevOps API ஐப் பயன்படுத்தி அறிவிலி மேல் ஒரு மெல்லிய அடுக்கைச் சேர்க்கிறது.

அறிவிலி 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 பதிப்பு கட்டுப்பாட்டு அமைப்பு and configure AZURE_DEVOPS_CREDENTIALS.

Pagure¶

Pagure repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

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:

See also

pagure ஒன்றிணைப்பு கோரிக்கைகள்¶

Added in version 4.3.2.

This adds a thin layer atop அறிவிலி using the Pagure API to allow pushing translation changes as merge requests instead of pushing directly to the repository.

To create merge requests, select Pagure as பதிப்பு கட்டுப்பாட்டு அமைப்பு and configure PAGURE_CREDENTIALS.

Other workflows¶

Gitee repository access¶

HTTPS with an access token¶

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 with a dedicated user¶

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.

See also

Gerrit review requests¶

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

The optional புச் கிளை setting selects the target branch for the Gerrit review. Leave it empty to use களஞ்சிய கிளை. 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 குறியீடு ஓச்டிங் தளங்களின் சான்றுகள்.