持续本地化

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

参见

与 Weblate 集成 描述了将您的开发集成到 Weblate 中的基本方式。代码托管集成 列出常见代码托管站的适用于特定供应商的配置步骤。

这是过程：

1. 开发人员进行更改并将其推送到版本控制系统仓库。

2. 可以选择更新翻译文件，请参阅 引入新字符串。

3. Weblate 从版本控制系统仓库中拉取更改，解析翻译文件并更新其数据库，见 更新仓库。

4. 译者使用 Weblate Web 界面提交翻译，或上传离线更改。

5. 译者完成后，Weblate 会将更改提交到本地仓库（请参阅 惰性提交）。

6. 更改被推送回上游仓库（见 推送 Weblate 的更改）。

提示

上游代码托管不是必需的，你可以通过 本地文件 使用 Weblate，在本地 VCS 中只有 Weblate 内的仓库。

更新仓库

你应该设置某种方式，从后端仓库的源头更新它们。

• Use 通知钩子 to integrate with the majority of common code hosting services, see 代码托管集成. You must also 启用钩子 for this to work.

• 在仓库管理中或使用 Weblate 的 REST API 或 Weblate 客户端 来手动触发更新

• 启用 AUTO_UPDATE 以自动更新你的 Weblate 实例上的所有部件

• 执行 updategit（选择项目，或 --all 来更新全部）

每当 Weblate 更新仓库时，更新后附加组件都将被触发，请参见：附加组件。

避免合并冲突

当同一文件在 Weblate 内外都被更改时，就会出现来自 Weblate 的合并冲突。根据情况不同，有几种方法可能会有帮助：

• 只更改 Weblate 中的翻译文件来避免合并冲突

• 做外部更改时锁定 Weblate 来避免合并冲突

• 聚焦 Git 操作避免合并冲突

只更改 Weblate 中的翻译文件来避免合并冲突

对于单语文件来说，避免 Weblate 之外的编辑是容易的——您可以在 Weblate 中添加新字符串，并将文件的整个编辑留在那里。对于双语文件，通常存在某种信息提取过程可以从源代码生成可翻译文件。在一些情况下，这可以分成两部分：

1. 该提取生成模板（例如，gettext POT 是用 xgettext 生成的）。

2. 进一步的过程将它合并入实际翻译（gettext PO 文件用 msgmerge 更新）。

你可以在 Weblate 内执行第二步，它会确保所有未提交更改在此操作前被包含在内。

做外部更改时锁定 Weblate 来避免合并冲突

将 Weblate 集成到你的更新流程中，以便它在更新 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 客户端代替 Weblate 客户端 来实现这一点，例如 curl，请参见 Weblate 的 REST API。

仓库维护

仓库维护 视图显示项目、部件或翻译的仓库状态，并让特权用户从用户界面运行维护操作。

也可用 Weblate 的 REST API 触发相同操作，或为受支持的子集触发相同操作，Weblate 客户端。

单独操作的可用性取决于权限，配置的 VCS，是否配置了推送，是否所选对象可被锁定。

操作	它做什么	典型使用
提交	将存储在 Weblate 中的未提交更改提交到本地仓库。	在别处做仓库工作前冲洗未提交的 Weblate 更改。
推送	将提交的本地仓库更改推送到配置的上游。	当自动推送禁用或延迟时向上游发送提交的译文。
更新	获取上游更改并用部件配置的 合并方式 集成它们。	用默认集成策略让 Weblate 和上游同步。
以合并方式更新	获取上游更改并用显示合并集成它们。	覆盖单一更新的默认合并样式。
以变基方式更新	获取上游更改并在上游基础上变基本地 Weblate 提交。	当历史记录匹配工作流时保持历史记录线性。
用不含快进的合并进行更新	获取上游更改并创建显示合并提交，即使可以快进。	出于审计或分支管理理由保留合并提交。
锁定 / 解锁	阻止或允许译者在 Weblate 中进行进一步更改。	在 Weblate 以外维护仓库时冻结翻译更改。
重置并丢弃	重置 Weblate 的本地仓库到上游并丢弃未提交的 Weblate 更改。	当上游应当覆盖本地 Weblate 仓库状态时使用。
重置并重新应用	重置 Weblate 的本地仓库到上游同时保留未提交的翻译。见 重置并重新应用恢复行为。	从有差异的历史记录恢复，同时保留未提交的 Weblate 翻译。
清理	从本地仓库签出中移除未跟踪的文件和过时分支。	清理 Weblate 签出中残留文件或过时仓库状态。
同步	强制 Weblate 将所有已知的译文写回仓库文件。	修复仓库文件与数据库状态不同步的情况。
重新扫描	将来自本地仓库的翻译文件重新读取到 Weblate 中。	在手动进行仓库操作或创建文件后导入文件更改。

重置并重新应用恢复行为

重置和重新应用 操作保留来自 Weblate 的待提交更改，同时重置本地仓库状态来匹配上游。

该操作只有在重置后目标语言文件仍存在或者 Weblate 能用有效的 新语种的翻译模版 为该部件创建这些文件时可以恢复未提交的翻译。

如果这些条件均不满足，Weblate 会在其数据库中保留未提交的更改并报告恢复错误，而不是稍后因一般性的解析错误而出现故障。

聚焦 Git 操作避免合并冲突

即便 Weblate 是翻译文件更改的单一来源，当使用 挤压 Git 提交 附加组件、合并方式 被配置为 Rebase，或者你在挤压 Weblate 外面的提交（比如合并拉取请求）时，也可能发生冲突。

此情形下，合并冲突的原因不同。比如，你在上游合并之前的 Weblate 提交后，Weblate 可能有新的本地提交。出现这种情况通常是因为合并操作不是自动进行的，更改要等待几天或数周进行人工审核。Git 有时会无法识别上游的更改是否与 Weblate 匹配，并拒绝执行变基操作。

Squash merging Weblate changes makes this harder to recover from. A squash merge creates a new commit instead of preserving the individual Weblate commits in the upstream history. Weblate still has the original commits in its local repository, and Git can no longer prove that upstream already contains them. If the conflict was also resolved manually, the file contents can differ from both repositories, so Weblate can keep failing to update even after the pull request was merged upstream.

If upstream no longer contains Weblate commits because they were squash merged, updating the repository might not be enough. Use Reset and reapply from Repository maintenance to reset Weblate to upstream while keeping pending translations; see 重置并重新应用恢复行为. Use Reset and discard only when upstream should fully replace Weblate's local changes.

要解决此问题，你需要在合并拉取请求时尽量减少 Weblate 中的待处理更改，或者通过不挤压更改来完全避免冲突。

这里有几个避免这一问题的选项：

• 别对 Weblate 更改使用 挤压 Git 提交 或挤压合并。挤压操作是 Git 为何在合并后不再识别更改的原因。

• When resolving conflicts outside Weblate, merge the Weblate commits with a regular merge commit and push that result upstream. Do not squash merge the conflict-resolution pull request.

• 在合并前让 Weblate 提交未提交更改。这会更新拉取请求的所有更改，且两个仓库会处于同步状态。

• 使用 Weblate 中的审阅功能（见 翻译工作流），这样你可以在 CI 通过后自动合并 GitHub 拉取请求。

• 在 Weblate 中使用锁定避免在审核 GitHub 拉取请求时的更改。

参见

Weblate 客户端

代码托管通知

Provider-specific app and webhook instructions for GitHub, GitLab, Bitbucket, Pagure, Azure Repos, Gitea, Forgejo, and Gitee are covered in 代码托管集成.

特定提供商的通知

These legacy anchors are kept for compatibility. Current provider-specific app and webhook setup is documented in 代码托管集成.

参见

• GitHub notifications

• GitLab notifications

• Bitbucket notifications

• Pagure notifications

• Azure Repos notifications

• Gitea notifications

• Forgejo notifications

• Gitee notifications

每晚自动更新仓库

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

推送 Weblate 的更改

每个翻译部件可以新建推送 URL（请参见 仓库推送 URL），在那种情况下 Weblate 能够将更改推送到远程仓库。Weblate 还可以配置在每次提交时自动推送更改（请参见 提交时推送）。

For the push options table and provider-specific pull, merge, and review request workflows, see 推送 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 与仓库交互的方式是 附加组件。关于如何通过附加组件执行外部脚本的信息，请咨询 从附加组件执行脚本。

跨部件保持翻译一致

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

翻译传播

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

传播前提条件：

• 所有部件必须位于单个项目中（仅链接部件是不够的）。

• 开启 允许同步翻译 自动地为匹配的字符串重用译文。

• 翻译传播需要密钥来匹配单语言翻译格式，因此在建立翻译密钥后请牢记。

• 字符串在翻译时会传播，从仓库加载的字符串不会传播。

小技巧

此功能目前存在一些限制，我们希望使其更加通用。请在 https://github.com/WeblateOrg/weblate/issues/3166 分享您的反馈。

一致性检查

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

自动翻译

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