持續在地化

有適當的基礎結構，因此您的翻譯緊隨開發。這樣，翻譯人員可以一直進行翻譯，而不必在發佈之前處理大量的新文本。

也參考

與 Weblate 整合 描述了將您的開發整合到 Weblate 中的基本方式。

這是過程：

1. 開發人員進行更改並將其推送到版本控制系統（VCS ）儲存庫。

2. Optionally the translation files are updated, see Introducing new strings.

3. Weblate pulls changes from the VCS repository, parses translation files and updates its database, see 更新儲存庫.

4. 翻譯者使用 Weblate Web 界面提交翻譯，或上傳離線更改。

5. Once the translators are finished, Weblate commits the changes to the local repository (see 簡易送交).

6. Changes are pushed back to the upstream repository (see 推送 Weblate 的更改).

提示

Upstream code hosting is not necessary, you can use Weblate with Local files where there is only the repository inside Weblate.

更新儲存庫

應該新建一些從他們的來源來更新後端儲存庫的方式。

• 使用 通知掛勾 來與多數常見的代碼託管服務整合：

  • 從 GitHub 自動接收更改

  • 從 GitLab 自動接收更改

  • 從 Bitbucket 自動接收更改

  • 從 Pagure 自動接受更改

  • 從 Azure Repos 自動接收更改

  • 從 Gitea Repos 自動接收更改

• 在儲存庫管理中或使用 Weblate 的 REST API 或 Weblate 客戶端 來手動觸發更新

• 允許 AUTO_UPDATE 在您的Weblate事例上自動更新所有組件

• Execute updategit (with selection of project or --all to update all)

每當 Weblate 更新儲存庫時，更新後外掛都將被觸發，請參見 附加元件。

避免發生合併衝突

當相同的文件在 Weblate 之內與之外都更改時導致 Weblate 的合併衝突。有兩種方法來處理——避免在 Weblate 之外編輯，或者將 Weblate 整合到您的更新過程中，從而在更新 weblate 之外的文件之前刷新更改。

The first approach is easy with monolingual files — you can add new strings within Weblate and leave whole editing of the files there. For bilingual files, there is usually some kind of message extraction process to generate translatable files from the source code. In some cases this can be split into two parts - one for the extraction generates template (for example gettext POT is generated using xgettext) and then further process merges it into actual translations (the gettext PO files are updated using msgmerge). You can perform the second step within Weblate and it will ensure that all pending changes are included prior to this operation.

第二種方法可以這樣實現，使用 Weblate 的 REST API，當您在自己一側進行更改時，強制 Weblate 推送所有待定的更改，並鎖定翻譯。

進行更新的腳本看起來像這樣：

# Lock Weblate translation
wlc lock
# Push changes from Weblate to upstream repository
wlc push
# Pull changes from upstream repository to your local copy
git pull
# Update translation files, this example is for Django
./manage.py makemessages --keep-pot -a
git commit -m 'Locale updates' -- locale
# Push changes to upstream repository
git push
# Tell Weblate to pull changes (not needed if Weblate follows your repo
# automatically)
wlc pull
# Unlock translations
wlc unlock

如果多個組件分享相同的儲存庫，需要分別將他們全部鎖定：

wlc lock foo/bar
wlc lock foo/baz
wlc lock foo/baj

備註

例子使用了 Weblate 客戶端，這需要組態 （API 金鑰）來遠端控制 Weblate。可以通過使用 HTTP 客戶端代替 wlc，例如 curl 來實現，請參見 Weblate 的 REST API。

Avoiding merge conflicts on Weblate originated changes

Even when Weblate is the single source of the changes in the translation files, conflicts can appear when using 匯併 Git 送交 add-on, 合併類型 is configured to Rebase, or you are squashing commits outside of Weblate (for example when merging a pull request).

The reason for merge conflicts is different in this case - there are changes in Weblate which happened after you merged Weblate commits. This typically happens if merging is not automated and waits for days or weeks for a human to review them. Git is then sometimes no longer able to identify upstream changes as matching the Weblate ones and refuses to perform a rebase.

To approach this, you either need to minimize amount of pending changes in Weblate when you merge a pull request, or avoid the conflicts completely by not squashing changes.

Here are few options how to avoid that:

• Do not use neither 匯併 Git 送交 nor squashing at merge time. This is the root cause why git doesn’t recognize changes after merging.

• Let Weblate commit pending changes before merging. This will update the pull request with all its changes and both repositories will be in sync.

• Use the review features in Weblate (see 翻譯工作流), so that you can automatically merge GitHub pull requests after CI passes.

• Use locking in Weblate to avoid changes while GitHub pull request is in review.

也參考

Weblate 客戶端

從 GitHub 自動接收更改

Weblate 伴隨 GitHub 本地支援。

如果使用 Hosted Weblate，推薦的方法是安裝 Weblate app，該方法能夠得到正確的設定，而不必設定很多東西。它還可以用於將更改推送回來。

為了在每次推送到 GitHub 儲存庫時接收通知，將 Weblate Webhook 新增到儲存庫設定（ Webhooks ）中，如下圖所示：

對於負載 URL，將 /hooks/github/ 增補到您的 Weblate URL 中，例如對於 Hosted Weblate 服務，這是 https://hosted.weblate.org/hooks/github/。

可以將其他設定保留為預設值（ Weblate 可以處理內容類型，並只消費 push 事件）。

也參考

POST /hooks/github/, 從託管的 Weblate 存取儲存庫

從 Bitbucket 自動接收更改

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

也參考

POST /hooks/bitbucket/, 從託管的 Weblate 存取儲存庫

從 GitLab 自動接收更改

Weblate 已經支援 GitLab hooks，新增專案的 Webhook，目的地為您的 Weblate 安裝上的``/hooks/gitlab/（例如``https://hosted.weblate.org/hooks/gitlab/）。

也參考

POST /hooks/gitlab/, 從託管的 Weblate 存取儲存庫

從 Pagure 自動接受更改

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

也參考

POST /hooks/pagure/, 從託管的 Weblate 存取儲存庫

從 Azure Repos 自動接收更改

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.

也參考

Web hooks in Azure DevOps manual, POST /hooks/azure/, 從託管的 Weblate 存取儲存庫

從 Gitea Repos 自動接收更改

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

也參考

Gitea 手冊中的 Webhooks <https://docs.gitea.io/en-us/webhooks/>`_, POST /hooks/gitea/, 從託管的 Weblate 存取儲存庫

從 Gitee Repos 自動接收更改

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

也參考

Gitee 手冊中的 Webhoks <https://gitee.com/help/categories/40>`_, POST /hooks/gitee/, 從託管的 Weblate 存取儲存庫

每晚自動更新儲存庫

Weblate 在後面合併變更時，每晚自動擷取遠端儲存庫來提高效能。可以選擇將其同樣轉換為進行每晚合併，通過允許 AUTO_UPDATE。

推送 Weblate 的更改

每個翻譯組件可以新建推送 URL（請參見 儲存庫推送 URL ），在那種情況下 Weblate 能夠將更改推送到遠端儲存庫。 Weblate 還可以組態在每次送交時自動推送更改（這是預設的，請參見 送交時一併推送 ）。如果不想更改自動給推送，可以在 Repository maintenance 之下手動進行，或通過 wlc push 使用 API。

推送選項根據使用的 版本控制整合 而不同，更多細節可以在那個章節中找到。

In case you do not want direct pushes by Weblate, there is support for GitHub pull requests, GitLab 合併請求, Gitea pull requests, Pagure 合併請求, Azure DevOps pull requests pull requests or Gerrit 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, and Azure DevOps:

需要的設定	版本控制系統	儲存庫推送 URL	推送分支
不推送	Git	空	空
直接推送	Git	SSH URL	空
Push to separate branch	Git	SSH URL	分支名稱
不推送	Mercurial	空	空
直接推送	Mercurial	SSH URL	空
Push to separate branch	Mercurial	SSH URL	分支名稱
來自叉子的 GitHub 拉取請求	GitHub pull requests	空	空
來自分支的 GitHub 拉取請求	GitHub pull requests	SSH URL [1]	分支名稱
來自叉子的 GitLab 結合請求	GitLab 合併請求	空	空
來自分支的 GitLab 結合請求	GitLab 合併請求	SSH URL [1]	分支名稱
Gitea merge request from fork	Gitea pull requests	空	空
Gitea merge request from branch	Gitea pull requests	SSH URL [1]	分支名稱
來自分叉的Pargue合併請求	Pagure 合併請求	空	空
來自分支的 Pagure合併請求	Pagure 合併請求	SSH URL [1]	分支名稱
Azure DevOps pull request from fork	Azure DevOps pull requests	空	空
Azure DevOps pull request from branch	Azure DevOps pull requests	SSH URL [1]	分支名稱

[1] (1,2,3,4,5)

在 來源碼儲存庫 支援推送的情況下可以為空。

備註

還可以允許 Weblate 送交後更改的自動推送，這可以在 送交時一併推送 中完成。

也參考

請參見 存取儲存庫 來設定 SSH 金鑰，和 簡易送交 獲得關於 Weblate 決定送交更改的資訊。

受保護的分支

如果在受保護的分支上使用 Weblate，可以組態使用拉取請求，並執行翻譯的實際複查（對您不知道的語言可能有問題）。另一個方法是去掉對 Weblate 推送使用者的這個限制。

例如在 GitHub，這可以在儲存庫組態中進行：

與其他相互影響

Weblate 通過使用它的 API，使與他人的交流更容易。

也參考

Weblate 的 REST API

簡易送交

Weblate 會盡可能將同一作者的送交分組到一個送交中。這大大減少了送交的數量，但是如果您想同步版本控制系統（VCS ）儲存庫，例如合併，您可能需要明確地告訴它去做送交（這對 Managers`群組是預設允許的，參見 :ref:`privileges）。

如果多個組件分享相同的儲存庫，需要分別將他們全部鎖定：

• 某人另外更改了已經被更改的字串。

• 來自上游的結合發生了。

• 明確地請求了送交。

• A file download is requested.

• 更改比 組件組態 上定義為 Age of changes to commit 的時間段更陳舊。

提示

Commits are created for every component. So in case you have many components you will still see lot of commits. You might utilize 匯併 Git 送交 add-on in that case.

If you want to commit changes more frequently and without checking of age, you can schedule a regular task to perform a commit. This can be done using Periodic Tasks in Django 管理界面. First create desired Interval (for example 120 seconds). Then add new periodic task and choose weblate.trans.tasks.commit_pending as Task with {"hours": 0} as Keyword Arguments and desired interval.

用指令稿處理儲存庫

自訂 Weblate 與儲存庫互動方式是 附加元件。關於如何通過外掛執行外部指令稿的資訊，請參見 Executing scripts from add-on。

跨組件保持翻譯一致

一旦具有多個翻譯組件，您會想要確保相同的字串具有相同的翻譯。這可以在幾個層次實現。

翻譯宣傳

With 允許翻譯再用 enabled (what is the default, see 組件組態), all new translations are automatically done in all components with matching strings. Such translations are properly credited to currently translating user in all components.

備註

翻譯宣傳需要金鑰來匹配單語言翻譯格式，因此在建立翻譯金鑰匙請記住。

一致性檢查

在字串不同時 不一致 會啟動檢查。您可以藉此來手動複查其差異，並選擇正確的翻譯。

自動翻譯

Automatic translation based on different components can be way to synchronize the translations across components. You can either trigger it manually (see 自動翻譯) or make it run automatically on repository update using add-on (see 自動翻譯).