18ways 部落格

i18n 已損壞：停止編寫翻譯鍵

一種原生於 AI 的方式在 Next.js 中進行國際化 (i18n)，而不會破壞 SEO。

國際化（通常簡稱為 i18n）、本地化（l10n）以及 多語言支持 都描述了相同的概念：調整您的產品，使人們能夠使用他們自己的語言。

i18n 仍然像 2005 年那樣構建

每個企業最終都會意識到他們需要支持多種語言。這時，產品團隊就像一位技師一樣靠在椅子上，吸了一口氣，然後說：“我們在談多少頁面？至少需要四個衝刺。”

對傳統國際化工作成本和努力的機械式反應

我們實現 i18n 的基本方式在 20 年來沒有改變。大多數 i18n 的「最佳實踐」是在現代網絡架構之前形成的，之後的一切都只是建立在這些基礎之上。

I18n 是現代網頁開發中唯一仍然涉及導出文件並將其發送給某人的部分。如果不再通過電子郵件發送，而是通過 API 上傳，則被視為現代化的設置。

在一個 CI 管道和部署以分鐘而非天數計算的世界裡，我們應該感到幸運，因為我們不必傳真任何東西。

為什麼 i18n 感覺不完整

現代網頁開發的進展非常迅速。

我們有：

然而，國際化工作流程仍然讓人感覺屬於不同的時代。

即使是相對較小的應用程序，也會迅速面臨以下挑戰：

開發者並不是一開始就想要建立這樣的系統。他們在不熟悉不同語言如何完全不同地結構句子的情況下，常常會被常見的國際化障礙絆倒……並且不情願地接受20年前設定的現狀。

隨著時間的推移，國際化成為堆疊中最複雜的部分之一。

現代 UI 不適合放在翻譯字串中

考慮一個簡單的用戶介面：

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>

但是，等等，我們的代碼和翻譯文件中現在都有英文文本？是的。不同的 i18n 庫對其進行了不同的處理，但試圖將部分格式化的文本提取到可讀的 JSON 文件中進行翻譯是一場失敗的戰鬥。

現代的用戶界面是結構化的，但翻譯系統是建立在平面字符串的基礎上。

一旦標記、變數和動態內容進入畫面，抽象就開始洩漏。

動態和用戶生成的內容打破了傳統的國際化

當內容不是靜態時，事情變得更加困難。

再舉這個例子：

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

那個字串來自一個API。我們如何將其轉換為翻譯鍵？

劇透：你不需要。現在你的後端也需要支持國際化。

您的後端現在必須管理：

翻譯者突然也需要訪問後端系統。

當用戶生成的內容進入畫面時，問題只會變得更加嚴重。

評論。留言。市場列表。論壇。

傳統的 i18n 流程假設開發者控制所有文本。然而，這種情況越來越不成立。

像亞馬遜這樣的公司在2026年開始嘗試翻譯用戶評論，這一事實充分說明了i18n生態系統發展的緩慢。

語言區域檢測仍然是一團糟

甚至確定用戶想要哪種語言也出乎意料地複雜。

瀏覽器通過 Accept-Language 標頭發送語言偏好：

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

這告訴伺服器：

  1. 偏好英式英語
  2. 然後任何形式的英語
  3. 然後任何形式的法語

在實踐中，正確實施這一點涉及：

許多框架將大部分邏輯留給開發者處理。

即使是基本的區域檢測，通常也會變成自定義應用程式代碼。

語言切換是事後考慮的

翻譯基礎設施只是問題的一半。

用戶仍然需要一種方式來更改語言。

大多數 i18n 庫提供翻譯層，但將問題的其餘部分留給開發者：

這些細節聽起來微不足道，但它們很快就會變成大量的應用程式架構，尤其是如果你對 i18n 的所有細節不熟悉的話。大多數公司和開發者都不熟悉。

快捷方式：自動網站翻譯

鑑於這些複雜性，一些團隊轉向自動網站翻譯工具。這些平台承諾能以最小的努力自動翻譯您的網站。

幾家公司正在構建這個想法的越來越複雜的版本。不幸的是，它們引入了一組不同的問題：

結果通常是一個在技術上支持多種語言的網站，但提供的體驗明顯較差，並且對開發人員來說是一個黑箱。

我們是如何來到這裡的

我們從一件美麗而簡單的事情開始：

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

最後得到了翻譯鍵、JSON 字典、破碎的管道、分離的後端和前端本地化層，以及外部翻譯工具。

現代的網頁應用程式是極其複雜的系統。然而，i18n 工具卻期望使用為不同時代設計的工作流程，就像一輛需要手搖啟動的法拉利。

重新思考模型

如果國際化看起來更像這樣呢？

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安全。

上下文感知翻譯

傳統的 i18n 系統失去了上下文。

翻譯者可能會看到類似的內容：

text
home

但這意味著什麼呢？

在德語中，這些意思需要完全不同的單詞：

如果你必須將「家」翻譯成德語，你更希望看到什麼？一個孤立的字符串，還是它實際出現的頁面？

在翻譯孤立的 JSON 字串與在整個網站上下文中翻譯之間的比較

僅僅查看孤立字串的翻譯系統在這些區別上會遇到困難。

18ways 在實際 UI 的上下文中分析翻譯。

我們的後端代理會檢查翻譯在實際頁面上的顯示，並針對以下進行優化：

對於任何熟悉德語複合名詞的人來說，別擔心，溢出檢測也包含在內。

賦能人類翻譯者

所有幫助人工智慧產生更好翻譯的事物，也同樣幫助人類翻譯者。

18ways 為翻譯者提供與我們的 AI 代理使用的相同上下文感知環境。

翻譯者直接在出現文本的用戶界面上進行審核，而不是編輯 JSON 文件。

這大幅提升了翻譯的準確性和工作流程的效率。

更好的國際化應該是什麼樣子

國際化不需要另一層翻譯鍵、字串檔案和管道粘合劑。

現代應用程序已經具備我們需要的結構、上下文和運行時信息，以便更好地完成這項工作。

下一代的 i18n 應該為伺服器渲染的應用程式、動態內容、AI 原生工作流程以及人類翻譯者並肩工作而構建。

這就是18ways所採取的方向。