國際化諮詢：修復出問題嘅地方，規劃下一步
你已經知 i18n 好難。我見過呢啲症狀：RTL 佈局崩潰、德文文字溢出按鈕、API 回應用錯語言，仲有翻譯喺推出後幾個星期內就失去同步。我唔賣萬靈丹。我幫你理清你團隊面對嘅特定混亂——同建立唔會再以同樣方式損壞嘅系統。
「我哋應該早啲計劃好」
你而家正承受緊嘅架構代價
你一開始用英文推出。效果唔錯。然後你加咗法文『只用喺登陸頁面』。而家你來到呢度，因為：
你嘅程式碼庫有 lang= 檢查散落喺 47 個檔案入面
產品經理問『我哋可以 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 地雷
- 框架專屬指引（Tailwind、shadcn、MUI），實現 RTL 優先的樣式設計
逐個組件手動修復 RTL 錯誤，根本不可行。我令 RTL 支援變得系統化，而非不斷救火。
「德文文字搞壞咗我哋個掣」
未針對翻譯設計的 UI
英文放得下，德文放不下。你嘅設計假設咗：
然後你翻譯成德文、芬蘭文或泰文，結果發現：
按鈕喺字中間被截斷
每行都有橫向捲動嘅表格
文字換行後變成無法閱讀的區塊
非拉丁文字因為容器設定了固定寬度而被截斷
我可以幫到你的範疇：
- 彈性 UI 模式，可因應內容長度靈活調整
- 字元預算規劃（例如德文會膨脹 30%、泰文不用空格）
- 能夠處理 CJK、阿拉伯文和天城文而不會出問題嘅排版系統
我會幫你整一套捱得住翻譯嘅 UI，唔使等你花咗錢翻譯 10,000 個字先發現根本放唔落。
你不需要人講解 i18n 有多重要。你需要的是一個曾經在凌晨 2 點 debug RTL popovers、跟產品團隊爭論字元預算、又設計過真正行得通的翻譯流程的人。
無人提醒過你嘅陷阱
過來人嘅實戰經驗
這些不是紙上談兵。這些都是在生產環境中出過問題嘅事情：
複數形式的地獄
英文：「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 回傳英文，因為驗證 token 冇帶 locale。結果你嘅介面出現混合語言，用家會以為係 bug。
Pseudo-Locale 測試
你冇用 [Ţĥîś îś ţéśţ ţéẋţ ţĥàţ éẋþàñðś 30%] 測試就直接上正式環境。而家你嘅波蘭文網站根本冇辦法用。
隱形嘅假設
你以為字串是唯一需要翻譯的東西。然後你遇到日期、數字、貨幣、排序、搜尋——所有東西都有因地區而異的行為。
我可以幫到你的範疇：
- ICU MessageFormat 實作（處理複數、性別、語境）
- API i18n 模式（語言協商、後備策略）
- 能在翻譯機構發現問題之前就捕捉到的 QA 流程
工作流程才是最難的部分
每日交付，你點樣保持 8 種語言同步？
你已經搞掂咗技術部分。而家卡喺流程上：
開發人員合併含有新英文字串的程式碼。翻譯滯後兩個星期。用家會見到半翻譯的 UI。
你唔知邊啲字串可以安全刪除（佢哋有喺度用緊嗎？已翻譯？正由翻譯公司處理中？）
產品想更新文案。冇人知道將「Submit」改成「Send」會唔會搞壞 12 種語言。
翻譯檔案與生產環境脫節，一拖就是好幾個星期
團隊問我的問題：
我見過出問題嘅情況：
- 簽入 git 的翻譯檔案與生產環境的字串出現分歧
- 「唔好掂個西班牙文檔案」嘅警告，因為冇人知道改咩先安全
- 功能以英文推出，然後在 6 個月後才翻譯（如果有的話）
我可以幫到你的範疇：
- 翻譯流程設計（何時使用 i18n 函式庫、何時使用 TMS、何時使用 AI）
- Git 工作流程：保持源字串與翻譯同步
- 自動化機制：當新字串未標記為需要翻譯時，自動阻擋 PR
技術問題可以解決。工作流程先係真正嘅障礙。我設計嘅工作流程，唔需要你拼死拼活去維護。
我合作過嘅團隊
全球產品，地區專長
LINE (Japan, Taiwan, Thailand)
通訊平台在 3 個主要東亞市場營運。處理過 CJK 字元處理、平台生態系統整合，以及日本、台灣和泰國之間不同的用家體驗期望等相關挑戰。
KakaoTalk (South Korea)
韓國主流通訊平台。針對韓國市場嘅特定產品需求提供方案，包括 UI 中的語言正式程度要求及平台整合需求。
Change.org (196 countries, 20+ priority languages)
全球請願平台，內容速度與品質同樣重要。協助規劃用家產生嘅政治／社會內容嘅翻譯工作流程，覆蓋多元市場。
Airbnb (220+ countries, 60+ languages)
具有複雜 i18n 要求嘅全球平台。就多語言環境下嘅信任／安全挑戰，以及平台概念喺唔同市場嘅文化適應提供諮詢。
Intercom (30+ languages, global B2B SaaS)
客戶溝通平台，服務全球企業客戶。負責過產品國際化工作，涵蓋即時支援工具及知識庫本地化。
Lilith Games (China, Japan, Korea, US, EU)
手機遊戲發行商，旗下作品於全球發行。針對各市場的內容本地化及地區平台要求等挑戰提供解決方案。
我推出過產品的市場：
東亞（日本、韓國、中國）：
CJK 排版、平台生態系統整合、直排文字支援
東南亞（泰國、越南、印尼）：
多文字系統支援、流動裝置為先的用家期望
MENA（阿拉伯語地區）：
RTL 佈局要求、正式與口語化嘅語言要求、文化內容適應
歐洲：
24 種官方語言，多國產品推出
美洲：
地區語言變體（拉丁美洲西班牙語 vs 西班牙西班牙語、巴西葡萄牙語）、雙語市場
我親眼見過喺呢啲市場入面乜嘢行得通、乜嘢行唔通——唔係靠理論，而係靠交付真實用家依賴嘅產品累積嘅經驗。
一齊修正問題
你不需要人講解 i18n 有多重要。你需要的是一個曾經在凌晨 2 點 debug RTL popovers、跟產品團隊爭論字元預算、又設計過真正行得通的翻譯流程的人。
架構與策略審視（1-2 星期）：
我會告訴你，當你新增下一批 3 種語言時，哪些地方會出問題，同埋修復要幾多錢
市場推出支援（4-8 星期）：
你打算在日本／MENA／EU 推出，需要有經驗的專家
持續合作：
喺你由 2 種語言擴展到 20 種嘅過程中，提供嵌入式顧問服務
我唔講理論。我做嘅係排優先次序、定 roadmap，同埋落地上線。