01
字符串改动会隐藏在大型拉取请求中，而不清楚其本地化影响。
轮班
本地化仍然是发布流程之外的手动步骤
02
工程和本地化通过 Slack 协调，而不是在 CI/CD 中。
03
翻译文件在各个版本之间会与源字符串产生偏差。
概览
开发人员每天合并字符串更改。本地化质量取决于是否有人记得在发布前检查。
01
用于本地化检查的 GitHub Action
在每个拉取请求上运行漂移检测、覆盖率检查和回归评估。
02
从 PR 差异中检测字符串更改
显示新增、修改和移除的键，并结合拉取请求描述和关联问题的上下文。
03
使用您偏好的 LLM 起草翻译
当字符串发生更改时，使用术语表和 TM 上下文自动生成区域设置草稿。
04
在拉取请求上评论本地化状态
在合并前，让审阅者清楚了解区域设置覆盖情况、质量标记以及未解决项。
它是如何运作的
从拉取请求到发布门控
Hyperlocalise 融入你团队现有的开发工作流——内置 GitHub Actions 和 TMS 同步。
01
拉取请求
检测新增、更改和移除的字符串
02
变更分析
将差异映射到语言环境和术语表影响
03
翻译草稿
使用你的 LLM 生成本地化草稿
04
审核路由
在你的 TMS 中打开审核任务
05
CI 检查
在 GitHub Actions 中运行本地化门禁
06
发布门槛
当区域设置未解析时阻止合并
核心功能
专为开发者主导的发布工作流程而设计
05
将已批准的字符串同步到您的 TMS
无需离开发布流程，即可将翻译推送到 Crowdin、Lokalise、Phrase 或 Smartling。
06
当质量门禁失败时阻止发布
配置检查，以防止在缺少关键语言环境或回归阈值被超出时进行合并。
为什么这不同
CI/CD 流水线中的本地化智能
Hyperlocalise 不是您 TMS 或 i18n 库的替代品。它添加了一个 AI 原生层，用于连接 GitHub 变更信号、翻译草稿和发布门控。
01与 TMS 无关
02与 LLM 无关
03需要审核时的人在回路中
04结合拉取请求和 issue 的上下文
05为工程和本地化运营而构建
06可跨 GitHub、TMS 和发布工具使用
示例工作流
价格页面重构在周二发起了一个拉取请求
一位开发者打开了一个拉取请求，将十四条 UI 字符串重命名并新增六条。Hyperlocalise 在 PR 上评论受影响的语言环境，使用链接的发布简报中的术语表上下文生成翻译草稿，在 Lokalise 中打开审校任务，运行 GitHub Action 以验证所有目标语言环境都已覆盖，并在德语和日语审校者批准更新后的定价术语之前阻止合并。
构建你的 AI 原生本地化工作流
加入 Hyperlocalise 等候名单，将本地化检查纳入您的发布流程。