持续本地化集成

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

参见

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

这是过程:

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

  2. 可以选择更新翻译文件(这取决于文件格式,请参阅 当已经更新了模板时,为什么 Weblate 仍然显示旧的字符串?)。

  3. Weblate 从版本控制系统(VCS)仓库中拉取更改,请参阅 更新仓库

  4. 一旦 Weblate 检测到翻译更改,便会根据翻译者的订阅设置通知他们。

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

  6. 翻译者完成后,Weblate 会将更改提交到本地仓库(请参阅 惰性提交),如果有权限将其推回(请参阅 推送 Weblate 的更改)。

digraph translations { graph [fontname = "sans-serif", fontsize=10]; node [fontname = "sans-serif", fontsize=10, margin=0.1, height=0]; edge [fontname = "sans-serif", fontsize=10]; "Developers" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Translators" [shape=box, fillcolor="#144d3f", fontcolor=white, style=filled]; "Developers" -> "VCS repository" [label=" 1. Push "]; "VCS repository" -> "VCS repository" [label=" 2. Updating translations ", style=dotted]; "VCS repository" -> "Weblate" [label=" 3. Pull "]; "Weblate" -> "Translators" [label=" 4. Notification "]; "Translators" -> "Weblate" [label=" 5. Translate "]; "Weblate" -> "VCS repository" [label=" 6. Push "]; }

更新仓库

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

每当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 )中,如下图所示:

../_images/github-settings.png

对于负载 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/ )。

../_images/bitbucket-settings.png

从 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 中完成:

../_images/pagure-webhook.png

从 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 中完成。

从 Gitee Repos 自动接收更改

3.9 新版功能.

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 还可以配置在每次提交时自动推送更改(这是默认的,请参见 提交时推送 )。如果不想更改自动给推送,可以在 Repository maintenance 之下手动进行,或通过 wlc push 使用 API。

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

如果不想要 Weblate 的直接推送,系统也支持 GitHubGitLabPagure 的拉取请求或 Gerrit 审核。 你可以通过在 组件配置 中选择 GitHubGitLabGerritPagure 作为 版本控制系统 来激活这些。

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

需要的设置

版本控制系统

代码库推送 URL

推送分支

不推送

Git

直接推送

Git

SSH URL

推送到单独的分支

Git

SSH URL

分支名称

来自分叉的 GitHub 拉取请求

GitHub

来自分支的 GitHub 拉取请求

GitHub

SSH URL 1

分支名称

来自分叉的 GitLab 合并请求

GitLab

来自分支的 GitLab 结合请求

GitLab

SSH URL 1

分支名称

来自分叉的 Pargue 合并请求

Pagure

来自分支的 Pagure 合并请求

Pagure

SSH URL 1

分支名称

1(1,2,3)

源代码库 支持推送的情况下可以为空。

注解

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

参见

请参见 Accessing repositories 来设置 SSH 密钥,和 惰性提交 获得关于 Weblate 决定提交更改的信息。

受保护的分支

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

例如在 GitHub ,这可以在仓库配置中进行:

../_images/github-protected.png

合并或变基

Weblate 默认将 上游仓库结合到自身。在你还通过其他方式访问下层仓库的情况下,这是最安全的方式。在不需要这个的情况下,可以允许上游更改的变基,这会产生较少的融合提交的历史。

注解

在复杂融合的情况下,变基可能使你产生麻烦,因此请仔细考虑是否允许它们。

与他人交互

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

惰性提交

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

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

  • 某人另外更改了已经被更改的字符串。

  • 来自上游的结合发生了。

  • 明确地请求了提交。

  • 更改比 组件配置 上定义为 Age of changes to commit 的时间段更陈旧。

提示

每个组件都建立提交。所以在具有很多组件的情况下,仍然会看到很多提交。在这种情况下你会使用 压缩(Squash) 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,
    }
}

用脚本处理仓库

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

跨组件保持翻译一致

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

翻译宣传

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

注解

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

一致性检查

任何时候字符串不同时 不一致的 都会检查启动。可以使用这个来手动复查这样的差异,并选择正确的翻译。

自动化翻译

基于不同组件的自动翻译,可以是跨组件同步翻译的方式。可以或者手动触发(请参见 自动化翻译 ),或者使用插件( 自动化翻译 )在仓库更新时自动运行。