持续本地化¶
有适当的基础结构，因此你的翻译紧随开发。这样，翻译人员可以一直进行翻译，而不必在发布之前处理大量的新文本。
参见
与 Weblate 集成 描述了将您的开发集成到 Weblate 中的基本方式。
这是过程：
开发人员进行更改并将其推送到版本控制系统仓库。
可以选择更新翻译文件，请参阅 引入新字符串。
Weblate 从版本控制系统仓库中拉取更改，解析翻译文件并更新其数据库，见 更新仓库。
译者使用 Weblate Web 界面提交翻译，或上传离线更改。
译者完成后，Weblate 会将更改提交到本地仓库（请参阅 惰性提交）。
更改被推送回上游仓库（见:ref:push-changes ）。
提示
上游代码托管不是必需的，你可以通过 :ref:`vcs-local`使用 Weblate，在本地 VCS 中只有 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。
避免发端于 Weblate 更改的合并冲突¶
即便 Weblate 是翻译文件更改的单一来源，当使用 挤压 Git 提交 附加组件、 component-merge_style`被配置为 :guilabel:`Rebase，或者你在挤压 Weblate 外面的提交（比如合并拉取请求）时，也可能发生冲突。
此情形下，合并冲突的原因是不同的。比如，在你合并 Weblate 提交后，Weblate 中发生了更改。出现这种情况通常是因为合并操作不是自动进行的，而是等待几天或数周进行人工审核。Git 有时会无法识别上游的更改是否与 Weblate 匹配，并拒绝执行变基操作。
要解决此问题，你需要在合并拉取请求时尽量减少 Weblate 中的待处理更改，或者通过不挤压更改来完全避免冲突。
这里有几个避免这一问题的选项：
不用 挤压 Git 提交，也不在合并时进行 squash。使用它们是导致 git 在合并后不识别改动的根本原因。
在合并前让 Weblate 提交待定更改。这会更新所有更改到拉取请求，且两个仓库会保持同步。
使用 Weblate 中的审阅功能（见 翻译工作流），这样你可以在 CI 通过后自动合并 GitHub 拉取请求。
在 Weblate 中使用锁定避免在审核 Github 拉取请求时的更改。
参见
从 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 自动接受更改¶
Weblate 已经支持 Pagure hooks，添加项目的 webhook，目的地为你的 Weblate 安装上的 /hooks/pagure/ （例如 https://hosted.weblate.org/hooks/pagure/ ）。这可以在 Project options 之下的 Activate Web-hooks 中完成：
从 Azure Repos 自动接收更改¶
Weblate 已经支持 Azure Repos web hooks，为 Code pushed 事件添加 webhook，目的地为你的 Weblate 安装上的 /hooks/azure/ URL （例如 https://hosted.weblate.org/hooks/azure/ ）。这可以在 Project settings 之下的 Service hooks 中完成。
从 Gitea Repos 自动接收更改¶
Weblate 已经支持 Gitea webhooks，为 Push events 事件添加 Gitea Webhook，目的地为你的 Weblate 安装上的 /hooks/gitea/ URL （例如 https://hosted.weblate.org/hooks/gitea/ ）。这可以在 Settings 之下的 Webhooks 中完成。
从 Gitee Repos 自动接收更改¶
Weblate 已经支持 Gitee webhooks，为 Push 事件添加 Webhook，目的地为你的 Weblate 安装上的 /hooks/gitee/ URL （例如 https://hosted.weblate.org/hooks/gitee/ ）。这可以在 Management 之下的 Webhooks 中完成。
每晚自动更新仓库¶
Weblate 在后面合并更改时，每晚自动获取远程仓库来提高性能。可以选择将其同样转换为进行每晚合并，通过允许 AUTO_UPDATE。
推送 Weblate 的更改¶
每个翻译部件可以新建推送 URL（请参见 仓库推送 URL ），在那种情况下 Weblate 能够将更改推送到远程仓库。Weblate 还可以配置在每次提交时自动推送更改（这是默认的，请参见 提交时推送 ）。如果不想更改自动给推送，可以在 仓库维护 之下手动进行，或通过 wlc push 使用 API。
推送选项根据使用的 版本控制集成 而不同，更多细节可以在那个章节中找到。
如果不想要 Weblate 的直接推送，系统也支持 GitHub 拉取请求 、 GitLab 合并请求、 Gitea 拉取请求、Pagure 合并请求 、 Azure DevOps 拉取请求 的拉取请求或 Gerrit 审核。你可以通过在 部件配置 中选择 GitHub 、 GitLab Gitea、 Gerrit 、 Azure DevOps`或 :guilabel:`Pagure 作为 版本控制系统 来激活这些。
整体上， Git、Mercurial、GitHub、GitLab、 Gitea、Pagure 和 Azure DevOps 有下列选项：
需要的设置 |
|||
|---|---|---|---|
不推送 |
空 |
空 |
|
直接推送 |
SSH URL |
空 |
|
推送到单独的分支 |
SSH URL |
分支名称 |
|
不推送 |
空 |
空 |
|
直接推送 |
SSH URL |
空 |
|
推送到单独的分支 |
SSH URL |
分支名称 |
|
来自派生的 GitHub 拉取请求 |
空 |
空 |
|
来自分支的 GitHub 拉取请求 |
SSH URL [1] |
分支名称 |
|
来自派生的 GitLab 合并请求 |
空 |
空 |
|
来自分支的 GitLab 结合请求 |
SSH URL [1] |
分支名称 |
|
来自分叉的 Gitea 合并请求 |
空 |
空 |
|
来自分支的 Gitea 合并请求 |
SSH URL [1] |
分支名称 |
|
来自派生的 Pargue 合并请求 |
空 |
空 |
|
来自分支的 Pagure 合并请求 |
SSH URL [1] |
分支名称 |
|
来自分叉的 Azure DevOps 拉取请求 |
空 |
空 |
|
来自分支的 Azure DevOps 拉取请求 |
SSH URL [1] |
分支名称 |
备注
还可以允许 Weblate 提交后更改的自动推送，这可以在 提交时推送 中完成。
受保护的分支¶
如果在受保护的分支上使用 Weblate，可以配置使用拉取请求，并执行翻译的实际复查（对你不知道的语言可能有问题）。另一个方法是去掉对 Weblate 推送用户的这个限制。
例如在 GitHub，这可以在仓库配置中进行：
与他人交互¶
Weblate 通过使用它的 API，使与他人的交流更容易。
惰性提交¶
Weblate 会尽可能将同一作者的提交分组到一个提交中。这大大减少了提交的数量，但是如果你想同步版本控制系统仓库，例如合并，你可能需要明确地告诉它去做提交（这对 管理者 组是默认允许的，参见 特权列表）。
一旦后面的任何条件满足，这种模式的更改将被提交：
某人另外更改了已经被更改的字符串。
来自上游的结合发生了。
明确地请求了提交。
已请求文件下载。
更改比 部件配置 上定义为 对更改进行提交的延时时间 的时间段更陈旧。
提示
每个部件都会创建提交。所以，如果你有很多部件，仍然会看到很多提交。在这种情况下，你可以使用 挤压 Git 提交 附加组件。
如果你想更频繁地提交更改而无需检查存在时间，你可以设置一个定时任务来执行提交。方法是使用 Django 管理界面 中的 Periodic Tasks。首先，创建期望的 Interval （比如 120 秒）。接着，添加新的定时任务并选择 weblate.trans.tasks.commit_pending 为 Task， {"hours": 0} 为 Keyword Arguments 和想要的间隔。
用脚本处理仓库¶
定制 Weblate 与仓库交互的方式是 附加组件。关于如何通过附加组件执行外部脚本的信息，请咨询 从附加组件执行脚本。
跨部件保持翻译一致¶
一旦具有多个翻译部件，你会想要确保相同的字符串具有相同的翻译。这可以在几个层次实现。
翻译传播¶
当 允许同步翻译 处于启用状态时（这是默认的，请参见 部件配置 ），在所有的部件中字符串匹配时，所有新的翻译自动进行。在所有的部件中这样的翻译都适当地归功于当前翻译的用户。
备注
翻译传播需要密钥来匹配单语言翻译格式，因此在建立翻译密钥后请牢记。
一致性检查¶
只要字符串存在差异，就会触发 不一致的 检查。可以利用此检查来手动复查这些差异，并选择正确的翻译。
自动翻译¶
基于不同部件的自动翻译，可以是跨部件同步翻译的方式。可以或者手动触发（请参见 自动翻译 ），或者使用附加组件（ 自动翻译 ）在仓库更新时自动运行。