让你的 App 多语言化（无需重写）

发布: 1个月前 (2026年3月17日 GMT+8 00:19)

11 分钟阅读

原文: Dev.to

Source: Dev.to

寻找折中方案

在 “仅英文” 与 “完整本地化为 40 种语言” 之间有一个务实的折中方案。大多数团队从未找到它，因为讨论直接从 “我们需要西班牙语” 跳到 “好吧，让我们在整个代码库中实现 i18n。” 那是一个需要数月的项目。有更快的启动方式。

开始关注面向用户的内容

将注意力放在应用中语言真正影响用户体验的部分：

产品描述
帮助文章
电子邮件通知
错误信息
入职流程

这些是非英语使用者会遇到障碍的地方。他们可能能够容忍英文的导航栏——按钮标签在不同语言间通常是可识别的——但解释关键功能的帮助文章或告诉他们出错原因的错误信息必须使用他们的语言。

翻译内容的工作量远小于对整个 UI 框架进行国际化，而且能够提供大部分的用户价值。

机器翻译 vs. 人工翻译

MT 的演进

五年前，机器翻译（MT）还是个笑柄。Google 翻译可以把法式餐厅菜单变成超现实主义诗歌，而专业人工译者是唯一严肃的选择。

情况已经改变。现代 MT 能很好地处理大多数欧洲语言和主要亚洲语言。它并不完美——在成语、文化引用以及高度专业的术语上仍有困难——但对于直接的内容（产品描述、支持文章、事务性邮件），其质量已经足够可用。

MT 适用场景（以及不适用场景）

适合的内容	不适合的内容
• 事实性内容	• 依赖文字游戏的营销文案
• 技术文档	• 对精确度要求极高的法律文件
• 事务性信息（订单确认、发货通知）	• 依赖文化背景的创意内容
• 知识库文章	• 语气与意义同等重要的任何内容
• 结构化且模式可预测的数据

第一类: MT 能让你完成 80‑90 % 的工作。
第二类: 仍需人工译者——但这部分内容的体量要小得多。

检测正确的语言

在翻译任何内容之前，您需要了解用户实际想要的语言。猜错比不翻译更糟。以下几个信号可以帮助：

浏览器语言标头 – 最可靠的自动信号。每个 HTTP 请求都会包含一个 Accept-Language 标头，列出用户偏好的语言顺序。
示例：es-MX,es;q=0.9,en;q=0.8 → 墨西哥西班牙语 > 通用西班牙语 > 英语。
账户设置 – 金标准。用户在个人资料中明确选择语言。仅对已登录且已配置设置的用户有效。
内容语言检测 – 适用于用户生成的输入（支持工单、表单提交）。检测提交文本的语言并相应地作出回应。
地理信号 – 粗略的代理（例如，位于日本的用户可能更倾向于日语）。这在外籍人士、旅行者以及多语言国家（瑞士、印度）中会失效。仅将其用作用户可以覆盖的默认选项。

实用分层

首要： 账户设置（如果可用）
次要： 浏览器 Accept-Language 标头
第三： 检测用户生成内容的语言

翻译优先级

入职流程 – 最高优先级。如果用户无法理解注册流程，他们永远不会成为用户。
事务性邮件 – 订单确认、密码重置、账单通知。用户需要理解这些内容才能使用您的服务。
错误信息 – 用英文显示的支付失败错误对说西班牙语的用户毫无帮助。翻译错误信息可以显著减少支持工单。
帮助文档与支持文章 – 实现自助服务，并且比雇佣多语言支持人员更具可扩展性。
营销页面 – 优先级最低，但可见度最高。不会阅读英文的潜在客户很可能是通过本地化搜索结果找到您的，因此本地化的着陆页至关重要。

程序化翻译内容

// Example: calling a translation API
const response = await fetch('https://api.apiverve.com/v1/translator', {
  method: 'POST',
  headers: {
    'x-api-key': 'YOUR_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    text: 'Your payment was processed successfully.',
    target: 'es'               // target language code
    // source: 'en'            // optional; omitted → auto‑detect
  })
});

const { data } = await response.json();
// data.translatedText → "Su pago fue procesado exitosamente."
// data.sourceLang    → "en"

注意： source 参数是可选的。省略时，API 会自动检测源语言，这在处理您不知道原始语言的用户生成内容时非常方便。

翻译字符串存放在哪里？

这取决于你的架构。 常见模式包括：

每个语言的独立 JSON/YAML 文件（例如 en.json、es.json）。
用于动态内容的数据库表（产品描述、帮助文章）。
CMS 驱动的本地化，编辑者直接在内容管理系统中管理翻译。

选择与您存储和提供内容方式相匹配的方法。

国际化策略

翻译存放位置

数据库 – 如果产品描述存放在数据库中，添加一个 locale 列，并将翻译后的版本作为单独的行存储。
相同内容 ID，不同语言。
翻译文件 – 适用于 UI 文本。以语言为键的 JSON 文件（en.json、es.json、fr.json）是标准的 i18n 做法。大多数前端框架都内置支持这种模式。
```
// en.json
{
  "welcome": "Welcome",
  "login": "Log in"
}

// es.json
{
  "welcome": "Bienvenido",
  "login": "Iniciar sesión"
}
```
即时生成 – 适合经常变化或对翻译精度要求不高的内容。
示例： 实时翻译客服聊天信息。用户会立即看到翻译结果，即使它并非人工打磨。
首次翻译后缓存 – 在成本与新鲜度之间取得平衡。第一次请求某语言的内容时进行翻译，随后将结果缓存并直接返回。这样既减少 API 调用，又保持翻译可用。

正确的做法通常结合这些方法：
静态 UI 文本放在翻译文件中。
数据库内容使用语言列。
聊天和用户生成内容采用实时翻译。

首批添加的语言选择

语言的选择是 业务决策，而非纯技术决策。

查看分析数据 – 你的现有用户分布在哪里？
- 如果有 15 % 的流量来自西班牙语国家，西班牙语显然是首选语言。
- 如果巴西的流量在增长，葡萄牙语应排在高位。
考虑市场策略 – 正在向特定地区扩张？在该地区正式上线前就先翻译当地语言，而不是事后补救。
思考语言覆盖范围 –
- 西班牙语 – 20 多个国家。
- 法语 – 欧洲、非洲、美洲。
- 普通话 – 世界人口最多的语言。
- 阿拉伯语 – 覆盖广阔的地理带。
这些高覆盖率语言能带来最高的翻译投资回报。
语言相似性 – 如果已经完成西班牙语翻译，葡萄牙语的增量工作量更小——两者在词汇和结构上有大量相似之处。这是少数“第二步比第一步更容易”的情况。

随时间提升翻译质量

机器翻译是起点，而非终点。 随着时间推移，通过反馈不断改进翻译。
用户生成的纠正 – 添加一个“小建议更好翻译”链接，让双语用户参与贡献。众包纠正能够自然提升质量。
高流量页面的人工作审 – 首页、定价页和结账流程值得专业翻译。成本适中，且对转化率的影响可量化。
支持工单分析 – 按语言统计工单。如果西班牙语用户频繁就某功能联系支持，说明该功能的翻译文档可能需要改进。
接受翻译质量是一个光谱 – 今天交付 80 % 的翻译总好过六个月后才交付完美版本。那六个月里流失的用户不会再回来。

实际 API 用法

翻译内容 – 使用 Translation API。
检测源语言 – 使用 Language Detection API。

这些服务让你无需从零开始即可触达全球受众。

最初发布于 APIVerve Blog.