持续本地化#

有适当的基础结构，因此你的翻译紧随开发。这样，翻译人员可以一直进行翻译，而不必在发布之前处理大量的新文本。

参见

与 Weblate 集成描述了将您的开发集成到 Weblate 中的基本方式。

这是过程：

开发人员进行更改并将其推送到版本控制系统仓库。
可以选择更新翻译文件，请参阅引入新字符串。
Weblate 从版本控制系统仓库中拉取更改，请参阅更新仓库。
一旦 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。

参见

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/, 从 Hosted Weblate 访问仓库

从 Bitbucket 自动接收更改#

Weblate 已经支持 Bitbucket webhooks，添加仓库推送时触发的 webhook，目的地为你的 Weblate 安装上的 /hooks/bitbucket/ （例如 https://hosted.weblate.org/hooks/bitbucket/ ）。

参见

POST /hooks/bitbucket/, 从 Hosted Weblate 访问仓库

从 GitLab 自动接收更改#

Weblate 已经支持 GitLab hooks，添加项目的 webhook，目的地为你的 Weblate 安装上的 /hooks/gitlab/ （例如 https://hosted.weblate.org/hooks/gitlab/ ）。

参见

POST /hooks/gitlab/, 从 Hosted Weblate 访问仓库

从 Pagure 自动接受更改#

Weblate 已经支持 Pagure hooks，添加项目的 webhook，目的地为你的 Weblate 安装上的 /hooks/pagure/ （例如 https://hosted.weblate.org/hooks/pagure/ ）。这可以在 Project options 之下的 Activate Web-hooks 中完成：

参见

POST /hooks/pagure/, 从 Hosted Weblate 访问仓库

从 Azure Repos 自动接收更改#

Weblate 已经支持 Azure Repos web hooks，为 Code pushed 事件添加 webhook，目的地为你的 Weblate 安装上的 /hooks/azure/ URL （例如 https://hosted.weblate.org/hooks/azure/ ）。这可以在 Project settings 之下的 Service hooks 中完成。

参见

Azure DevOps 手册中的 Web hooks, POST /hooks/azure/, 从 Hosted Weblate 访问仓库

从 Gitea Repos 自动接收更改#

Weblate 已经支持 Gitea webhooks，为 Push events 事件添加 Gitea Webhook，目的地为你的 Weblate 安装上的 /hooks/gitea/ URL （例如 https://hosted.weblate.org/hooks/gitea/ ）。这可以在 Settings 之下的 Webhooks 中完成。

参见

Gitea 手册中的 Webhooks, POST /hooks/gitea/, 从 Hosted Weblate 访问仓库

从 Gitee Repos 自动接收更改#

Weblate 已经支持 Gitee webhooks，为 Push 事件添加 Webhook，目的地为你的 Weblate 安装上的 /hooks/gitee/ URL （例如 https://hosted.weblate.org/hooks/gitee/ ）。这可以在 Management 之下的 Webhooks 中完成。

参见

Gitee 手册中的 Webhoks , POST /hooks/gitee/, 从 Hosted Weblate 访问仓库

每晚自动更新仓库#

Weblate 在后面合并更改时，每晚自动获取远程仓库来提高性能。可以选择将其同样转换为进行每晚合并，通过允许 AUTO_UPDATE。

推送 Weblate 的更改#

每个翻译部件可以新建推送 URL（请参见仓库推送 URL ），在那种情况下 Weblate 能够将更改推送到远程仓库。Weblate 还可以配置在每次提交时自动推送更改（这是默认的，请参见提交时推送）。如果不想更改自动给推送，可以在仓库维护之下手动进行，或通过 wlc push 使用 API。

推送选项根据使用的版本控制集成而不同，更多细节可以在那个章节中找到。

如果不想要 Weblate 的直接推送，系统也支持 GitHub 拉取请求、 GitLab 合并请求、 Gitea 拉取请求、Pagure 合并请求的拉取请求或 Gerrit 审核。你可以通过在部件配置中选择 GitHub 、 GitLab Gitea、 Gerrit 或 Pagure 作为版本控制系统来激活这些。

整体上，Git 、 GitHub 和 GitLab 可以具有后面的选项：

需要的设置	版本控制系统	仓库推送 URL	推送分支
不推送	Git	空	空
直接推送	Git	SSH URL	空
推送到单独的分支	Git	SSH URL	分支名称
不推送	Mercurial	空	空
直接推送	Mercurial	SSH URL	空
推送到单独的分支	Mercurial	SSH URL	分支名称
来自派生的 GitHub 拉取请求	GitHub 拉取请求	空	空
来自分支的 GitHub 拉取请求	GitHub 拉取请求	SSH URL [1]	分支名称
来自派生的 GitLab 合并请求	GitLab 合并请求	空	空
来自分支的 GitLab 结合请求	GitLab 合并请求	SSH URL [1]	分支名称
来自分叉的 Gitea 合并请求	Gitea 拉取请求	空	空
来自分支的 Gitea 合并请求	Gitea 拉取请求	SSH URL [1]	分支名称
来自派生的 Pargue 合并请求	Pagure 合并请求	空	空
来自分支的 Pagure 合并请求	Pagure 合并请求	SSH URL [1]	分支名称

备注

还可以允许 Weblate 提交后更改的自动推送，这可以在提交时推送中完成。

参见

请参见访问仓库来设置 SSH 密钥，和惰性提交获得关于 Weblate 决定提交更改的信息。

受保护的分支#

如果在受保护的分支上使用 Weblate，可以配置使用拉取请求，并执行翻译的实际复查（对你不知道的语言可能有问题）。另一个方法是去掉对 Weblate 推送用户的这个限制。

例如在 GitHub，这可以在仓库配置中进行：

与他人交互#

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

参见

Weblate 的 REST API

惰性提交#

Weblate 会尽可能将同一作者的提交分组到一个提交中。这大大减少了提交的数量，但是如果你想同步版本控制系统仓库，例如合并，你可能需要明确地告诉它去做提交（这对管理者组是默认允许的，参见权限和内置角色列表）。

一旦后面的任何条件满足，这种模式的更改将被提交：

某人另外更改了已经被更改的字符串。
来自上游的结合发生了。
明确地请求了提交。
已请求文件下载。
更改比部件配置上定义为对更改进行提交的延时时间的时间段更陈旧。

提示

每个部件都会创建提交。所以，如果你有很多部件，仍然会看到很多提交。在这种情况下，你可以使用挤压 Git 提交附加组件。

如果你想更频繁地提交更改而无需检查存在时间，你可以设置一个定时任务来执行提交。方法是使用 Django 管理界面中的 Periodic Tasks。首先，创建期望的 Interval （比如 120 秒）。接着，添加新的定时任务并选择 weblate.trans.tasks.commit_pending 为 Task， {"hours": 0} 为 Keyword Arguments 和想要的间隔。

用脚本处理仓库#

定制 Weblate 与仓库交互的方式是附加组件。关于如何通过附加组件执行外部脚本的信息，请咨询从附加组件执行脚本。

跨部件保持翻译一致#

一旦具有多个翻译部件，你会想要确保相同的字符串具有相同的翻译。这可以在几个层次实现。

翻译宣传#

当允许同步翻译处于启用状态时（这是默认的，请参见部件配置），在所有的部件中字符串匹配时，所有新的翻译自动进行。在所有的部件中这样的翻译都适当地归功于当前翻译的用户。

备注

翻译宣传需要密钥来匹配单语言翻译格式，因此在建立翻译密钥匙请记住。

一致性检查#

只要字符串存在差异，就会触发不一致的检查。可以利用此检查来手动复查这些差异，并选择正确的翻译。

自动翻译#

基于不同部件的自动翻译，可以是跨部件同步翻译的方式。可以或者手动触发（请参见自动翻译），或者使用附加组件（自动翻译）在仓库更新时自动运行。