持续本地化¶
有适当的基础结构,因此你的翻译紧随开发。这样,翻译人员可以一直进行翻译,而不必在发布之前处理大量的新文本。
参见
与 Weblate 集成 描述了将您的开发集成到 Weblate 中的基本方式。代码托管集成 列出常见代码托管站的适用于特定供应商的配置步骤。
这是过程:
开发人员进行更改并将其推送到版本控制系统仓库。
可以选择更新翻译文件,请参阅 引入新字符串。
Weblate 从版本控制系统仓库中拉取更改,解析翻译文件并更新其数据库,见 更新仓库。
译者使用 Weblate Web 界面提交翻译,或上传离线更改。
译者完成后,Weblate 会将更改提交到本地仓库(请参阅 惰性提交)。
更改被推送回上游仓库(见 推送 Weblate 的更改)。
提示
上游代码托管站点不是必需的,你可以通过 本地文件 使用 Weblate,在本地 VCS 中只有 Weblate 内的仓库。
更新仓库¶
你应该设置某种方式,从后端仓库的源头更新它们。
在仓库管理中或使用 Weblate 的 REST API 或 Weblate 客户端 来手动触发更新
启用
AUTO_UPDATE以自动更新你的 Weblate 实例上的所有部件执行
updategit(选择项目,或--all来更新全部)
每当 Weblate 更新仓库时,更新后附加组件都将被触发,请参见:附加组件。
避免合并冲突¶
当同一文件在 Weblate 内外都被更改时,就会出现来自 Weblate 的合并冲突。根据情况不同,有几种方法可能会有帮助:
只更改 Weblate 中的翻译文件来避免合并冲突¶
对于单语文件来说,避免 Weblate 之外的编辑是容易的——您可以在 Weblate 中添加新字符串,并将文件的整个编辑留在那里。对于双语文件,通常存在某种信息提取过程可以从源代码生成可翻译文件。在一些情况下,这可以分成两部分:
该提取生成模板(例如,gettext POT 是用 xgettext 生成的)。
进一步的过程将它合并入实际翻译(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 标记的重复字符串问题。 |
清理未使用的项目 |
从单个翻译文件中移除源语言文件(基准文件)中已不存在的字符串。清理翻译文件 附加组件可自动执行此操作。 |
无需安装附加组件,直接运行一次性清理。 |
移除陈旧项 |
从单个 PO 翻译文件中删除陈旧字符串。 |
无需启用自动清除弃用字符串功能,直接运行一次性 PO 文件清理。 |
重置并重新应用恢复行为¶
重置和重新应用 操作保留来自 Weblate 的待提交更改,同时重置本地仓库状态来匹配上游。
该操作只有在重置后目标语言文件仍存在或者 Weblate 能用有效的 新语种的翻译模版 为该部件创建这些文件时可以恢复未提交的翻译。
如果这些条件均不满足,Weblate 会在其数据库中保留未提交的更改并报告恢复错误,而不是稍后因一般性的解析错误而出现故障。
聚焦 Git 操作避免合并冲突¶
即便 Weblate 是翻译文件更改的单一来源,当使用 挤压 Git 提交 附加组件、合并方式 被配置为 Rebase,或者你在挤压 Weblate 外面的提交(比如合并拉取请求)时,也可能发生冲突。
此情形下,合并冲突的原因不同。比如,你在上游合并之前的 Weblate 提交后,Weblate 可能有新的本地提交。出现这种情况通常是因为合并操作不是自动进行的,更改要等待几天或数周进行人工审核。Git 有时会无法识别上游的更改是否与 Weblate 匹配,并拒绝执行变基操作。
以压缩合并(Squash merge)方式合并 Weblate 的变更会导致此类问题更难恢复。压缩合并会生成一个新的提交,而不是在远程主仓库的提交历史记录中保留 Weblate 的各个原始提交。Weblate 本地仓库中依然保留着这些原始提交,导致 Git 无法判定远程仓库是否已经包含了它们。如果在此过程中还手动解决了冲突,文件内容可能会与两个仓库都产生差异,最终导致即便 PR 已在远程合并,Weblate 依然会持续更新失败。
如果因为 Weblate 提交被压缩合并造成上游不再包含 Weblate 提交,更新仓库可能不够。可在 仓库维护 中使用 重置并重新应用,在保留待处理翻译的同时将 Weblate 重置为上游状态,详见 重置并重新应用恢复行为 。仅在上游应完整替换 Weblate 本地变更时使用 重置并丢弃。
要解决此问题,你需要在合并拉取请求时尽量减少 Weblate 中的待处理更改,或者通过不挤压更改来完全避免冲突。
这里有几个避免这一问题的选项:
别对 Weblate 更改使用 挤压 Git 提交 或挤压合并。挤压操作是 Git 为何在合并后不再识别更改的原因。
在 Weblate 之外解决冲突时,请使用常规合并提交(Merge commit)来合并 Weblate 的提交,并将其推送到远程仓库。切勿对用于解决冲突的 Pull Request 执行压缩合并(Squash merge)。
在合并前让 Weblate 提交未提交更改。这会更新拉取请求的所有更改,且两个仓库会处于同步状态。
使用 Weblate 中的审阅功能(见 翻译工作流),这样你可以在 CI 通过后自动合并 GitHub 拉取请求。
在 Weblate 中使用锁定避免在审核 GitHub 拉取请求时的更改。
参见
代码托管通知¶
有关 GitHub、GitLab、Bitbucket、Pagure、Azure Repos、Gitea、Forgejo 及 Gitee 的特定平台应用与 Webhook 配置说明,详见 代码托管集成。
特定提供商的通知¶
保留这些旧版的锚点链接是为了保持兼容性。当前特定平台的应用与 Webhook 配置说明,请参阅 代码托管集成。
每晚自动更新仓库¶
Weblate 在后面合并更改时,每晚自动获取远程仓库来提高性能。可以选择将其同样转换为进行每晚合并,通过允许 AUTO_UPDATE。
推送 Weblate 的更改¶
每个翻译部件可以新建推送 URL(请参见 仓库推送 URL),在那种情况下 Weblate 能够将更改推送到远程仓库。Weblate 还可以配置在每次提交时自动推送更改(请参见 提交时推送)。
有关推送选项表以及特定平台的拉取(Pull)、合并(Merge)和评审(Review)请求工作流,请参阅 推送 Weblate 的更改。
受保护的分支¶
如果在受保护的分支上使用 Weblate,可以配置使用拉取请求,并执行翻译的实际复查(对你不知道的语言可能有问题)。另一个方法是去掉对 Weblate 推送用户的这个限制。
例如在 GitHub,这可以在仓库配置中进行:
与他人交互¶
Weblate 通过使用它的 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 分享您的反馈。
一致性检查¶
只要字符串存在差异,就会触发 不一致的 检查。可以利用此检查来手动复查这些差异,并选择正确的翻译。
自动翻译¶
基于不同部件的自动翻译,可以是跨部件同步翻译的方式。可以或者手动触发(请参见 自动翻译),或者使用附加组件(自动翻译)在仓库更新时自动运行。