持续本地化集成¶
有适当的基础结构，因此你的翻译紧随开发。这样，翻译人员可以一直进行翻译，而不必在发布之前处理大量的新文本。
参见
与 Weblate 集成 描述了将您的开发集成到 Weblate 中的基本方式。
这是过程：
开发人员进行更改并将其推送到版本控制系统（VCS ）仓库。
可以选择更新翻译文件（这取决于文件格式，请参阅 当已经更新了模板时，为什么 Weblate 仍然显示旧的字符串？）。
Weblate 从版本控制系统（VCS ）仓库中拉取更改，请参阅 更新仓库。
一旦 Weblate 检测到翻译更改，便会根据翻译者的订阅设置通知他们。
翻译者使用 Weblate Web 界面提交翻译，或上传离线更改。
翻译者完成后，Weblate 会将更改提交到本地仓库（请参阅 惰性提交），如果有权限将其推回（请参阅 推送 Weblate 的更改）。
更新仓库¶
应该新建一些从他们的源来更新后端仓库的方式。
使用 通知钩子 来与多数常见的代码托管服务集成：
在仓库管理中或使用 Weblate 的 REST API 或 Weblate 客户端 来手动触发更新
允许
AUTO_UPDATE在你的Weblate事例上自动更新所有组件执行
updategit（选择项目，或 –all 来更新全部）
每当Weblate更新存储库时，更新后插件都将被触发，请参见： 附加组件 。
避免合并冲突¶
当相同的文件在 Weblate 之内与之外都更改时导致 Weblate 的合并冲突。有两种方法来处理——避免在 Weblate 之外编辑，或者将 Weblate 集成到你的更新过程中，从而在更新 weblate 之外的文件之前刷新更改。
第一种方法容易用于单语言文件——可以添加 Weblate 之内的新字符串，并将文件的整个编辑留在那里。对于双语言文件，通常存在某种消息提取过程而从源代码产生翻译文件。在一些情况下，这可以分成两部分——一部分用于提取过程产生模板（例如使用 xgettext 产生 gettex POT ），然后下一步过程将它合并到真正的翻译中（例如使用 msgmerge 更新 gettext PO 文件）。可以在 Weblate 中执行第二步，它将确认在这个操作前所有待定的更改都包括进去了。
第二种方法可以这样实现，使用 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 。
参见
从 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 事件）。
从 Bitbucket 自动接收更改¶
Weblate 已经支持 Bitbucket webhooks ，添加仓库推送时触发的 webhook ，目的地为你的 Weblate 安装上的 /hooks/bitbucket/ （例如 https://hosted.weblate.org/hooks/bitbucket/ ）。
从 GitLab 自动接收更改¶
Weblate 已经支持 GitLab hooks ，添加项目的 webhook ，目的地为你的 Weblate 安装上的 /hooks/gitlab/ （例如 https://hosted.weblate.org/hooks/gitlab/ ）。
从 Pagure 自动接受更改¶
3.3 新版功能.
Weblate 已经支持 Pagure hooks ，添加项目的 webhook ，目的地为你的 Weblate 安装上的 /hooks/pagure/ （例如 https://hosted.weblate.org/hooks/pagure/ ）。这可以在 Project options 之下的 Activate Web-hooks 中完成：
从 Azure Repos 自动接收更改¶
3.8 新版功能.
Weblate 已经支持 Azure Repos web hooks ，为 Code pushed 事件添加 webhook ，目的地为你的 Weblate 安装上的 /hooks/azure/ URL （例如 https://hosted.weblate.org/hooks/azure/ ）。这可以在 Project settings 之下的 Service hooks 中完成。
从 Gitea Repos 自动接收更改¶
3.9 新版功能.
Weblate 已经支持 Gitea webhooks ，为 Push events 事件添加 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/, Accessing repositories from Hosted Weblate
从 Gitee Repos 自动接收更改¶
3.9 新版功能.
Weblate 已经支持 Gitee webhooks ，为 Push 事件添加 Webhook ，目的地为你的 Weblate 安装上的 /hooks/gitee/ URL （例如 https://hosted.weblate.org/hooks/gitee/ ）。这可以在 Management 之下的 Webhooks 中完成。
参见
Gitee 手册中的 Webhoks <https://gitee.com/help/categories/40>`_, POST /hooks/gitee/, Accessing repositories from Hosted Weblate
每晚自动更新仓库¶
Weblate 在后面合并更改时，每晚自动获取远程仓库来提高性能。可以选择将其同样转换为进行每晚合并，通过允许 AUTO_UPDATE 。
推送 Weblate 的更改¶
每个翻译组件可以新建推送 URL（请参见 代码库推送 URL ），在那种情况下 Weblate 能够将更改推送到远程仓库。 Weblate 还可以配置在每次提交时自动推送更改（这是默认的，请参见 提交时推送 ）。如果不想更改自动给推送，可以在 Repository maintenance 之下手动进行，或通过 wlc push 使用 API。
推送选项根据使用的 版本控制集成 而不同，更多细节可以在那个章节中找到。
如果不想要 Weblate 的直接推送，系统也支持 GitHub 、 GitLab、 vcs-pagure`的拉取请求或 :ref:`vcs-gerrit 审核。 你可以通过在 组件配置 中选择 GitHub 、 GitLab 、 Gerrit 或 Pagure 作为 版本控制系统 来激活这些。
整体上， Git 、 GitHub 和 GitLab 可以具有后面的选项：
需要的设置 |
|||
|---|---|---|---|
不推送 |
空 |
空 |
|
直接推送 |
SSH URL |
空 |
|
推送到单独的分支 |
SSH URL |
分支名称 |
|
来自叉子的 GitHub 拉取请求 |
空 |
空 |
|
来自分支的 GitHub 拉取请求 |
SSH URL 1 |
分支名称 |
|
来自叉子的 GitLab 结合请求 |
空 |
空 |
|
来自分支的 GitLab 结合请求 |
SSH URL 1 |
分支名称 |
|
来自分叉的Pargue合并请求 |
空 |
空 |
|
来自分支的 Pagure合并请求 |
SSH URL 1 |
分支名称 |
注解
还可以允许 Weblate 提交后更改的自动推送，这可以在 提交时推送 中完成。
参见
请参见 Accessing repositories 来设置 SSH 密钥，和 惰性提交 获得关于 Weblate 决定提交更改的信息。
受保护的分支¶
如果在受保护的分支上使用 Weblate ，可以配置使用拉取请求，并执行翻译的实际复查（对你不知道的语言可能有问题）。另一个方法是去掉对 Weblate 推送用户的这个限制。
例如在 GitHub ，这可以在仓库配置中进行：
结合或变基¶
Weblate 默认将 上游仓库结合到自身。在你还通过其他方式访问下层仓库的情况下，这是最安全的方式。在不需要这个的情况下，可以允许上游更改的变基，这会产生较少的融合提交的历史。
注解
在复杂融合的情况下，变基可能使你产生麻烦，因此请仔细考虑是否允许它们。
惰性提交¶
Weblate会尽可能将同一作者的提交分组到一个提交中。这大大减少了提交的数量，但是如果你想同步版本控制系统（VCS ）仓库，例如合并，你可能需要明确地告诉它去做提交（这对 Managers`组是默认允许的，参见 :ref:`privileges）。
一旦后面的任何条件满足，这种模式的更改将被提交：
某人另外更改了已经被更改的字符串。
来自上游的结合发生了。
明确地请求了提交。
更改比 组件配置 上定义为 Age of changes to commit 的时间段更陈旧。
提示
每个组件都建立提交。所以在具有很多组件的情况下，仍然会看到很多提交。在这种情况下你会使用 压缩 Git 提交 插件。
如果想要更频繁地提交更改，并且不检查新旧，可以安排周期定时性任务来执行提交：
CELERY_BEAT_SCHEDULE = {
# Unconditionally commit all changes every 2 minutes
"commit": {
"task": "weblate.trans.tasks.commit_pending",
# Ommiting hours will honor per component settings,
# otherwise components with no changes older than this
# won't be committed
"kwargs": {"hours": 0},
# How frequently to execute the job in seconds
"schedule": 120,
}
}