18ways 博客

i18n 已损坏：停止编写翻译键

一种在 Next.js 中进行国际化的 AI 原生方式，不会破坏 SEO。

国际化（通常缩写为 i18n）、本地化（l10n）和 多语言支持 都描述了同一个概念：调整您的产品，使人们能够使用自己的语言。

i18n 仍然像 2005 年那样构建

每个企业最终都会意识到他们需要支持多种语言。此时，产品团队像个机械师一样靠在椅子上，吸了一口气，说：“我们在谈多少页面？至少要四个冲刺。”

对传统国际化工作成本和努力的机械式反应

我们实现国际化（i18n）的基本方式在过去20年中没有改变。大多数国际化的“最佳实践”是在现代网络架构出现之前形成的，之后的一切都只是建立在这些基础之上。

国际化是现代网页开发中唯一仍然涉及导出文件并将其发送给他人的部分。如果你通过API上传文件而不是通过电子邮件发送，那么这被认为是现代的设置。

在一个CI管道和部署以分钟而非天数来衡量的世界里，我们应该感到幸运，因为我们不需要传真任何东西。

为什么国际化感觉不顺畅

现代网页开发发展得非常迅速。

我们有：

然而，国际化工作流程仍然感觉像是属于一个不同的时代。

即使是相对较小的应用程序也很快会面临以下挑战：

开发者并不是为了构建这样的系统而开始的。他们在不熟悉不同语言如何完全不同地构造句子时，常常会被常见的国际化障碍绊倒……并且勉强接受20年前设定的现状。

随着时间的推移，国际化成为技术栈中最复杂的部分之一。

现代用户界面不适合放在翻译字符串中

考虑一个简单的用户界面：

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

这很容易理解。它很简单。

在某个时刻，我们决定将其国际化。因此，我们将文本提取到一个翻译文件中：

json
{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

我们在代码中引用了这一点：

jsx
<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

但是，等等，我们的代码和翻译文件中都有英文文本？是的。不同的国际化库对其进行了不同的处理，但试图通过将部分格式化的文本提取到一个人类可读的 JSON 文件中进行翻译是一场注定失败的战斗。

现代用户界面是结构化的，但翻译系统是建立在平面字符串的基础上的。

一旦标记、变量和动态内容进入视野，抽象就开始泄漏。

动态和用户生成的内容打破了传统的国际化（i18n）

当内容不是静态时，事情变得更加困难。

再举这个例子:

jsx
<b>{serverResponse.productDescription}</b>

该字符串来自一个API。我们如何将其转换为翻译键？

剧透：你并不需要。现在你的后端也需要支持国际化。

您的后端现在必须管理：

翻译人员突然也需要访问后台系统。

当用户生成的内容进入视野时，问题只会愈加严重。

评论。意见。市场列表。论坛。

传统的国际化（i18n）流程假设开发者控制所有文本。但这种情况越来越不成立。

像亚马逊这样的公司在2026年开始尝试翻译用户评论，这一事实充分说明了国际化生态系统的发展是多么缓慢。

区域设置检测仍然很混乱

甚至确定用户想要哪种语言也出乎意料地复杂。

浏览器通过 Accept-Language 头发送语言偏好：

text
Accept-Language: en-GB,en;q=0.9,fr;q=0.8

这告诉服务器：

  1. 偏好英式英语
  2. 那么任何形式的英语
  3. 然后任何形式的法语

在实践中，正确实施这一点涉及：

许多框架将大部分逻辑留给开发者。

即使是基本的区域设置检测，通常也会变成自定义应用程序代码。

语言切换是事后考虑的事情

翻译基础设施仅仅是问题的一半。

用户仍然需要一种更改语言的方法。

大多数国际化库提供翻译层，但将问题的其余部分留给开发者：

这些细节听起来微不足道，但它们很快就会变成大量的应用程序基础设施，尤其是如果你对国际化的所有复杂性不熟悉的话。大多数公司和开发者并不熟悉。

快捷方式：自动网站翻译

鉴于所有这些复杂性，一些团队转向自动网站翻译工具。这些平台承诺以最小的努力自动翻译您的网站。

几家公司正在构建这一理念的越来越复杂的版本。不幸的是，它们引入了一系列不同的问题：

结果往往是一个在技术上支持多种语言的网站，但提供的体验明显较差，并且对开发者来说是一个黑箱。

我们是如何来到这里的

我们从一些美丽而简单的东西开始：

jsx
<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

最终得到了翻译键、JSON 字典、破碎的管道、分离的后端和前端本地化层，以及外部翻译工具。

现代网络应用程序是极其复杂的系统。然而，国际化工具却期望采用为不同年代设计的工作流程，就像一辆需要手摇启动的法拉利。

重新思考模型

如果国际化看起来更像这样呢？

jsx
<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

没有翻译键。

没有 JSON 字典。

没有手动管道。

仅仅是文本。

一种不同的方法

这个想法是18ways背后的基础。

18ways 将翻译视为一种优化的运行时问题。提取翻译键和管理翻译文件是机器而非人类的问题。

开发者只需标记他们想要翻译的文本。

幕后，18ways:

一切仍然保持SSR友好和SEO安全。

上下文感知翻译

传统的国际化系统失去了上下文。

翻译者可能会看到类似于：

text
home

但这是什么意思？

在德语中，这些意思需要完全不同的词：

如果你需要将“home”翻译成德语，你更希望看到什么？一个孤立的字符串，还是它实际出现的页面？

在翻译孤立的 JSON 字符串与在完整网站上下文中翻译之间的比较

仅仅看到孤立字符串的翻译系统在这些区别上会遇到困难。

18ways 在实际用户界面的上下文中分析翻译。

我们的后台代理会审查翻译在真实页面上的呈现，并进行优化以：

对于任何熟悉德语复合名词的人来说，不用担心，溢出检测也包含在内。

赋能人类翻译者

一切有助于人工智能产生更好翻译的东西，也有助于人类翻译者。

18ways 为翻译人员提供与我们的 AI 代理使用的相同上下文感知环境。

翻译人员直接在出现文本的用户界面上进行审查，而不是编辑 JSON 文件。

这大大提高了翻译的准确性和工作流程的效率。

更好的国际化是什么样的

国际化不需要另一层翻译键、字符串文件和管道粘合剂。

现代应用程序已经具备我们需要的结构、上下文和运行时信息，以便更好地完成这一任务。

下一代国际化应为服务器渲染的应用程序、动态内容、人工智能原生工作流程以及人类翻译者并肩工作而构建。

这就是18ways所采取的方向。