持续本地化集成¶
有适当的基础结构,因此您的翻译紧随开发。这样,翻译人员可以一直进行翻译,而不必在发布之前处理大量的新文本。
这是过程:
开发人员进行更改并将其推送到 VCS 仓库。
可以选择更新翻译文件(这取决于文件格式,请参阅 Why does Weblate still show old translation strings when I’ve updated the template?)。
Weblate 从 VCS 仓库中拉取更改,请参阅 更新仓库。
一旦 Weblate 检测到翻译更改,便会根据翻译者的订阅设置通知他们。
翻译者使用 Weblate Web 界面提交翻译,或上传离线更改。
翻译者完成后,Weblate 会将更改提交到本地仓库(请参阅 惰性提交),如果有权限将其推回(请参阅 推送 Weblate 的更改)。
更新仓库¶
应该设置一些方式来从他们的源更新后端仓库。
使用 通知钩子 来与多数常见的代码托管服务集成
在仓库管理中或使用 API 或 Weblate 客户端 来手动触发更新
允许
AUTO_UPDATE
在您的Weblate事例上自动更新所有组件执行
updategit
(选择项目,或 –all 来更新全部)
无论何时 Weblate 更新仓库,都将出发以前更新插件,请见: 附加组件 。
避免合并冲突¶
当相同的文件在 Weblate 之内与之外都更改时导致 Weblate 的合并冲突。有两种方法来处理——避免在 Weblate 之外编辑,或者将 Weblate 集成到您的更新过程中,从而在更新 weblate 之外的文件之前刷新更改。
第一种方法容易用于单语种文件——可以添加 Weblate 之内的新字符串,并将文件的整个编辑留在那里。对于双语种文件,通常存在某种消息提取过程而从源代码产生翻译文件。在一些情况下,这可以分成两部分——一部分用于提取过程产生模板(例如使用 xgettext 产生 gettex POT ),然后下一步过程将它合并到真正的翻译中(例如使用 msgmerge 更新 gettext PO 文件)。可以在 Weblate 中执行第二步,它将确认在这个操作前所有挂起的更改都包括进去了。
第二种方法可以这样实现,使用 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 来实现,请见 API 。
从 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 事件)。
从 Bitbucket 自动接收更改¶
Weblate 已经支持 Bitbucket webhooks ,添加仓库推送时触发的 webhook ,目的地为您 Weblate 安装上的 /hooks/bitbucket/
(例如 https://hosted.weblate.org/hooks/bitbucket/
)。
从 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 中完成:
从 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 直接推送的情况下,有对 GitHub 、 GitLab 推送请求或 Gerrit 复查的支持,可以通过选择 GitHub 、 GitLab 或 Gerrit 作为 Component configuration 中的 版本控制系统 来激活。
整体上, Git 、 GitHub 和 GitLab 可以具有后面的选项:
需要的设置 |
|||
---|---|---|---|
不推送 |
empty |
empty |
|
直接推送 |
SSH URL |
empty |
|
推送到单独的分支 |
SSH URL |
分支名称 |
|
来自叉子的 GitHub 拉取请求 |
empty |
empty |
|
来自分支的 GitHub 拉取请求 |
SSH URL 1 |
分支名称 |
|
来自叉子的 GitLab 结合请求 |
empty |
empty |
|
来自分支的 GitLab 结合请求 |
SSH URL 1 |
分支名称 |
注解
还可以允许 Weblate 提交后更改的自动推送,这可以在 提交时推送 中完成。
参见
请见 Accessing repositories 来设置 SSH 密钥,和 惰性提交 获得关于 Weblate 决定提交更改的信息。
受保护的分支¶
如果在受保护的分支上使用 Weblate ,可以配置使用推送请求,并执行翻译的实际复查(对您不知道的语言可能有问题)。另一个方法是去掉对 Weblate 推送用户的这个限制。
例如在 GitHub ,这可以在仓库配置中进行:
结合或变基¶
Weblate 默认将 上游仓库结合到自身。在您还通过其他方式访问下层仓库的情况下,这是最安全的方式。在不需要这个的情况下,可以允许上游更改的变基,这会产生较少的融合提交的历史。
注解
在复杂融合的情况下,变基可能是您产生麻烦,因此请仔细考虑是否允许它们。
惰性提交¶
Weblate的行为是,如果可能的话,将来自相同作者的提交分组成为一个提交。这极大地减少了提交的数量,然而,在您想要同步得到版本管理系统 VCS 仓库,例如用于结合的情况下(这对管理者群组是默认允许的,请见 访问控制 ),您可能需要明确告诉它进行提交。
一旦后面的任何条件满足,这种模式的更改将被提交:
某人另外更改了已经被更改的字符串。
来自上游的结合发生了。
明确地请求了提交。
更改比 Component configuration 上的 Age of changes to commit 定义的时间段更陈旧。
提示
每个组件都建立提交。所以在具有很多组件的情况下,仍然会看到很多提交。在这种情况下您会使用 压缩 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,
}
}
在部件之间保持翻译一致¶
一旦具有多个翻译组件,您会想要确保相同的字符串具有相同的翻译。这可以在几个层次实现。
翻译宣传¶
允许翻译宣传时(这是默认的,请见 Component configuration ),在所有的组件中字符串匹配时,所有新的翻译自动进行。在所有的组件中这样的翻译都适当地归功于当前翻译的用户。
注解
翻译宣传需要密钥来匹配单语种翻译格式,因此在建立翻译密钥匙请记住。