让编程代理统一三端文案与翻译键

把界面文案交给 AI 翻译，难点往往不在翻译，而在同一句话分散在多个平台、占位符不能改坏、译文长度还得适合按钮。作者做的 locli，试图把这些问题放进一条完整流程：由编程代理整理文案、统一标识、辅助翻译，再由人批准发布。

作者已把它用于自己的 6 个应用，覆盖约 2,650 个键。这份经验值得看的是流程设计；至于换到多人团队后能省多少时间，原文没有对照数据。

先统一文案身份，翻译才不会越做越乱

作者的应用同时覆盖 iOS、Android，部分还有 Web。几轮发布之后，文案一部分硬编码在 SwiftUI 和 Compose 界面里，另一部分虽然进了资源文件，命名却各自为政。

同一个登录按钮，iOS 可能叫 Sign in、account.login 或 login_button，Android 用 R.string.login_btn，Web 又叫 auth.signIn。三套名字让翻译重复维护，也更容易出现用词漂移。

他们的第一步是让代理把硬编码文案搬进各平台原有的目录：iOS 用 String Catalog，Android 用 strings.xml，Web 或后端用 ICU JSON。业务代码改为按键读取。

接着统一为带功能前缀的 lower_snake_case，例如 account_login、settings_language_title、cart_checkout。跨平台表达同一个含义，就共用一个标识；某个平台确实需要不同措辞，再建立对应变体。

这里统一的是含义，不能只看原文是否相同。两个位置都显示「打开」，也可能分别指打开文件和开启功能。

合并时，代理还要保留已有译文、更新代码引用。遇到同一个按钮存在两份不同的德语译文，才停下来让作者判断，而不是自行选一份。

翻译上下文，比多写一句提示词更重要

locli push 上传键和文本，并按作者描述保留翻译人员已经修改的内容。随后，代理结合两类信息翻译：项目为不同语言设定的语气和术语表，以及文案在代码中的使用位置。

例如术语表要求统一使用 workspace，不能随意换成 project；locli context 则通过读取代码，判断 cart_checkout 是工具栏项目，cart_title 是页面标题。

这能帮助代理判断译文需要多简短、承担什么作用。同一句表达放在标题和按钮里，合适的写法可能不同。

上传时还会检查 %lld、{count} 等占位符、各语言的复数形式和术语使用。波兰语、阿拉伯语的复数规则不能只靠 one、other 两类覆盖。

上下文帮助选词，校验负责拦住结构错误，两者不能互相替代。

不过，原文没有展示占位符检查的实现，也没有提供翻译准确率或界面溢出的测试结果。知道文案用于工具栏，并不等于已经验证它能在真实屏幕上放得下。

发布必须绑定批准的版本

这条流程最后留了一道人工作业：作者在 locli Web 应用里查看文案差异，批准一个发布版本。之后，locli pull 才把该版本写入应用。

这样，构建取用的是一份明确批准的内容，而不是随时变化的最新译文。作者希望借此保证构建可复现，并避免代理凭自信把错误翻译送进商店。

作者使用 Claude Code，也表示 Cursor 和 Codex 可以采用同样的流程。他在自己的 6 个应用中管理约 2,650 个键，覆盖 iOS、Android、Web 和后端，locli 自己的 Web 应用也用它做本地化。

这些实际使用确实发现过兼容问题：当前 Xcode 保存的 String Catalog 版本为 1.1，CLI 起初拒绝读取。作者称已为发现的问题补上修复和测试。

仓库内的初始化入口如下，用于开始配置应用文案：

npx @locli/cli init

注意包名是 @locli/cli；这条命令只是初始化入口，原文没有展开迁移配置细节。

Claude Code 还可以安装插件，让代理接入这套流程：

/plugin marketplace add mariohahn/locli
/plugin install locli@locli

注意先添加 marketplace，再安装插件。作者称 CLI 和 MCP server 采用 MIT 许可、没有依赖，并提供一个免费项目；原文没有说明托管服务的完整授权及额度边界。

我的判断

我认同的是它把整理、翻译、校验、审批连起来了。相比直接让代理批量改资源文件，这套流程更清楚地回答了两个问题：谁处理冲突，以及构建最终取哪份译文。

但跨平台共用键需要稳定的语义边界。移动端短按钮和 Web 上的解释性操作，未必适合共用同一措辞。原文允许建立变体，这是必要的余地，不能为了减少键的数量强行合并。

6 个自有应用能证明作者实际用过，不能证明多人团队的审核成本、协作冲突和规模表现。原文也没有与现有本地化平台或仓库内脚本做对照，效率收益仍应视为作者的经验判断。

能拿来做什么

• 先盘点前端项目里的硬编码和重复键，按含义整理命名；合并时保留已有译文，并把语义冲突交给人确认。
• 给 AI 翻译任务附上使用位置、语气和术语表。标题、按钮、工具栏操作应有明确上下文，不能只传一个孤立字符串。
• 在资源检查中覆盖占位符和语言复数规则，并保留真实界面的人工检查，尤其关注长译文能否正常显示。
• 如果让编程代理参与本地化，把文案修改与发布批准分开，让构建读取明确批准的版本。