多語系平台一次搞定三地格式，介面排版不再亂

講真的，大家做多語言應用程式的時候啊，常常以為難點只是搞定文字翻譯，不過事實比你想得還要頭痛。有沒有？其實真正複雜的是 - 到底要怎麼讓這款App能夠在三種不同語言環境之間都保有那種「我們是本地的」氛圍，同時別因為在手機、平板或其他設備上切換而讓用戶大亂陣腳。嗯，我們在Cogntix嘛……唔，一直被丟來這類表面單純、可細節藏滿小陷阱的專案。真心不騙，上週才遇到一個新例子，我們替比利時市場打造了一套電信App，有些事情是必須針對英文和法文去調校每個細節，否則出包超容易。

如果你也曾挑戰同時支援兩種（以上）語言的平台，那種掙扎絕不是「拿Google 翻譯貼上就沒事了」，說來簡單，但裡面坑特別多。例如說，每次內容排版，結構都要配合不同語系隨機應變 - 像荷蘭語字串動不動比英文長好多，只會影響顯示嗎？錯了，那也牽動所有按鈕大小、行距全跟著大洗牌，有點令人崩潰哪。整件事最靠北的一點，是每步技術決策老得優先考慮顧客使用體驗；你偷懶一下設計馬上卡關，用戶直接問號臉。所以不只是避免出現障礙，其實更多時候是在消耗腦力幫他們挖除那些微妙、不明顯但確實困擾使用者的陷阱。好吧，就是這樣，有做過就懂我意思了…。

開發多語系應用時，唉，法文有點怪啦，就是總覺得它怎麼老愛要額外搞語境，不給你一點線索就很難寫出「那個味道」。然後那個介面的版型又不准隨便亂掉，光是換語言結果按鈕斷行什麼的，馬上爆炸 - 反正工程師心態就是：「給我穩一點！」（欸？）同時，有些動態文字其實也沒那麼簡單，比如複數的抓法、金錢顯示格式什麼，全都要依照使用者所選語種、地區，再加上場景不同進去調。這類各自本色強烈的小細節，看起來像零星議題，可其實還真會拉到整體流程設計裡頭。有時錯誤訊息、一句溫馨提示或者警告字樣，都不能只是直接套翻譯檔案，要講得跟當地人罵髒話或勸朋友一樣自然，才叫不機械。

剛協助一家比利時做電信的新團隊把新App推上線啦，麻煩之處在於，他們堅持法文、英文兩邊必須完全Cover。你可以想見這情況下，用戶期待根本截然不同，只能硬生生盯著維持同一份程式碼，但又要讓大家看了都通順。而為了別每次從設定改語言就斷線重啟，最後決定功能之一得直接偵測裝置首選語系，可是，也保留手動選擇的權利。另外後台嘛，其實編輯那端也方便：管理員可按照地域需要更改顯示內容或限哪些分眾能看到。不說不覺中，又不得不想到另一坑……雖說現在還沒開RTL（像阿拉伯文從右寫到左），但前面UI已經全部寫好能支援RTL - 因為嘛，要等以後大翻修再補這玩意，到時只會哭死自己吧，好累。我知道有人肯定共鳴。

每一次輸出給用戶看的訊息，說實話，其實都藏著無數使用者體驗（UX）背後的糾結與選擇。舉例好了，一行英文像「2 orders」，看來挺直白，可遇上法文，那些複數變化 - 欸，就不是你以為那麼理所當然。為什麼要這麼費工？我們有意識地將自己寫死，把複數邏輯硬生生塞進UI元件裡，就是希望，和任何帶數字的標籤碰面時，都不會掉鏈子，而能順理成章符合各自語言本土習慣。有趣的是，就連那些平凡的通知提示，我們也暗中動了手腳。

通知真的不能只是毫無感情地彈個窗。像同一句「Your recharge was successful」，英語簡單直接，放到法文，不調整句感就超奇怪……雖然原始資訊沒啥不同，可讀起來、甚至按下確認鍵時的心情，就是要針對文化特性作細節處理。不這樣搞，就是在砸自己招牌啦。

還有一個老問題，有些人會把開發方便錯誤當成用戶友善，真的太天真。有時看到團隊因為程式碼省事，犧牲UX - 唔，我們偏不要走那條路。我們把翻譯機制紮紮實實安插在元件最底層，而不是只丟在大路由上帶過去。具體說，例如深巢狀、超隱密的小組件、不常露臉的錯誤態，在這種場景中，只要有需要，它都能做到本地化支援和備案提示；從主操作鈕到小角落提醒，全盤打點周全。不怕煩，就是想保證每一格畫面不留破綻，好啦，有點執著……可是，用戶其實早就在意這種細節，只是他不一定說得清楚而已。

後端設計其實，滿講究用戶的語言偏好欸。主要是這樣啦 - 使用者一登入，他選什麼語系就馬上存起來，接下來API回應的時候，就會根據標頭去判斷，用同個語言丟內容給他。說真的，連異常處理都不是走制式訊息，每次都照著用戶選的語言，把錯誤訊息換掉（就不用一直看不懂的英文啦）。然後日誌嘛，也沒放過，把語言狀態、上下文全記了，所以你如果遇到只在特定語系崩掉的那種鬼問題，其實排查起來超直觀，重點是能對症下藥而且少踩坑。

至於管理端，坦白說，以前那種只靠JSON編輯和人工找Key值...老實講，大部分非技術的人進去看會直接陣亡。不知哪邊有東西要改、有時還會一改到主環境掛掉。這次方案完全不同，不要再拿沒經驗的人抓去摸code或配置檔了，設計就直接整合了一套「即時內容管理」的小工具到後台畫面。

有意思的是，它加了一個CSV匯入的流程，你手上一份檔案，只要資料欄填好，各國各語都可以一起匯批更新，要幾百筆也沒在怕。最扯的是，它自動對欄位、維護結構，一頁之內每個語系區塊清清楚楚，不用傻傻跳分頁（爽度有差吧）。不只如此，每格小內容獨立設定顯示國別、優先規則想怎麼疊加override都行，有些場景甚至乾脆隱藏，用起來彈性又免寫死流程。

哦、全部這堆功能底層還是建在Spring Boot那一套，就是API本身天生支援地域和多國多語切換。一方面這樣保證營運效率，可控性也牢牢抓住，不再為改條文、多加地區版本焦頭爛額。

這代表說，一個端點，其實可以依據使用者設定來變動，也能根據IP自動選擇備用，讓相同的資源資料有多種語言版本出現。不過唉，雖然東西會經過智能快取處理，但效能竟然幾乎沒差異，說起來還蠻神奇。

其實，多數人做多語應用程式時，很容易忽略一些看似微不足道的小細節。講白了，大家往往以為只要翻譯標籤或替換語言檔案就搞定，結果其實這樣只能算最初階那一層。有很多棘手的麻煩，都躲在你沒察覺的地方。嗯…如果這些藏在角落的小問題被忽略了，就可能害使用者對服務不信任，又或者會帶來明顯的不便。

說到這裡，大部分「在地化」的失敗都常發生於以下狀況：警示提示、錯誤訊息跟系統回饋。

介面那些文字也許表面上很好翻，可是剛剛講的那些反饋內容，真的超常被遺漏掉。你大概也曾遇過：某次切換語言後，有些突兀又生硬的英文錯誤訊息突然冒出來，看了心頭一緊；或者整個介面都中文，可一旦出錯畫面卻全亂七八糟，都沒有想像中順暢可讀…。哎，好吧，不注意這塊真的是隨時踩雷欸。

有時候，應用程式出現錯誤後，接下來的翻譯作業只會更加混亂。一整串看不懂的英文訊息還夾在那裡，令人摸不著頭緒。唉，大部分這些錯誤警告，其實都是死板寫死在後端服務或什麼第三方 SDK 裡邊。所以即使整個 UI 已經完美法文化，只要 API 卡住沒回來，用戶就還是會硬生生見到諸如 "Invalid input provided." 這種直接噴出的英文內容 - 真心覺得不親切。

嗯……Cogntix 處理這塊其實滿講究。我們採的是一種集中式處理辦法：把所有系統層級的錯誤通通映射成前端自己地區語言的提示；然後在 Spring Boot 框架中加入有在意本地語言環境的例外攔截器，就是說，在訊息傳到客戶端之前，有機會讓它先換上一身正確語言外衣。話說伺服器丟出那些驗證失敗相關資訊，也一律都做本地化，免得用戶面對某種技術黑話。聽起來折騰，但其實真的比較人性。

順帶一提，格式細節也別小看哪。比如 "Monday" 跟 "Lundi"，光是詞差異已經明顯，更別談兩字背後牽動的文化習慣與心理預期。如果介面上的時間、日期甚至數字排列弄錯地方風格，很容易整體感覺怪怪、不太舒服。例如，比利時講法文那邊常看到 DD/MM/YYYY 的日期格式，要是哪天冷不防跳出美式 MM/DD/YYYY，那多半一下子就叫大家迷路。而且歐洲不少國家規定禮拜一才算是一週開頭，不像北美習慣禮拜天先行。老實說，用戶很快就能察覺箇中落差，有點雞毛蒜皮，但堆積久了，其實挺惱人吧。

你有沒有注意過，一樣都是數字、一樣的金額，結果在歐洲、亞洲那種「1 000,00 €」看起來就是哪裡怪怪的？其實光是一個小空格、小逗號，就可能讓人瞬間卡殼。不開玩笑，標點真的會左右資訊到底順不順眼。Cogntix - 說到他們，欸，也是直接採用「Intl.DateTimeFormat」和「Intl.NumberFormat」這兩個API啦。說得複雜一點，就是根據你當下選的語言或地區，前端自動幫你把日期跟數字格式搞定，後端只送出單純的時間戳而已。這招厲害的是，不論你是在小工具元件也好，還是訊息跳出來警告你的時候，那些日期、錢幣甚至百分比，全都乖乖照你的地區邏輯呈現。

話說回來，其實全球化產品最麻煩的往往不是螢幕上秀什麼，而是「怎麼輸入」。像郵遞區號喔，加拿大人硬要混英文加數字湊六位；法國就懶得變通，就純五個阿拉伯數字到底。明明只是一個小欄位欸，每個地方偏要自己的一套。這代表啥？老實說，只能想辦法針對各國、自動去調整輸入驗證規則，要確保使用者資料別弄錯，也多少可以讓用戶感覺舒服點吧（笑）。

在德語圈、或者像荷蘭這樣的地方，說真的，人名排序其實跟中文完全不一樣，一般來講姓氏都會跑到最後面，可偏偏使用的人又很可能一開始直接先打上自己的姓。嗯，這常搞得系統設計師也頭大。如果你沒處理好，齁 - 連賬單那個細節都能踩雷。

另外，還有一種很微妙的狀況：區域習慣上千分位跟小數點到底要點還是要逗號？有人硬生生就把1.000,00 當成 1,000.00，那萬一解析順序錯了，不小心真的給亂入了金額，你帳戶明細看到會吐槽「到底…」算了。所以啦，每個地區對於這類標示的需求其實差距比你想像更大（尤其財務相關欸），只是日常大家不太意識到而已。

Cogntix 他們的方法，有意思的是 - 他們不是只改UI美觀，他們是依據各國實際運作情境去重新設定每項表單輸入規則；接下來會根據用戶所處區域，在伺服器端再做一次輸入資料驗證，以此來預防轉換誤判。一想到每條路徑都需驗證，而且不能出現死板機械訊息，那壓力也挺大的。不只如此，他們甚至去弄了一套可以客製化格式的小工具，不僅讓表單看起來更本地化，更重要的是使用者在輸入互動時，本身方式就被調整到合適地區模式，而非僅流於表面。

坦白講，大部分軟體其實直接無視那些小落差。但 Cogntix 不是敷衍，它深知用戶確實覺得這才是關鍵落差，一但經歷過才知道哪裡痛（還真懶得多解釋）。所以他們堅持照著做，把所有觸角從顯示拉回用戶行為本身。好吧，就這麼回事。

信任有時候，就是這麼容易一個縫就鬆掉了欸。舉例說，假如法語使用者碰見的是英文警示，心頭多少會有點不是滋味；或者填個郵遞區號，被提醒「格式錯誤」，忍不住冒火…這些看似小事啊，其實才真的磨損人對產品的感受。唉，這年頭，體驗沒做好，用戶走得比誰都快。所以咱們後來又調整了流程，好讓東西更貼近各種語言背景吧。

## 正確的測試方式

光是把介面翻譯一遍哪夠？其實，我們在測試時是直接從流程切下去，不停換多國語系和場景交叉檢查。例如 - 如果支付步驟跳出用德文或俄文錯誤資訊，結果還能完整接上原本選擇的語系嗎？又或者，從搜尋頁一路進結帳，用戶會不會無緣無故被強制換成別的語言？偶爾突然腦袋想歪點：未來要是在荷蘭語和阿拉伯文間切換呢？介面裡已經支援RTL顯示的那些元件，到底扛不扛得住轉折變化…老實說，有時連團隊自己也開始懷疑細節到底做夠沒。QA夥伴只能拚命在真機跑測試，各種網路慢斷、系統亂碼、預料之外的小故障全丟進去狠操一頓，每一層設定反覆繞回來捏幾次。

## 最終交付成果

到最後應用程式正式上線那刻，「多語」已經只是基礎盤而已。我們拿得出去說嘴的是，三套獨立又扎實、本地感很強的體驗流程。你要說每位用戶嗎，他總算可以舒舒服服地依據自己的偏好，大方瀏覽想看的內容，不必再卡在奇怪界面兜圈子。此外管理端不用再寄望工程師神救援，一旦流程設計好，只靠自家掌控就能維護跟操作完整的後台管理權限。嗯哼 - 如果你問我，我覺得少掉求助環節那叫暢快。

現在市場上，談到多語言平台的建置，說起來簡單，做下去常常讓人想敲頭。每當公司碰到電信、金融科技、電子商務等不同產業的國際擴展時，很難只靠翻譯兩個字交差 - 真的沒這麼容易啊。不僅每一位用戶講話方式怪異，各地背景也千奇百怪，就算把介面換成本地語言，不代表大家會覺得「嗯，自己人」。

Cogntix倒是真的摸出了一套可以彈性調整規模的多語言技術 - 講白點，他們管理端能隨機應變調整動態內容，再從後台一路串聯到跨區客戶在前端實際操作。這流程像魔術一樣安靜地進行，用戶往往根本感覺不出有什麼障礙。欸，有意思的是，如果你正構思下一款服務，對於如何呈現自然且帶點地方口音、文化細節以及如何徹底支援各種語言困擾得滿頭霧水，其實也別太自責。

Cogntix其實很願意和你一起討論那種「一打開就懂」的平台設計要怎麼落實。我自己偶爾也想，如果產品真能讓第一次打開的人馬上心領神會，到底工程背後得花多少力氣與細節堆疊。

作者是Gayathri Priya Krishnaram，目前負責Cogntix的數位內容編輯（公司名稱千萬別漏掉了）。