最近蠻常被問到一個問題：「我們的 App 想做多國語言版本，是不是把所有文字都丟去翻譯，然後做個語系切換按鈕就好了？」
嗯... 每次聽到這個，我都很想直接說，如果真的這麼簡單，那市面上就不會有一堆明明切換到中文，卻還是滿天飛英文錯誤訊息、或是日期格式亂七八糟的 App 了。
說真的，這件事的複雜度，大概是最多人低估的產品開發挑戰之一。不只是翻譯文字，而是要打造一個 App，讓它在三種不同語言、不同文化背景下，跑在各種裝置上，都讓人覺得「嗯，這東西很在地、很順手」。
重點一句話
真正的魔鬼，全部藏在那些你看不到、但使用者肯定會「感覺到」的小細節裡。它不是翻譯問題，是使用者體驗 (UX) 的問題。
你以為的「翻譯」，跟使用者要的「在地化」差遠了
很多人會以為，多國語言嘛，就是在專案裡多開幾個語系資料夾（例如 `en.json`, `fr.json`），然後把 key-value 填一填就收工了。這...這真的只是冰山一角，而且是最小的那一角。
真正的問題，都發生在你以為搞定了之後。這些小地方如果沒處理好，使用者對你 App 的信任感就會一點一滴地流失。
狀況一：系統噴出來的錯誤訊息，直接讓使用者「出戲」
這是最最最常見的狀況。你 App 的介面按鈕、標題，可能都翻譯得很完美。結果使用者網路一斷線、或是不小心送出一個錯誤的資料，API 噴回來的錯誤訊息直接就是一行英文："Invalid input provided."
瞬間，那個好不容易建立起來的「在地感」就全毀了。使用者只會覺得：「蛤？這 App 到底行不行啊？是沒做完嗎？」
說真的，這也不能全怪前端。因為很多錯誤訊息是後端服務、甚至是第三方 SDK 直接寫死的。所以要解決這個，得從架構層面去想，比如建立一個錯誤碼對照表，讓後端只回傳錯誤「代碼」，前端再根據使用者的語系，去顯示對應的在地化訊息。
狀況二：日期、數字和貨幣格式的「文化衝擊」
這個小細節，殺傷力超強，但超容易被忽略。
你知道嗎，在法國，「04/05/2024」是指 5 月 4 號，但在美國，這會被看成 4 月 5 號。如果你的 App 是個訂票系統，這下問題就大了。
還有啊，歐洲很多地方的週一是每週的第一天，但北美習慣把週日當第一天。你的行事曆元件如果沒處理好，使用者訂會議或排程就會整個錯亂。
數字也是。一千塊錢，在台灣我們可能寫「1,000 元」，但在德國可能會看到「1.000,00 €」。那個逗號跟小數點是反過來的。如果你的輸入框沒有處理好，使用者想輸入一千塊，結果系統解析成一塊錢，那真的會引發客訴。
這點跟我們在台灣的習慣很不一樣，台灣雖然也用西元年，但在一些比較正式的政府或銀行文件上，偶爾還是會看到「民國年」的蹤跡，這又是另一層複雜度了。反過來說，美國聯邦政府的官方文件，根據他們的樣式指南 U.S. Government Publishing Office Style Manual，日期格式就是 `Month Day, Year`（例如 June 5, 2024），非常明確，這跟歐洲習慣的 DD/MM/YYYY 完全不同。這就顯示了「在地化」真的不只是換個語言而已。
狀況三：輸入框期待的跟你想的不一樣
不只是顯示，使用者「輸入」的內容也跟語系和地區有關。
- 郵遞區號：加拿大的郵遞區號是「字母數字字母 數字字母數字」的組合，但美國是 5 位數字。你的驗證規則如果寫死，那加拿大使用者就永遠無法通過驗證。
- 姓名順序：在德語區，雖然官方文件上姓氏在後，但很多人日常習慣會先把姓氏說出來。如果你的表單只有「Name」一個欄位，你收到的資料可能會亂七八糟。
這些問題，單獨看都只是小事。但它們會一直冒出來，像小石頭一樣，不斷絆倒你的使用者，讓他們覺得你的 App「水土不服」、很難用。
好啦，那到底該怎麼做才對？
要做好，就不能只靠前端工程師一個人埋頭苦幹。這需要前端、後端，甚至是內容管理團隊一起配合。我自己是覺得，可以從兩個大方向去思考：一個是技術架構，另一個是管理流程。
下面這個表格，可以很清楚地看出「只做翻譯」和「真正做在地化」的思維差異。
| 處理項目 | A. 只求有翻譯就好 (然後祈禱不要出事) | B. 追求真正的在地化體驗 (一開始就做對) |
|---|---|---|
| UI 文字 | 丟個翻譯檔，前端元件直接讀取。管他句子長度爆版，反正有字就好。 | 設計階段就要考慮彈性佈局，德文的字串通常比英文長很多，版面不能因此跑掉。 |
| 複數/單數 | 全部用 `(s)` 處理，例如 `2 item(s)`。超醜，而且很多語言根本不適用。 | 針對不同語言寫好 pluralization 規則。例如法文的複數規則跟數字有關，這得用程式邏輯處理才行。 |
| 日期/數字 | 後端直接給 `2024-05-04` 這種格式字串，前端直接顯示。管他使用者是哪國人。 | 後端統一給 ISO 8601 時間戳，前端用 Intl.DateTimeFormat 和 Intl.NumberFormat 這些 API，根據使用者語系動態產生格式。 |
| 錯誤訊息 | 反正很少出現，直接用英文硬코딩吧，省事。 | 連錯誤訊息都要是當地語言，而且要講人話，不能是「錯誤碼 502」，要像是「抱歉，伺服器有點忙，請稍後再試」。 |
| 內容管理 | 叫行銷或內容同學去改 JSON 檔... 他們改壞了算他們的。 | 打造一個非技術人員也看得懂的後台！可以直接在同一個畫面並排輸入不同語言的內容，甚至用 CSV 批次上傳。 |
後端要夠聰明，才能讓管理變簡單
我真的看過太多悲劇了。公司的行銷團隊為了改一個活動頁的文案，要拜託工程師去程式碼裡面撈那個字串 key，然後在一大堆 JSON 檔案裡大海撈針，改完還要擔心會不會不小心多一個逗號就讓整個 App 崩潰。
這完全是把非技術人員推入火坑。
一個好的多國語言後台，應該要做到：
- 直觀的編輯介面：不要再看程式碼或 JSON 了。應該是像填表格一樣，一個欄位對應一個語言，一目了然。
- 批次處理能力：例如，支援 CSV 檔案匯入。營運團隊只要填好一個 Excel 表，按個上傳，幾百條文案就能在幾秒內更新完畢，而且不會動到系統結構。
- 語系跟地區的權限控制：可以設定某個內容只在特定語區顯示，或是在某個國家優先顯示特定版本。
後端 API 本身也要有「語系意識」。理想上，同一個 API endpoint，可以根據使用者請求的 header (像是 `Accept-Language`)，自動回傳對應語言的資料。這樣前端就不用做一堆複雜的判斷，程式碼會乾淨很多。
現在省下的小錢，未來會變成巨大的技術債
有時候老闆或 PM 會問：「我們現在又沒有阿拉伯語或希伯來語的市場，有必要現在就為了 RTL (由右至左書寫) 語言去調整架構嗎？聽起來好麻煩。」
這就是典型的短視近利。麻煩的不是「現在多做一點」，而是「未來要全部重做」。
如果你的 App 一開始就沒有考慮到 RTL 佈局，那代表你所有的排版、元件、CSS 可能都是基於「由左到右」寫死的。未來某天，當市場需要拓展到中東時，你會發現，你不是只要加一個語言檔而已，你是要回頭去修改整個 App 的骨架。那個成本... 絕對比一開始就用 `flexbox` 的 `start` 和 `end` 屬性，而不是寫死的 `left` 和 `right` 要高出幾十倍。
這就像蓋房子。一開始就預留好所有管線的位置，遠比等裝潢好了才來敲牆壁要省錢省事得多。
常見錯誤與修正
整理一下，如果你正在或準備要打造多國語言 App，千萬避開這幾個坑：
- 錯誤：只在前端做語系切換，API 回來的資料還是單一語言。
修正：後端 API 必須也要能根據使用者語系，回傳對應的在地化資料。使用者登入時就把語系偏好存起來，後續 API request 都帶上這個資訊。 - 錯誤：用字串拼接來處理單複數或變數。例如 `"你有 " + num + " 個新訊息"`。
修正：使用支援變數和複數規則的 i18n 函式庫。它能處理不同語言的語法順序和複數形式，例如法文的 `Vous avez 1 nouveau message` vs `Vous avez 2 nouveaux messages`。 - 錯誤：把測試工作只當成「翻譯校對」。
修正：測試的重點是「完整的使用流程」。測試人員要模擬真實使用者，在不同語言設定下，從頭到尾走一遍核心功能（例如註冊、購物、聯絡客服），確保過程中沒有任何環節的語系或格式「跳掉」。
說到底，做多國語言 App，技術只是工具，核心思想其實是對使用者的「尊重」。你願不願意多花一點心思，讓來自不同文化背景的人，都覺得你的產品是為他們而設計的。
我自己是覺得，當使用者在一個小小的日期格式或是一句貼心的錯誤提示上，感受到你的用心時，那種信任感的建立，是再多行銷預算都買不到的。
在你用過的 App 中，有遇過哪種最讓你「出戲」的爛翻譯或格式錯誤嗎？歡迎在下面留言分享你的經歷！
