程式碼託管整合¶

Weblate 會在多個不同環節與程式碼託管網站整合，包括儲存庫存取、傳入通知，以及將翻譯推送回儲存庫。實際設定取決於您使用 Hosted Weblate 或自行執行 Weblate 執行個體，也取決於 Weblate 應直接推送，還是建立 Pull Request 或 Merge Request。

請將本頁作為依服務提供者分類的檢查清單。各設定頁面仍是設定語法的標準參考資料。

設定概覽¶

授予儲存庫權限給 Weblate。
- 對於 Hosted Weblate 上的 GitHub 儲存庫，請從 Weblate 的連接 GitHub 帳號流程使用 Hosted Weblate app。此 App 可讓 Hosted Weblate 存取儲存庫，不必邀請 Hosted Weblate 的 weblate 使用者。
- 對於其他 Hosted Weblate 儲存庫，以及 GitHub App 工作流程以外的直接 SSH 推送，請在可用處加入 Hosted Weblate 的 weblate 使用者；請參閱從 Hosted Weblate 存取儲存庫。
- 對於自行託管的 Weblate，請建立專用的程式碼託管使用者，並使用 Weblate 的 SSH 金鑰或 HTTPS 權杖授予存取權；請參閱存取程式碼託管網站上的儲存庫（GitHub、GitLab、Bitbucket、Azure DevOps 等）。
設定原始碼儲存庫所以 Weblate 可以複製儲存庫。
設定傳入通知，讓 Weblate 在推送後盡快拉取變更。存放庫 Webhook 或應用程式必須指向相符的 Weblate 掛勾 URL，而且專案必須啟用啟用掛勾。組件的原始碼儲存庫必須與 Webhook 承載內容中的存放庫 URL 相符；請參閱比對 Webhook 目標。
決定 Weblate 應如何將翻譯推送回儲存庫：
- 使用 Git 或 Mercurial 與儲存庫推送 URL 以直接推送。
- 若要建立拉取請求或合併請求，請使用特定服務提供者的 VCS 後端，例如 GitHub 或 GitLab。這些後端需要在 Weblate 設定中提供 API 憑證。
如果 Weblate 應推送至上游儲存庫中的分支，而非在支援的情況下使用 fork，可以選擇性設定推送分支。

從 Weblate 推送變更¶

每個翻譯組件都可以設定推送 URL（請參閱儲存庫推送 URL），設定後 Weblate 就能將變更推送到遠端儲存庫。也可以將 Weblate 設定為每次提交時自動推送變更；此功能預設啟用，請參閱提交時一併推送。

如果不希望自動推送變更，可以在儲存庫維護下手動推送，或透過 API 使用 wlc push。

如果您不想由 Weblate 直接推送，我們支援 GitHub 拉取請求、 GitLab 合併請求、 Gitea 拉取請求、 Pagure 合併請求、 Azure DevOps 拉取請求或 Gerrit 檢閱請求檢閱。您可以透過在組件設定中選擇 GitHub 、 GitLab 、 Gitea 、 Gerrit 、 Azure DevOps 或 Pagure 作為版本控制系統來啟動它們。

整體而言，Git、Mercurial、GitHub、GitLab、Gitea、Pagure、Azure DevOps、Gerrit、Bitbucket Data Center 及 Bitbucket Cloud 提供下列選項：

所需設定	版本控制系統	儲存庫推送 URL	推送分支
不推送	Git	空白	空白
直接推送	Git	SSH URL	空白
推送至單獨的分支	Git	SSH URL	分支名稱
不推送	Mercurial	空白	空白
直接推送	Mercurial	SSH URL	空白
來自 fork 的 GitHub 拉取請求	GitHub 拉取請求	空白	空白
來自分支的 GitHub 拉取請求	GitHub 拉取請求	SSH URL [1]	分支名稱
來自 fork 的 GitLab 合併請求	GitLab 合併請求	空白	空白
來自分支的 GitLab 合併請求	GitLab 合併請求	SSH URL [1]	分支名稱
來自 fork 的 Gitea 合併請求	Gitea 拉取請求	空白	空白
來自分支的 Gitea 合併請求	Gitea 拉取請求	SSH URL [1]	分支名稱
來自分叉的Pargue合併請求	Pagure 合併請求	空白	空白
來自分支的 Pagure合併請求	Pagure 合併請求	SSH URL [1]	分支名稱
來自 fork 的 Azure DevOps 拉取請求	Azure DevOps 拉取請求	空白	空白
來自分支的 Azure DevOps 拉取請求	Azure DevOps 拉取請求	SSH URL [1]	分支名稱
Gerrit 檢閱	Gerrit 檢閱請求	SSH URL	目標分支名稱（選用）
從 fork 建立 Bitbucket Data Center 拉取請求	Bitbucket 資料中心拉取請求	空白	空白
來自分支的 Bitbucket 資料中心拉取請求	Bitbucket 資料中心拉取請求	SSH URL [1]	分支名稱
從 fork 建立 Bitbucket Cloud 拉取請求	Bitbucket Cloud 拉取請求	空白	空白
來自分支的 Bitbucket Cloud 拉取請求	Bitbucket Cloud 拉取請求	SSH URL [1]	分支名稱

GitHub¶

GitHub 儲存庫存取¶

Hosted Weblate GitHub App¶

在 Hosted Weblate 上，建議的設定方式是從專案所在的 Weblate 工作空間連接 Hosted Weblate app。使用連接 GitHub 帳號流程，將 App 安裝到擁有儲存庫的 GitHub 使用者或組織、授予 App 對待翻譯儲存庫的存取權，再從已連接的 GitHub 帳號匯入組件。

以 App 為基礎的工作流程會使用 GitHub App 安裝項目存取權杖來複製儲存庫、推送翻譯分支、建立拉取請求，以及接收傳入通知。使用這個方式匯入組件時，不必邀請 Hosted Weblate 的 weblate GitHub 使用者，也不必另行設定儲存庫 Webhook。

只有在您刻意設定 GitHub App 工作流程以外的直接 SSH 推送時，才使用 Hosted Weblate 的 weblate GitHub 使用者；請參閱從 Hosted Weblate 存取儲存庫。

使用個人存取權杖的 HTTPS¶

對單一私有儲存庫而言，若服務提供者支援 Git over HTTPS，使用存取權杖透過 HTTPS 存取通常是最簡單的設定方式。請在原始碼儲存庫中使用服務提供者要求的使用者名稱及權杖。

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

權杖需要讀取權限才能 Clone，並需要寫入權限才能推送。可建立 Pull Request 或 Merge Request 的服務提供者專用 VCS 後端，可能需要另外提供 API 認證資訊。

要使用這種方式：

依照建立供指令列使用的存取權杖的說明建立個人存取權杖。
在您的儲存庫 URL 中包含權杖： https://username:token@github.com/owner/repo.git。

這適合剛開始使用 Weblate 或只有單一儲存庫的情況。

使用專用使用者的 SSH¶

需要設定多個儲存庫時，請使用 SSH 存取，並為 Weblate 建立專用的程式碼代管使用者。將 Weblate 的 SSH 公開金鑰加入該使用者、授予其儲存庫存取權，並在原始碼儲存庫中使用 SSH URL，例如 git@example.com:group/project.git。

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

這也能避開服務提供者對重複使用 SSH 金鑰的限制。部分程式碼代管網站只允許加入公開 SSH 金鑰 1 次，或只能將其加入單一使用者或部署金鑰項目。將 Weblate 的 SSH 金鑰保留在專用使用者上，便能授予該使用者多個儲存庫的存取權，而無須在多處重複使用金鑰。

這能避免將個人、專案或 API 存取權杖放入儲存庫 URL。使用服務提供者專用 VCS 後端建立 Pull Request 或 Merge Request 時，仍需提供服務提供者 API 認證資訊；這些認證資訊會與 Git 儲存庫 URL 分開設定。

對於 GitHub，請建立專用使用者（例如 weblate-bot），並為儲存庫使用 GitHub SSH URL，例如 git@github.com:owner/repo.git。

在 Hosted Weblate 上，只有在建議的 Hosted Weblate app 工作流程之外需要直接以 SSH 推送時，才使用這個 SSH 使用者工作流程。

備註

使用 GitHub 建立拉取請求時，推送分支設定會影響行為：未設定時，專案會建立 fork，並透過該 fork 推送變更；設定後，變更會推送至上游儲存庫的指定分支。

GitHub 通知¶

Weblate 原生支援 GitHub。

如果使用 Hosted Weblate，請在 Weblate 的連結 GitHub 帳號流程中使用 Hosted Weblate App。這個 App 使用 GitHub App Webhook，因此不需在 GitHub 中另行設定 Webhook。從已連結 GitHub 帳號匯入的組件，也會使用該 App 存取儲存庫及建立拉取請求，無需邀請 Hosted Weblate 的 weblate GitHub 使用者。

Hosted Weblate 舊版應用程式會保留給既有的僅 webhook 設定。其傳遞使用通用 GitHub webhook URL，並以 Hosted Weblate 營運者設定的獨立 webhook 祕密值進行驗證。只有在您需要舊版應用程式將 GitHub 通知傳送至 Hosted Weblate 時才使用它。

對於自行託管的 Weblate，請依照下方說明的應用程式內註冊流程註冊 GitHub App。Weblate 會產生 App 資訊清單、GitHub 會傳回憑證，而憑證會儲存在資料庫中，因此不需要在設定中另行組態。

從 Weblate 註冊 GitHub App¶

新增 GitHub App 最快的方法，是讓 Weblate 產生已預先填入正確權限、事件及 Webhook URL 的 GitHub App 資訊清單：

使用具備管理存取權的帳號登入 Weblate。
開啟管理 → 程式碼託管連線 → 註冊 Weblate GitHub App。
填寫表單。GitHub 主機預設為 github.com；如有需要，請將其變更為您的 GitHub Enterprise 主機名稱。將組織留空會在個人帳號下註冊 App；輸入組織代稱則會在該組織下註冊。
按一下繼續前往 GitHub，並在 GitHub 的建立 GitHub App 頁面確認（仍可在該頁重新命名 App）。
GitHub 會重新導向回 Weblate；Weblate 會以暫時性程式碼交換 App ID、私密金鑰、Webhook 密碼及代稱，並將這些資料儲存至資料庫。之後即可立即使用連接 GitHub 帳號按鈕。

The manifest requests the permissions and event subscriptions Weblate needs (Contents and Pull requests read/write, Metadata read-only, Organization administration read-only, Workflows read/write, and the Installation, Meta, Push and Repository events), and sets the callback, setup and per-app webhook URLs automatically, so no manual GitHub App configuration is required. GitHub delivers the Installation and Installation repositories events to all GitHub Apps by default.

GitHub 只會提供已登入的 GitHub 使用者可以安裝或要求安裝 App 的帳號。如果安裝流程中未顯示某個組織，請檢查使用者的組織角色，以及該組織對 GitHub App 的安裝限制。在 GitHub.com 上，公開 App 可以安裝到其他帳號；私人 App 只能安裝到擁有該 App 的帳號。

連線工作空間¶

已連接的 GitHub 帳號會綁定至 Weblate 工作空間。只要使用者對工作空間中的任一專案具備專案管理權限，就能在該工作空間連接 GitHub 帳號。連接後，工作空間中的每個專案都能從 GitHub App 安裝項目可存取的儲存庫匯入組件。對於組織帳號，Weblate 會驗證安裝時的 GitHub 使用者是否能管理該組織的安裝項目。

不在工作空間中的專案無法透過 GitHub App 連接 GitHub 帳號。

若沒有其他 Weblate 工作空間使用已安裝的 GitHub App，移除已連結的 GitHub 帳號也會從 GitHub 解除安裝該 App。若其他工作空間仍在使用該安裝項目，Weblate 只會移除所選的工作空間連線。透過該連線匯入的組件將無法再存取其儲存庫。移除工作空間時，也會以相同方式解除安裝其連結帳號的 App。

即使 GitHub 已無該安裝項目的記錄，Weblate 仍會移除連線；只有在無法連上 GitHub 時才會保留連線，讓您稍後重試移除。

透過 GitHub App 流程匯入的組件會使用專用的 GitHub (透過 Weblate GitHub app) VCS 後端。組件設定使用者介面會將儲存庫 URL 保持為唯讀，避免 App 核發的憑證被重新導向至不相關的儲存庫。

遷移現有組件¶

若 Git 和 GitHub 提取要求組件符合條件，可遷移至已註冊的 Weblate GitHub App，Weblate 會顯示資訊性診斷。請使用診斷中的遷移至 GitHub App 連結，檢視工作空間內所有符合資格的組件。

為工作空間連結或更新 GitHub 帳號，授予 App 存取所列儲存庫的權限，並選取要遷移的組件。Weblate 會將所選組件的 VCS 後端變更為 GitHub（透過 Weblate GitHub App），將儲存庫位址改為標準 HTTPS 複製網址，並移除個別的推送網址，因為 App 會驗證推送至來源儲存庫的操作。

應用程式 webhook URL¶

每個已註冊的 Weblate GitHub App 都有各自的 webhook URL，其中包含可唯一識別單一已註冊 App 的不透明權杖：

https://weblate.example.com/hooks/integrations/<webhook_token>/

使用 GitHub (透過 Weblate GitHub App) VCS 後端的組件，只會透過這個專用端點進行比對。所有通用程式碼代管平台 webhook 端點（包括 /hooks/github/）都不會比對這些組件，也不會在回應診斷資訊中納入這些組件。傳送至通用端點的舊版 GitHub App 通知，只能比對使用非 App VCS 後端的組件。

When a repository is renamed or transferred on GitHub, the Repository event makes Weblate refresh the repositories of the connected GitHub account and point the affected components to the new repository URL. Apps registered before Weblate 2026.10.1 are not subscribed to this event; enable Repository under Subscribe to events in the App settings on GitHub.

Refreshing repositories of a connected GitHub account retargets such components too, for example when the event was missed. Use refresh_github_repositories to do this for all connected GitHub accounts at once.

如果不使用 GitHub App，請在儲存庫設定（Webhooks）中新增 Weblate Webhook，以在每次推送到 GitHub 儲存庫時收到通知，如下圖所示：

Payload URL 由附加 /hooks/github/ 的 Weblate URL 所組成。例如，Hosted Weblate 服務的 URL 為 https://hosted.weblate.org/hooks/github/.

其他值可保留預設設定。Weblate 可以處理兩種內容類型，而且只會處理 push 事件。

也參考

GitHub 拉取請求¶

這在 Git 頂部新增了一個薄層，使用 GitHub API 允許將翻譯變更作為拉取請求推送，而不是直接推送到儲存庫。

Git 將變更直接推送到儲存庫，而 GitHub 後端建立拉取請求。僅存取 Git 儲存庫不需要後者。

若要建立拉取請求，請選取 GitHub 作為版本控制系統，並設定 GITHUB_CREDENTIALS。對於 GitHub.com，請使用 api.github.com 作為 API 主機。權杖必須允許 Weblate 讀寫儲存庫內容及建立拉取請求。如果 Weblate 應 fork 私人儲存庫，權杖可能也需要管理存取權。

If creating a pull request fails with 404 Not Found, GitHub can be refusing API access even when the repository is readable. Weblate checks the repository's pull request creation policy and, for user tokens, the authenticated account. The failure alert reports confirmed findings and provides further checks when the cause remains unknown. Diagnostic lookup failures preserve the original pull request error.

Check that the effective API token belongs to the intended fork owner and allows creating pull requests. For fine-grained tokens, check repository selection, resource owner, and Pull requests write permission. Also check organization restrictions and access to the source branch. For GitHub Apps, check installation access to the repositories and pull request permissions. A successful Git push does not verify API access: pushing can use a separate SSH key. The repository log includes GitHub's request ID and permission headers when available to help investigate the failure. Accepted permission headers describe endpoint requirements, not the permissions granted to the token.

GitLab¶

GitLab 儲存庫存取¶

使用個人或專案存取權杖的 HTTPS¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

權杖需要讀取權限才能 Clone，並需要寫入權限才能推送。可建立 Pull Request 或 Merge Request 的服務提供者專用 VCS 後端，可能需要另外提供 API 認證資訊。

對 GitLab 而言，權杖需要 write_repository 作用範圍，才能將變更推送至儲存庫。專案存取權杖則需要 Developer 角色才能推送。

URL 需要包含使用者名稱。對個人存取權杖，它是實際使用者名稱：https://user:personal_access_token@gitlab.com/example/example.git；對專案存取權杖，可以是非空白值：https://example:project_access_token@gitlab.com/example/example.git 。

備註

不同的 GitLab 版本使用專案存取權杖的規則各異。非空白值是目前要求，但較老版本有不同預期（專案名、bot 使用者名稱）。如不確定請檢視相符您版本的 GitLab 文件。

使用專用使用者的 SSH¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

對於 GitLab，請建立專用使用者並使用 GitLab SSH URL，例如 git@gitlab.com:group/project.git。

對於 GitLab 上的 Hosted Weblate 儲存庫，請加入 Hosted Weblate 的 weblate 使用者，並授予必要的儲存庫權限；請參閱從 Hosted Weblate 存取儲存庫。

GitLab 通知¶

Weblate 支援 GitLab hooks，新增專案的 webhook，目的地為您的 Weblate 安裝上的 /hooks/gitlab/ URL，例如 https://hosted.weblate.org/hooks/gitlab/ 。

疑難排解

請查看 GitLab Webhook 請求歷程，確認 Webhook 是否已傳遞。
回應承載內容包含相符組件的資訊。

也參考

GitLab 合併請求¶

這使用 GitLab API 在 Git 上新增了一個薄層，以允許將翻譯變更作為合併請求推送，而不是直接推送到儲存庫。

不需要使用它來存取 Git 儲存庫，普通的 Git 工作方式相同，唯一的區別是如何處理推送到儲存庫。使用 Git 將變更直接推送到儲存庫，而 GitLab 後端建立合併請求。

要建立合併請求，請選擇 GitLab 作為版本控制系統並設定 GITLAB_CREDENTIALS。

推送分支設定會影響 Weblate 在開啟合併請求前將變更推送至何處。如果未設定，系統會 fork 專案，並透過 fork 推送變更；如果已設定，變更會推送至上游儲存庫及選取的分支。

Gitea、Forgejo 與 Codeberg¶

Gitea、Forgejo 與 Codeberg 儲存庫存取¶

使用存取權杖的 HTTPS¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

權杖需要讀取權限才能 Clone，並需要寫入權限才能推送。可建立 Pull Request 或 Merge Request 的服務提供者專用 VCS 後端，可能需要另外提供 API 認證資訊。

使用專用使用者的 SSH¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

對於 Codeberg 上的 Hosted Weblate 儲存庫，請加入 Hosted Weblate 的 weblate 使用者，並授予必要的儲存庫權限；請參閱從 Hosted Weblate 存取儲存庫。

Gitea 通知¶

Weblate 已經支援 Gitea webhooks，為 Push events 事件新增 Gitea Webhook，目的地為您的 Weblate 安裝上的 /hooks/gitea/ URL，例如 https://hosted.weblate.org/hooks/gitea/。這可以在 Settings 之下的 Webhooks 中完成。

也參考

Forgejo 通知¶

Weblate 支援 Forgejo Webhook。請在 Weblate 安裝環境中新增目的地為 /hooks/forgejo/ URL 的 Forgejo Webhook，並選擇 Push events 事件；例如 https://hosted.weblate.org/hooks/forgejo/。這項設定可在儲存庫設定下的 Webhooks 中完成。

也參考

Gitea 拉取請求¶

在 4.12 版被加入.

這使用 Gitea API 在 Git 上新增了一個薄層，以允許將翻譯變更作為拉取請求推送，而不是直接推送到儲存庫。

不需要使用它來存取 Git 儲存庫，普通的 Git 工作方式相同，唯一的區別是如何處理推送到儲存庫。使用 Git 將變更直接推送到儲存庫，而 Gitea 後端建立拉取請求。

要建立拉取請求，請選擇 Gitea 作為版本控制系統並設定 GITEA_CREDENTIALS。

Bitbucket¶

Bitbucket 儲存庫存取¶

使用存取權杖的 HTTPS¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

權杖需要讀取權限才能 Clone，並需要寫入權限才能推送。可建立 Pull Request 或 Merge Request 的服務提供者專用 VCS 後端，可能需要另外提供 API 認證資訊。

使用專用使用者的 SSH¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

對於 Bitbucket 上的 Hosted Weblate 儲存庫，請加入 Hosted Weblate 的 weblate 使用者，並授予必要的儲存庫權限；請參閱從 Hosted Weblate 存取儲存庫。

若要直接推送，請搭配儲存庫推送 URL 使用 Git 或 Mercurial。

Bitbucket 通知¶

Weblate 支援 Bitbucket webhooks。新增儲存庫推送時觸發的 webhook，目的地為您的 Weblate 安裝上的 /hooks/bitbucket/，例如 https://hosted.weblate.org/hooks/bitbucket/。

也參考

Bitbucket 資料中心拉取請求¶

在 4.16 版被加入.

這使用 Bitbucket 資料中心 API 在 Git 上新增了一個薄層，以允許將翻譯變更作為拉取請求推送，而不是直接推送到儲存庫。

警告

這不支援 Bitbucket Cloud API。

不需要使用它來存取 Git 儲存庫，普通的 Git 工作方式相同，唯一的區別是如何處理推送到儲存庫。使用 Git 將變更直接推送到儲存庫，而 Bitbucket 資料中心後端建立拉取請求。

若要建立拉取請求，請將 Bitbucket Data Center 選為版本控制系統，並設定 BITBUCKETSERVER_CREDENTIALS。

Bitbucket Cloud 拉取請求¶

在 5.8 版被加入.

這使用 Bitbucket Cloud API 在 Git 上新增了一個薄層，以允許將翻譯變更作為拉取請求推送，而不是直接推送到儲存庫。

警告

這與 Bitbucket Data Center API 不同。

不需要使用它來存取 Git 儲存庫，普通的 Git 工作方式相同，唯一的區別是如何處理推送到儲存庫。使用 Git 將變更直接推送到儲存庫，而 Bitbucket Cloud 後端建立拉取請求。

要建立拉取請求，將 Bitbucket Cloud 選為版本控制系統並設定 BITBUCKETCLOUD_CREDENTIALS。

Azure DevOps¶

Azure Repos 儲存庫存取¶

使用存取權杖的 HTTPS¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

權杖需要讀取權限才能 Clone，並需要寫入權限才能推送。可建立 Pull Request 或 Merge Request 的服務提供者專用 VCS 後端，可能需要另外提供 API 認證資訊。

對儲存庫使用 Azure Repos 顯示的 HTTPS 複製 URL。

使用專用使用者的 SSH¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

對儲存庫使用 Azure Repos 顯示的 SSH URL。

Azure Repos 通知¶

Weblate 支援 Azure Repos Webhook。請為 Code pushed 事件新增 Webhook，並將目的地設為 Weblate 安裝環境中的 /hooks/azure/ URL，例如 https://hosted.weblate.org/hooks/azure/。您可以在 Project settings 下的 Service hooks 中完成這項設定。

也參考

Azure DevOps 拉取請求¶

這在 Git 頂部新增了一個薄層，使用 Azure DevOps API 允許將翻譯變更作為拉取請求推送，而不是直接推送到儲存庫。

Git 將變更直接推送到儲存庫，而 Azure DevOps 後端建立拉取請求。僅存取 Git 儲存庫不需要後者。

要建立拉取請求，請選擇 Azure DevOps 作為版本控制系統並設定 AZURE_DEVOPS_CREDENTIALS。

Pagure¶

Pagure 儲存庫存取¶

使用存取權杖的 HTTPS¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

權杖需要讀取權限才能 Clone，並需要寫入權限才能推送。可建立 Pull Request 或 Merge Request 的服務提供者專用 VCS 後端，可能需要另外提供 API 認證資訊。

使用專用使用者的 SSH¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

Pagure 通知¶

Weblate 已經支援 Pagure hooks。新增專案的 webhook，目的地為您的 Weblate 安裝上的 /hooks/pagure/（例如 https://hosted.weblate.org/hooks/pagure/）。這可以在 Project options 之下的 Activate Web-hooks 中完成：

也參考

Pagure 合併請求¶

在 4.3.2 版被加入.

這使用 Pagure API 在 Git 上新增了一個薄層，以允許將翻譯變更作為合併請求推送，而不是直接推送到儲存庫。

存取 Git 儲存庫時不需使用此後端，一般的 Git 運作方式相同，唯一差別是如何處理儲存庫推送。Git 會將變更直接推送至儲存庫，Pagure 後端則會建立合併請求。

要建立合併請求，請選擇 Pagure 作為版本控制系統並設定 PAGURE_CREDENTIALS。

其他工作流程¶

Gitee 儲存庫存取¶

使用存取權杖的 HTTPS¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

權杖需要讀取權限才能 Clone，並需要寫入權限才能推送。可建立 Pull Request 或 Merge Request 的服務提供者專用 VCS 後端，可能需要另外提供 API 認證資訊。

使用專用使用者的 SSH¶

只有在 Weblate 應直接推送變更，或所選工作流程需要推送 URL 時，才設定儲存庫推送 URL；請參閱從 Weblate 推送變更。

Gitee 通知¶

Weblate 已經支援 Gitee webhooks。為 Push 事件新增 Webhook，目的地為您的 Weblate 安裝上的 /hooks/gitee/ URL，例如 https://hosted.weblate.org/hooks/gitee/。這可以在 Management 之下的 Webhooks 中完成。

也參考

Gerrit 檢閱請求¶

Gerrit 支援使用 git-review 工具在 Git 上新增一個薄層，以允許將翻譯變更作為 Gerrit 檢閱請求推送，而不是將它們直接推送到儲存庫。

選用的推送分支設定會選取 Gerrit 檢閱的目標分支。將其留空會使用儲存庫分支。請使用簡短分支名稱（例如 main）；Weblate 和 git-review 會自動將檢閱推送至 refs/for/<branch>。Gerrit 推送選項可以附加在任一設定的 % 後方，例如 main%topic=l10n。Gerrit 會將這些選項解讀為已設定的 Weblate Gerrit 帳號，並套用其本身的權限。

Gerrit 文件詳細說明建立此類儲存庫所需的設定。此後端沒有獨立的程式碼託管認證資訊設定。

Docker 憑證¶

對於 Docker 安裝，程式碼託管 API 認證資訊也可以透過環境變數提供，請參閱程式碼託管網站認證資訊。