当‘Adaptive Icons’翻译成‘自适应图标’：记录我在专业领域做多语言适配的踩坑日记

1. 糟糕的开头

凌晨一点，我在调整“App 图标大小”工具的日语界面。当我看到自动翻译把 iOS 的 “Master Size” 翻译成日语中类似于“工匠师傅的尺寸”时，我手里的无糖可乐差点喷在屏幕上。

那是一种极度专业的不适感。在开发者工具这个细分领域，翻译错误不仅仅是文字不通顺，它会让用户觉得这个工具的作者根本不懂技术。

2. 我的思考

daima.life 走向全球化的过程中，最难的不是配置 next-intl 的路由，而是寻找那些**“技术语感”**。每一个技术词汇，比如 Android 的 Adaptive Icons、HarmonyOS 的 Super Device，在不同的目标语言环境里都有其特定的行业共识。

我们不能简单地依赖 Google 翻译或 AI 直刷。我们要构建的是一套基于上下文的**“垂直领域词典”**。在 2026 年，由于 Apple Vision Pro 和鸿蒙系统的全面普及，这类专有名词的爆炸式增长让适配工作变成了一场持久战。

3. 技术硬核区

我们选择 next-intl 的核心原因是它对 ICU Message Format 的完美支持。这让我们能处理非常复杂的动态技术描述。

例如我们的翻译文件结构：

// messages/zh.json
{
  "AppIconSize": {
    "platforms": {
      "android": {
        "title": "Android (自适应图标)",
        "masterSizeNote": "提供一张 {size}px 的正方形原图，系统将自动切割安全区域。"
      }
    }
  }
}

在 04-07 的重构中，我们特别优化了“动态插值”逻辑。对于不同平台的显示逻辑，我们不再在组件里写 if/else，而是全部交给语言包中的变量控制。

// 组件代码极其精简
<p>{t('platforms.android.masterSizeNote', { size: platform.masterSize })}</p>

这种做法将“技术细节”与“语言表达”彻底解耦。即便以后 HarmonyOS 增加了一个新的尺寸规格，我们也只需要更新 JSON 配置，而不需要动任何业务代码。

4. FAQ 模块

Q1: 为什么不用全自动 AI 翻译？ AI 在处理通俗文本时很强，但在处理“技术梗”和特定平台的专有名词（比如 iOS 的 @2x/@3x 习惯）时，容易产生幻觉。我们采用的是“AI 初稿 + 极客人工校对”的流水线。

Q2: 如何处理日语中大量的片假名技术词汇？ 这是最头疼的。有些词日本开发者习惯用英语原词，有些则习惯用片假名（如 アイコン vs Icon）。我们的原则是：参照各平台官方（Apple/Google/Huawei）的开发者文档作为最高准则。

5. 结尾

多语言适配不是一次性的功能上线，它是一种长期的文化渗透。在 04-07，我们通过了全站 3 种语言的“语感测试”。当你切换到日语或英语模式，感受到那种“丝滑且专业”的氛围时，那背后其实是我们对每一个像素和词汇的死磕。你想来感受一下这种跨越国界的技术之美吗？