以一個真實字串為例：「連結 Search Console」這個按鈕標籤，是在某個星期二下午上架的，當時我們在網域設定流程中新增了一個上手步驟。這沒什麼特別——一個 `data-i18n` 鍵、一句英文句子，這種變更每週都會發生十幾次。以下依序說明從提交到顯示在畫面上之間，實際發生了什麼事。
提交時的字串
開發人員照常手動撰寫英文鍵值，並在旁邊手動加上中文翻譯——這兩個永遠不是機器生成的，因為它們是團隊中母語人士會實際閱讀並抓出偏差的部分。字串的其他一切則保持原樣不動。法文或韓文的翻譯檔案不會被碰。沒有人需要打開另外十八個 JSON 檔案來保持同步。這正是重點所在：這次提交的範圍，只限於一個人實際撰寫的那兩種語言。
它落入的登記庫
這個鍵值進入一個後端和前端都會讀取的單一真相來源——一個檔案記錄了每種支援語言的代碼、母語名稱、瀏覽器語系前綴以及文字方向。它並不特別知道「連結 Search Console」是什麼；它只知道無論出現什麼新鍵值，都有二十個語言欄位在等著，其中十八個目前還缺少這一項。
接手處理的執行程序
功能上架就是觸發點。沒有人需要開一張工單去「翻譯新的上手步驟」。一個生成程序會針對登記庫執行，將每個目錄與英文原始版本比對差異，並精確填補缺少的字串——這一項也包括在內——同時保持其他檔案中的每一行都不受影響。如果我們等著有人想起來才動手，這個按鈕在一年後的德文介面裡可能還會顯示「Connect Search Console」，跟其他一切德文內容並列在一起。這正是我們建立整套流程要避免的失敗模式：問題不在於翻得不好，而在於因為沒有任何機制強制推動，翻譯根本不會發生。
那個刻意以未完成狀態上線的詞
這裡是讓人意外的地方。這次的上手步驟同時也引入了一個新的網域狀態值，而狀態值來自資料庫，不是來自翻譯人員的待辦佇列——它們是在呈現的最末端進行在地化的，並內建了英文備援機制。所以在程式碼上線到目錄重新生成之間的那幾個小時裡，法文使用者看到的是該狀態的原始英文單字，而不是空白、錯誤訊息或程式錯誤堆疊。這是刻意讓它看起來比正式翻譯差一點，但也刻意比徹底壞掉要好。
我們寧可上線一個誠實的缺口，也不要一次無聲的失敗。
語言切換器
當目錄更新完成後，使用者存取它們的方式完全不變。地球圖示會出現在每個公開頁面的導覽列上——而不是藏在帳號設定裡的一項偏好選項——切換它會就地重新渲染當前頁面。如果有人正在使用那個新的上手步驟時，從英文切換到越南文，按鈕會在游標下即時重新標示，不會重新載入頁面，也不會遺失流程中的所在位置。老實說，這個細節所花的工程時間，比翻譯流程本身還多，因為「不重新載入就重新渲染一切」牽涉到頁面上每一個有狀態的元件，不只是靜態文案。
從未見過登記庫的智慧代理
現在來說最出乎意料的一點：以上這些機制，都不是使用那個上手流程的使用者真正會注意到的部分。他們注意到的，是助理會直接用他們提問時所使用的任何語言來回答——不是因為它讀取了字串登記庫，而是因為它是一個語言模型，會以同樣的語言回應，就像對一個人那樣回應一樣。
- 在設定過程中開啟 AI 助理，用越南語提問——它會用越南語回答。
- 請網站建構器用日語擬定計畫——計畫會以日語回覆。
- 用西班牙語請求 SEO 報告——整份報告從頭到尾都是西班牙語。
介面文字是上述那套二十種語言的機制；智慧代理輸出則是完全不同的機制，達到相同的體驗，正是它讓產品感覺是為你量身打造，而非被翻譯出來的。
