C 端產品跨國運營踩過的坑 — 介面多語言篇
跨國運營之必要
線上旅行社（OTA）的本質是資訊交換的效率，中文不夠好的日本旅行社該如何把行程賣給想去立山黑部的台灣旅客？
直覺想到的可能是把立山黑部的行程翻譯成中文？仔細再想，這樣真的有解決問題嗎？實際將日文網站透過右鍵翻譯，會發現許多實際令台灣旅客不習慣的地方。
KKday 主要任務是協助台灣旅客找到最適合的立山黑部行程，為了做好這個任務，除了內容翻譯、替日本旅行社把商品資訊翻譯到台灣旅客能理解（如：早、午、晚餐、集合時間、取消政策、行程長度…等）。
這就引出了 OTA 跨國運營的兩大項目：
- 商品內容的多語言
- KKday 平台的多語言
本篇文章將著重在 KKday 平台多語言。
平台多語言
平台多語言指網站與 App 需支持多種語言，以便用戶能以熟悉的語言輕鬆地使用，單純在產品開發多語言並不難，難的是將多語言執行好，而過程中確實包含了許多眉角與妥協。KKday 為此嘗試過不同手段、方法去試圖做到，本文將帶著大家重溫這段過程。
I — 只是產品支援多語言
多語言上線了，有個後台或表單可以輕易地變更介面上字串各語言的文案。然而產品團隊發現，這僅僅是介面換個語言而已，骨子裡還是中文思維，文字生硬不易理解，僅比 Google 右鍵翻譯好一點。
這階段還有很多狀況，譬如標題永遠過長、按鈕文案變兩行、中文句型翻到英文/日文語序不同等…
當產品團隊意識到文字生硬難懂，並開始著手處理時，就正式進到了第二階段。
II — 想要道地而不可得的多語言
這階段，面臨挑戰包含：
- 介面限制文案發揮：標題只能放 13 個字元，越南文、泰文怎麼寫都將超過被切掉或斷成兩行
- 語序差異：「作為第 N 個留下評論的人，你將獲得新台幣 XX 折扣券」，英文語序應是「Get XX SGD coupon by leaving the Nth comment of this product.」，但編譯為了配合中文語序硬凹變成四不像。
解決介面限制文案發揮：介面兼容多語言
面對到標題、按鈕等有長度限制的文案時，KKday 曾試圖限制編譯團隊 output 的字數，但實際上並不可行，為什麼？就…有些語言翻譯後一定會超過 😅（編按：越南文、泰文編譯哀怨地望著先祖）
山不轉路轉，於是產品團隊回去看原本的介面是不是有擴充空間，譬如 Dialog 的標題 Desinger 最初規劃是一行，但實際上看了當地的 App，Dialog 標題都是 2~3 行的設計，就回去跟團隊討論放寬，最終掌握了「多語言介面」的概念，也就是從一開始就依照 2~3 倍中文的文字量去設計介面，放得下才過關，放不下就會在評審環節被注意到，並且調整。
當一個看過 Getyourguide, Trip.com 的 Designer，再看到飛豬設計肯定會認為版位好精巧且運用得出神入化，於是乎採用飛豬介面設計的概念送進評審會議時，直接死在多語言這關。怎麼發現的？這將非常仰賴英文程度較好的團隊成員，或是有經驗的成員來指出問題。
為什麼是在評審環節才發現？沒有 Guideline 嗎？不是沒 Guideline，而是遵守與應用太難想像，KKday 的產品團隊多數位於台北，且團隊成員對外文並不很熟悉，即使做競品研究，也是將競品切換為中文做研究，而中文在表達相同意思時，通常是字數最少的語言，幾種因素疊加起來後，敏銳多語言介面的嗅覺只能靠後天特別訓練。
解決語序差異：參數語意化
不同語言的語言順序不一樣，承上方範例，「作為第 N 個留下評論的人，你將獲得新台幣 XX 折扣券」，在英文是「Get XX SGD coupon by leaving the Nth comment of this product.」，為此，必須允許編譯團隊自由調整參數的順序，不能看到「Get %s SGD coupon by leaving the %s comment of this product.」這種事。
還有參數語意化，如果「Get %s SGD coupon by leaving the %s comment」送到編譯團隊，除了語序，光是要理解這兩個 %s 各自代表什麼都有困難，產品團隊調整為「Get {{amount}} {{currency}} coupon by leaving the {{nth}} comment of this product.」，並且附註上範例「Get 5 SGD coupon by leaving the 4th comment of this product.」幫助理解。
當介面已經符合要求，語序差異也解決後，仍有問題存在。
III — 務實追求道地的多語言
系統限制雖解開，有兩個狀況仍持續發生：
- 介面與文案不匹配：新上線的專案中，按鈕文案用了祈使句、標題文案是 S + V + O 的超完整句型…
- 文案不夠道地：訂單列表被翻成 Order List / Order Record 而非常見的 Order History / Orders
- 中文同義而外文不同：中文「確認」對應到不同情況可能變成 Agree, Accept, Permit, Confirm，而一開始文案是用中文概念去設計，因此所有站上的「確認」都是同個 Key
解決介面與文案不匹配：優化內部流程
經過與編譯團隊的訪談後得知，介面與文案不匹配是來自翻譯需求發起時，沒有附上產品介面截圖幫助編譯團隊理解字串的用途，未能附上產品截圖則是因為太耗費工時，因此 KKday 引入 Lokalise 整合到上傳字串的流程中，確保產品團隊能以合理成本處理文案維運工作，編譯團隊也能獲得充足資訊提升品質。
解決文案不夠道地：大量參照
KKday 留意到語言上的理解與熟悉（aka 道地）是不同的概念，以電商很常見的「訂單列表」，中文會是「訂單管理」、「訂單列表」、「訂單紀錄」，直翻成英文 Order management, Order list, Order record 雖然能理解，但應該是要翻成 Booking history 或 Orders / Bookings 才是道地用法。
如何得知呢？照著英文 / 日文 / 韓文市場最大的競業的用字遣詞做，隨著編譯團隊對於介面多語言的理解加深，就能夠獲得更高品質的文案，接著運用 Glossary（常用字）將這些文案存起來，之後就能持續輸出相同且高品質的文案，而這正是 UX Writing。
解決中文同義而外文不同：Key 命名系統
另外，在迭代時當編譯團隊想改一個「確認」的文案，查了含有「確認」的文案時，會觸發了隱藏事件：所有 Dialog 的「確認」都是用同一個 Key，甚至還有更多不確定的地方也用了同一個 Key。
原因是當初網站是用中文本位設計，中文「確認」能夠應用範圍很廣，開發時為了一致性就用了同一個 Key，沒有考慮其他語言或不同語境下無法一體適用，光是英文再不同情境下就分 Confirm, Agree, Accept, Permit…等，學到這一課後，KKday 就按元件、頁面把 Key 給拆開，也依照這個原則去建立新 Key。
一但 Key 多，透過 API 取所有 Key 的效能一定會變差，此時用元件、頁面命名的 Key，就能允許 RD 一次只取該頁面 / 該元件的字串，提升未來網站效能的天花板。
至於 Key 拆分潛在影響文案的不一致，就透過 Glossary（常用字）來解決。
IV — 仍在前往多語言的路上
這個世界不缺少值得優化的文案，而是缺少發現；KKday 的用戶、Marketing Team 乃至 CTO 在瀏覽介面時，不時會留意到翻譯不夠好的地方，接著編譯團隊就會發起修正。
KKday 以前改個文案要 1~4 週來回對焦，浪費很多時間在溝通上，包含但不限於做一份精美的 Google Slide / Sheet 並附上 Screenshot，還得用紅框圈起不滿意的地方，最後附上原因或期望內容，接著發需求給 RD 進行修改，修改後要 QA，上線後還要回報與驗收，如此冗長的流程曾澆熄了每個想要將文案改好的編譯的熱情。
於是乎，KKday 也透過 Lokalise 整合並做出流程調整：
流程上透過移除 RD 團隊的介入與溝通成本，讓編譯團隊自行迭代，反應速度就從以週計變為以天計了。
不過，KKday 多語言現在仍沒有做好，我們也還在路上。
關於多語言的後記
這趟路程走來跌了不少跟斗，編譯品質、流程效率、實際結果、繼續調整，每個小篇章對應到現實都是 3 個月甚至更長的時間，作業流程牽動著產品、編譯、行銷單位。
對了，如果上面那些沒有嚇退你，我們有在找隊友一起做產品啦：
其他職位（更多 PM、工程師、QA、設計師）也誠徵隊友：https://kkday.bamboohr.com/careers?source=aWQ9MzM%3D
