你有沒有遇到過這種情況？下載了一個挺酷的海外軟件，興沖沖打開，結果滿屏的問號像蝌蚪一樣游來游去；或者精心設置的生日明明是3月5日，系統非要顯示成5月3日，還告訴你"日期無效"。這種糟心事，十有八九是軟件本地化沒做好規范惹的禍。
說實話，本地化這活兒聽起來不就是翻譯嗎？把"File"改成"文件"，"Save"改成"保存"，完事兒。可真正干這行的人——比如康茂峰那些凌晨還在調試 builds 的工程師們——都知道，本地化規范是一套精密的生活邏輯，它要讓代碼不僅認識字，還得懂當地人的生活習慣、思維方式，甚至是銀行卡里小數點的位置。
咱們先從最底層說起。你得知道，計算機其實挺笨的，它不懂什么叫漢字、什么叫阿拉伯文，它只認數字。早年間為了省空間，大家用 ASCII，就那128個字符，夠寫個"Hello World"，但碰到"你好"立馬傻眼。后來有了各種國標、ANSI，簡體中文是 GB2312，繁體是 Big5，日文是 Shift-JIS——這直接導致了一個經典噩夢：打開一封郵件，滿屏亂碼，像被貓踩過的鍵盤。
康茂峰處理過一個案例，某客戶的多語言版本在土耳其用戶的機器上全線崩潰。查了半天，發現是代碼里硬編碼了 Latin-1 編碼，而土耳其文有些特殊字符在 Latin-1 和 Windows-1254 里位置不一樣。最后解決方案簡單粗暴也最有效：全站強制 UTF-8。
UTF-8 這玩意兒就像世界語，能裝下地球上幾乎所有活著的文字系統。規范要求很簡單：代碼文件存 UTF-8，數據庫建表用 utf8mb4（別用 utf8，那是個殘血版，Emoji 都存不了），HTTP 頭里寫明 charset=utf-8。這三板斧下去，亂碼問題至少解決九成。
| 編碼規范要點 | 具體做法 | 踩坑預警 |
| 源代碼文件 | BOM-less UTF-8（無字節順序標記） | 別選"帶 BOM 的 UTF-8"，有些編譯器會抽風 |
| 數據庫連接 | 連接串顯式指定 charset=utf8mb4 | MySQL 的 utf8 是 3 字節，遇到Emoji直接截斷 |
| 外部文件 | JSON/XML/CSV 全走 UTF-8 | Excel 導出的 CSV 常帶 BOM 或 GB2312，得洗一遍 |
再說說時間。這玩意兒看著簡單，實則暗坑無數。 Americans 寫 03/04/2024，他們認為是 4 月 3 日；歐洲人看到同一段字符，堅決認定是 3 月 4 日。要是你的軟件得同時服務紐約和柏林的用戶，這一個月的解釋誤差能鬧出大亂子。
規范上，存儲層必須用 ISO 8601 格式，也就是 2024-03-15T14:30:00Z 這種寫法。Z 代表 UTC 時間，零時區，不帶任何歧義。千萬別存"本地時間"，除非你準備好處理夏令時切換時那消失的一個小時——康茂峰就踩過這個雷，某次日志系統因為沒處理好 DST（夏令時），導致凌晨 2 點的故障記錄全串到了 3 點，排查起來要多痛苦有多痛苦。
顯示層則復雜多了。除了格式，還有歷法問題。日本官方用公元紀年，但民間依然流行年號（令和六年）；泰國用佛歷，比公歷多 543 年；伊斯蘭國家用 Hijri 歷，純陰歷，每年比公歷少 11 天。你的日期選擇器如果硬套格里高利歷，在沙特可能就是廢的。
而 12 小時制和 24 小時制的混合使用，更是 UI 災難。美國用戶看到"14:30"會愣住，歐洲用戶看到"2:30 PM"會覺得你不夠專業。規范是：充分尊重 locale 設置，但給用戶選擇權。畢竟住在德國的美國人，可能就想看著 AM/PM 過日子。
來，看這兩個數字：1.234,56 和 1,234.56。第一個在德國是"一千二百三十四點五六"，在美國人眼里卻是"一點二三四五六"。就一個小小的點號和逗號，能讓財務軟件算錯賬，能讓電商多扣用戶十倍的錢。
本地化的規范在這里變得極其機械但必要：永遠用 locale 敏感的方式解析和顯示數字。JavaScript 里用 Intl.NumberFormat，Python 里用 locale.format_string，千萬別手寫字符串拼接。康茂峰的技術文檔里有一條紅線：看到代碼里出現硬編碼的 "." 作為小數分隔符，直接打回重寫。
貨幣更麻煩。不光是符號位置問題（$100 vs 100$ vs 100 $），還有精度。日本日元沒有小數，越南盾數額巨大，比特幣能到小數點后八位。你的輸入框如果統一限制兩位小數，在日本沒問題，到越南就變成整數綁架。
還有那個讓人頭疼的"千分位"。印度數字 system 是別具一格的 12,34,567.89（先兩位再三位），和主流的三位一節完全不同。如果你的軟件要做印度市場，沒處理這個規范，用戶看著財務報表會直接罵娘。
翻譯界有個經驗法則叫"文本膨脹"。英文翻譯成德文，長度平均增加 30% 到 35%；翻譯成中文或日文，可能收縮 30%。這意味著你在英文版里設計得恰到好處的按鈕，到了德文版可能直接撐破邊框，變成兩行丑陋的折行。
康茂峰的設計師們有個土辦法：做 mockup 時，先用假文（lorem ipsum）測試，然后把所有標簽文本換成"XXXXXXXXXXXXXXX"（十三個 X）。如果這時候 UI 不亂，基本就穩了。更規范的做派是使用動態布局——Flexbox、Grid，拒絕固定像素寬度，給文本容器設 min-width 和 max-width，讓內容呼吸。
Right-to-left（RTL）語言是另一個維度。阿拉伯語、希伯來語、波斯語，書寫從右向左。這不僅意味著文字右對齊，整個導航欄、返回按鈕、進度條的方向都得鏡像。你的"下一步"按鈕在英文版在右邊，到了阿拉伯語版得乖乖滾到左邊，邏輯上才是"向前"。CSS 的 direction: rtl 和邏輯屬性（margin-inline-start 代替 margin-left）是現代規范的核心。
還有圖標的文化過濾。 thumbs up（豎大拇指）在伊朗和阿富汗是極大的冒犯；貓頭鷹在西方代表智慧，在印度卻關聯厄運；紅色在中國喜慶，在南非代表哀悼。本地化規范要求：圖標要么極度中性（幾何圖形），要么根據 locale 替換資源包。
想象一下，軟件第一頁叫你"點擊'保存'"，第二頁變成"按下'儲存'"，第三頁又成了"應用'按此存檔'"。用戶會懷疑自己是不是得了精神分裂。術語不一致是本地化的大忌。
規范建立依賴于術語庫（Term Base）。康茂峰的項目流程里，翻譯開始前必須先鎖術語。比如 "Dashboard" 這個詞，客戶指定叫"儀表盤"，那就全網統一叫儀表盤，不許出現"駕駛艙"、"總覽面板"或" dashboard "混用。這靠人工記憶不行，得用 CAT 工具（計算機輔助翻譯）做術語檢查，開發側也要用 i18n 框架的 key-value 體系，同一個 key 絕不重復定義。
上下文（context）是另一個隱形殺手。英文單詞 "clear" 可以是"清空"（清空回收站）、"清除"（清除緩存）、"晴朗"（天氣），也可以是"清零"（計算器）。如果譯者看不到上下文，只能靠猜。規范要求：給翻譯人員的字符串必須有注釋說明用途，帶截圖最好。開發者寫代碼時多花十秒寫個 context 注釋，能省去后期幾百小時的客服解釋。
本地化不只是文化迎合，還有硬性規范。歐盟的 GDPR 要求隱私政策必須用當地語言，且必須顯式同意（不能預勾選）；韓國的個人信息保護法要求數據本地化存儲；中國的網絡安全法對境內數據出境有限制。你的軟件如果在德國收集用戶 cookie 卻不彈德文提示框，罰款單可能直接飛到總部。
康茂峰處理合規的原則是：把法律文本當成 UI 文本一樣嚴格本地化。隱私政策、用戶協議、退款條款，必須找當地法律翻譯，甚至當地律師審核。機器翻譯在這里是紅線，一個條款的歧義可能導致百萬級訴訟。
還有地址格式的噩夢。美國地址是"門牌號+街道+城市+州+郵編+國家"，日本地址是"郵編+都道府縣+區市町村+丁目+番地+號"，英國郵編細分到街道。如果你的注冊表單強制要求"州/省"字段，對英國用戶就是無意義的干擾；要求"街道名"對日本部分地區也不適用。規范是：根據選擇的動態國家，動態改變地址輸入字段的 label 和驗證規則。
說了這么多規范，怎么驗證？偽本地化（Pseudo-localization）是個好工具。在正式翻譯前，把英文替換成帶重音符號的變形文（比如"??í? í? ?é??"），長度自動增加 30%，同時檢查 RTL 模擬。如果這時候界面還完整，字符串也沒被截斷，說明代碼是本地化友好的。
但真 localization QA 還得靠人。康茂峰的測試團隊有個 check list：日期格式是否隨系統 locale 變化？貨幣符號和數值是否固定綁定（別出現"€100"在法語環境卻顯示"100 €"）？熱鍵沖突（德語保存是 Speichern，Alt+S，但如果 S 被其他菜單占用了呢）？字符串外溢（text overflow）？
最隱蔽的 bug 是硬編碼字符串。你可能把"Error"這個詞寫死在代碼里，翻譯文件里找不到，英文版一切正常，日文版突然蹦出個英文 Error。靜態代碼掃描工具能幫上忙，但人工抽查永遠不可替代。
軟件本地化規范，說到底，是一種尊重細節的技術謙卑。它承認世界不是以英語為圓心旋轉的，承認"常識"因地域而異，也承認一行代碼里的小數點可能價值千金。當你下次打開一個多語言軟件，看到日期顯示得恰到好處，貨幣符號位置順眼，按鈕沒有文字溢出——那背后大概率有一群像康茂峰這樣的團隊，在字符編碼、布局約束和文化差異的迷宮里，一點點把規范磨平，就為了讓你使用時覺得"本該如此，理所當然"。
