七种语言：为什么本地化是一项可靠性功能

Tactic Remote 现已完整支持七种语言：英语、简体中文、日语、韩语、西班牙语、德语和法语。这不是一个"我们把字符串丢进翻译 API"的公告。在一个处理网络配置、终端输出和系统级操作的开发者工具中，本地化所要求的标准与消费者应用翻译截然不同。

本文介绍我们的技术方案、那些教会我们将本地化视为可靠性工程的 bug，以及我们在国际用户增长中观察到的数据。

七种语言

我们的语言选择基于私测期间的用户数据和需求量：

我们优先选择那些既有用户需求、又能联系到母语开发者来验证技术准确性的语言。开发者工具的本地化需要领域专业知识——将"session"、"tunnel"或"hook"翻译成日语，需要理解这些术语的技术含义，而不仅仅是查字典。

不仅仅是字符串翻译

iOS 本地化的标准做法很直接：将面向用户的字符串提取到 .strings 或 .xcstrings 文件中，提供翻译，让系统处理显示。我们也这样做，但真正有趣的工程在字符串替换之下的层面。

语言环境感知的输入处理

改变我们本地化理念的那个 bug：德语区域设置的用户在初始设置时无法输入 IP 地址。

德语区域设置下的 iOS 键盘默认使用逗号作为小数分隔符。当德语区域的用户在数字键盘上点击"."键区域时，得到的是逗号。像 192.168.1.100 这样的 IPv4 地址会被输入为 192,168,1,100——我们的验证将其判定为格式错误而拒绝。

这不是翻译 bug，而是区域设置行为 bug。界面字符串翻译正确，但输入机制因键盘布局假设而失效。我们通过在 IP 地址输入框中标准化逗号到句点的转换，以及呈现始终显示句点键的自定义键盘配置来修复此问题。

在修复前，这单个 bug 导致了德语区域用户约 23% 的设置失败。部署修复后，德语区域的首次运行完成率在一个发布周期内就与英语基准线持平。

复数形式和语法一致性

带计数的字符串插值是经典的本地化陷阱。英语处理起来很简单："1 session" 和 "2 sessions"。其他语言有更复杂的复数规则：

• 日语和韩语没有语法复数——无论数量多少都使用相同的形式。
• 法语在 2 及以上时对大多数名词加复数，但某些表达方式有不同的行为。
• 德语的复合词可能根据语法格和复数性变化形式。

我们使用 iOS 的 stringsdict 复数规则系统，支持 CLDR 复数类别（zero、one、two、few、many、other）。每个包含计数的面向用户的字符串都通过复数感知的格式化处理，而不是简单的字符串拼接。

从右到左布局的准备

我们当前的七种语言都不需要 RTL 布局，但我们的 UI 架构已经考虑到了这一点。所有布局约束使用 leading/trailing 锚点而非 left/right。文本对齐设置为 .natural。这意味着当我们添加阿拉伯语或希伯来语支持时——这两种语言都有活跃的开发者社区——布局工作将是最小的。

MDX 内容本地化

Tactic Remote 的网站和文档使用 MDX 构建。文档内容的本地化需要与应用字符串本地化不同的策略。

每个 MDX 文档可以有使用文件名后缀约定的特定语言变体：product-update.mdx（英语默认）、product-update.zh-CN.mdx（中文）、product-update.ja.mdx（日语），以此类推。内容路由器检测用户的首选语言并提供相应的变体，当本地化版本不存在时回退到英语。

这种方法有一个刻意的权衡：我们不会将每个文档页面翻译成每种语言。技术设置指南和 API 参考保留英语，因为它们包含代码示例、命令行指令和配置值，这些与语言无关。我们将本地化工作集中在语言障碍实际阻碍理解的内容上：产品公告、概念概述和引导流程。

目前，34% 的 MDX 内容至少有一个非英语变体。我们根据页面流量和客服工单的关联性确定优先级——如果某个页面不成比例地产生来自特定语言群体的支持问题，该页面就会被优先本地化。

可靠性论证

我们将本地化视为可靠性功能有一个具体原因：一个因区域设置相关的输入 bug 而无法完成设置的开发者，与一个因网络错误而无法连接的开发者处于相同的状态。产品对他们来说是坏的。根因是"我们假设了英语键盘布局"而不是"我们有一个 TCP bug"，这并不改变用户体验。

这种定义对我们的工程流程有实际影响：

特定区域设置的测试矩阵。 我们的 CI 在六种非英语区域设置配置下运行关键路径测试（设置流程、连接建立、审批流程）。德语区域 IP 输入的回归会在合并前被发现。

本地化 bug 获得严重级别 1 的分级处理（当它们阻塞核心功能时）。翻译错误的标签是外观问题。依赖区域设置的输入失败是生产事故。

发布前的字符串冻结。 我们在每次发布前 72 小时冻结英语字符串，给翻译人员一个稳定的目标。翻译由团队中的母语开发者验证，而不仅仅是语言学家。

国际化采用情况

自发布多语言支持以来，我们的用户群出现了可衡量的变化：

• 非英语区域用户 在六周内从周活跃用户的 18% 增长到 41%。
• 简体中文用户 现在是第二大语言群体，占周活跃用户的 15%。
• 日语用户 在所有语言群体中平均会话时长最高——52 分钟，而整体平均为 47 分钟。
• 设置完成率 在所有区域设置中现在与英语基准线的差距在 2 个百分点以内。在本地化工作之前，某些区域的完成率比英语低 15-20%。

设置完成率的收敛是我们最关心的指标。它验证了本地化正在弥合可靠性差距，而不仅仅是添加翻译后的标签。

下一步计划

我们正在基于相同的标准扩展语言支持：用户需求加上能联系到母语技术审阅者。

• 我们正在根据用户需求和母语技术审阅者的可用性评估更多语言。
• 我们正在构建翻译的社区贡献工作流，通过审核流程确保合并前的技术准确性。

关于语言检测和回退机制的详情，请参阅本地化架构。如果你想为尚未支持的语言贡献翻译，请通过支持页面联系我们。