七種語言：為什麼在地化是一項可靠性功能

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%。

設定完成率的收斂是我們最關心的指標。它驗證了在地化正在彌合可靠性差距，而不僅僅是新增翻譯後的標籤。

下一步計畫

我們正在基於相同的標準擴展語言支援：使用者需求加上能聯繫到母語技術審閱者。

• 我們正在根據使用者需求和母語技術審閱者的可用性評估更多語言。
• 我們正在建構翻譯的社群貢獻工作流程，透過審核流程確保合併前的技術準確性。

關於語言偵測和退回機制的詳情，請參閱在地化架構。如果你想為尚未支援的語言貢獻翻譯，請透過支援頁面聯繫我們。