持续本地化集成

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

参见

与 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 的直接推送,系统也支持 GitHubGitLabvcs-pagure`的拉取请求或 :ref:`vcs-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 )仓库,例如合并,你可能需要明确地告诉它去做提交(这对 Managers`组是默认允许的,参见 :ref:`privileges)。

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

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

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

  • 明确地请求了提交。

  • 更改比 组件配置 上定义为 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 与仓库交互的方式是 附加组件 。关于如何通过插件执行外部脚本的信息,请咨询 从附加组件执行脚本

跨组件保持翻译一致

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

翻译宣传

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

注解

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

一致性检查

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

自动化翻译

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