國際化諮詢：修正正在中斷的問題，規劃下一步
您已經知道 i18n 很難。我見過這些症狀：會崩壞的 RTL 版面配置、德文溢出按鈕、API 回應使用錯誤語言，以及推出幾週內就失去同步的翻譯。我不賣萬靈丹。我幫您釐清團隊目前面臨的具體問題，並建立不會再以同樣方式中斷的系統。
「我們應該早點規劃這件事」
您正在付出的架構代價
您用英文推出了產品。成功了。然後您「只為了登陸頁面」加了法文。現在您來到這裡是因為：
您的程式碼庫中有分散在 47 個檔案裡的 lang= 檢查
產品經理詢問「我們能 A/B 測試文案嗎？」而工程團隊說「不重寫就不行」
您有三套不同的翻譯工作流程，但沒有一套能穩定運作
我見過中斷的情況：
- 團隊花超過 6 個月把 i18n 硬塞進 Next.js 應用程式，只因為字串是直接寫死在元件裡的
- 翻譯檔案失去同步，因為開發人員不知道該更新哪個檔案
- 每次發布前都有「在地化凍結」期，因為沒有人信任現有的翻譯流程
- 抗拒變更任何已翻譯的內容，因為工作流程太痛苦了
我能協助的項目：
- 讓您能漸進式採用 i18n 的重構策略（我不會要求您「停下所有工作，全部重寫」）
- 讓翻譯保持同步、又不拖慢開發進度的流程設計
- 架構審查，找出您目前的做法在超過 10 種語言時會中斷的環節
i18n 是架構，不是功能。想在後期才加入，就像房子都蓋好了才決定要挖地下室一樣。
我協助您挖掘那個地下室——或判斷您是否真的需要一個。
RTL 毀掉一切
您的 UI 並非為阿拉伯文、希伯來文或烏爾都文而設計
您切換了 dir="rtl"，然後看著整個版面炸開：
我觀察到的：
- 設計系統擁有 200 多個元件，但只有 12 個能正確處理 RTL
- 團隊使用 float: left 而非邏輯屬性，導致每個新功能都出現 RTL 錯誤
- 需要針對元件做 RTL 覆寫的彈出框與模態視窗
- 號稱支援「RTL」的框架，只翻轉了版面方向，卻破壞了定位邏輯
我協助的內容：
- CSS 邏輯屬性遷移（以 margin-inline-start 取代 margin-left）
- 設計系統稽核，在交付前找出 RTL 地雷
- 針對 RTL 優先樣式的框架特定指引（Tailwind、shadcn、MUI）
在每個元件中手動修復 RTL 錯誤是不可持續的。我讓 RTL 支援系統化，而非不斷救急。
「德文文字破壞了我們的按鈕」
不是為翻譯而設計的 UI
英文放得下，德文放不下。您的設計預設了：
然後您翻譯成德文、芬蘭文或泰文，才發現：
按鈕在單字中間被截斷
每一列都要水平捲動的表格
文字換行後變成難以閱讀的區塊
非拉丁文字因為容器具有固定寬度而被截斷
我協助的內容：
- 彈性 UI 模式，可依內容長度靈活調整
- 字元預算規劃（了解德文會擴展 30%，泰文不使用空格）
- 能處理 CJK、阿拉伯文和天城文而不會出錯的排版系統
我幫您建立能在翻譯後存活的 UI——在您為不適用的 10,000 個單字付費之前。
您不需要關於 i18n 為何重要的說教。您需要的是在凌晨 2 點除錯 RTL 彈出視窗、與產品團隊爭論字元預算，並設計出真正能運作的翻譯流程的人
沒有人警告過您的陷阱
來自親身經歷過的團隊的實戰故事
這些不是紙上談兵。這些都是在正式環境中實際出過問題的案例：
複數形式的地獄
英文：「1 item」與「2 items」
波蘭文：「1 przedmiot」/「2 przedmioty」/「5 przedmiotów」（3 種複數形式）
阿拉伯文：6 種複數形式
您的 count === 1 ? 'item' : 'items' 邏輯已經行不通了。
日期／時間混亂
您用 toLocaleDateString() 來格式化日期。結果日本的使用者在您的 CSV 匯出中看到「2025 年 2 月 9 日」，然後 Excel 就出錯了。
API 語言不一致
您的前端請求法文，但您的 API 回傳英文，因為驗證權杖沒有攜帶語言區域設定。現在您的 UI 出現混合語言，使用者還以為是 bug。
偽語言環境測試
您在上線到生產環境之前沒有用 [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] 進行測試。現在您的波蘭文網站根本無法使用。
看不見的假設
您以為字串是唯一需要翻譯的東西。結果碰上了日期、數字、貨幣、排序、搜尋——每一項都有地區特定的行為。
我協助的內容：
- ICU MessageFormat 實作（處理複數、性別、情境）
- API i18n 模式（語言協商、備援策略）
- 能在翻譯機構發現問題之前就攔截到的 QA 流程
工作流程才是困難的部分
當您每天交付時，如何讓 8 種語言保持同步？
您已經搞定了技術，現在卡在流程上：
開發人員合併包含新英文字串的程式碼。翻譯延遲 2 週。使用者看到一半翻譯的 UI
您不知道哪些字串可以安全刪除（它們是否被使用？已翻譯？正在與機構處理中？）
產品團隊想要更新文案。沒有人知道將「Submit」改為「Send」是否會破壞 12 種語言
翻譯檔案與生產環境不同步，一次就是好幾週
團隊詢問我的問題：
我見過的失敗案例：
- 簽入 git 的翻譯檔案與生產字串出現分歧
- 「不要碰西班牙文檔案」的警告，因為沒人知道變更什麼是安全的
- 功能先以英文推出，然後在 6 個月後才翻譯（如果有的話）
我協助的事項：
- 翻譯管線設計（何時用 i18n 函式庫、何時用 TMS、何時用 AI）
- 用於保持來源字串和翻譯同步的 Git 工作流程
- 如果新字串未標記為翻譯，則封鎖 PR 的自動化
技術是可以解決的。工作流程才是阻礙。我設計不需要英雄式維護的工作流程。
我合作過的團隊
全球產品，在地專業
LINE（日本、臺灣、泰國）
橫跨 3 個主要東亞市場的通訊平台。處理 CJK 字元處理、平台生態系整合，以及日本、台灣和泰國之間使用者體驗期望差異等特定挑戰。
KakaoTalk（南韓）
韓國最大的通訊平台。處理韓國市場的特定產品需求，包括 UI 中語言敬語層級的要求，以及平台整合需求。
Change.org（196 個國家，20 多種優先語言）
全球連署平台，內容的速度與品質同等重要。協助規劃跨多元市場，使用者自發產出的政治／社會內容翻譯工作流程。
Airbnb（220 多個國家，60 多種語言）
具有複雜國際化需求的全球市集平台。針對多語言環境下的信任與安全機制，以及跨市場平台概念的文化在地化等挑戰提供諮詢。
Intercom（30 多種語言，全球 B2B SaaS）
服務全球企業客戶的客戶溝通平台。負責即時客服工具的產品國際化，以及知識庫的在地化工作。
Lilith Games（中國、日本、韓國、美國、歐洲）
行動遊戲發行商，旗下遊戲於全球發行。針對特定市場在內容在地化與區域平台需求方面的挑戰，提供有效解決方案。
我曾推出產品的市場：
東亞（日本、韓國、中國）：
CJK 字體排版、平台生態系整合、直排文字支援
東南亞（泰國、越南、印尼）：
多文字系統支援、行動優先的使用者期望
中東及北非（阿拉伯語地區）：
RTL 版面配置需求、正式與口語語言期望、文化內容調整
歐洲：
24 種官方語言，多國產品上線
美洲：
區域語言差異（拉丁美洲西班牙語 vs. 西班牙西班牙語、巴西葡萄牙語），雙語市場
我見證了這些市場中哪些有效、哪些失敗——不是來自理論，而是來自推出真實使用者所依賴的產品
讓我們修復正在出問題的部分
您不需要關於 i18n 為何重要的說教。您需要的是在凌晨 2 點除錯 RTL 彈出視窗、與產品團隊爭論字元預算，並設計出真正能運作的翻譯流程的人
架構與策略審查（1-2 週）：
我會告訴您當您新增下 3 種語言時會出現什麼問題，以及修復需要多少成本
市場推出支援（4–8 週）：
您正準備在日本 /MENA/EU 上線，需要有實戰經驗的專家
持續合作夥伴關係：
當您從 2 種語言擴展到 20 種語言時，提供嵌入式諮詢服務
我不搞理論。我做的是分級處理、路線規劃，以及交付。