如果你正在做軟件本地化工作，相信我，單位轉(zhuǎn)換絕對是你會遇到的最"磨人"但又最重要的小細(xì)節(jié)之一。說它小，是因為在龐大的本地化項目里，它可能只占很小一部分工作量；但說它重要，是因為一旦出錯，用戶看到的東西就會特別別扭——明明是個溫度顯示，愣是給人看出個"100度"的冷汗來。
我有個朋友之前跟我吐槽，說他翻譯一個天氣類應(yīng)用時，把華氏度直接當(dāng)成攝氏度翻譯了。結(jié)果美國用戶看到"北京氣溫零下18度"的時候，整個人都傻了。這還只是顯示問題，更麻煩的是涉及到尺寸、重量、容量這些和實際生活息息相關(guān)的單位，一旦弄錯，用戶體驗直接崩塌。
今天就想聊聊，在軟件本地化這個大工程里，度量衡單位轉(zhuǎn)換到底應(yīng)該怎么處理，哪些坑要繞著走，哪些方法能讓你少掉點(diǎn)頭發(fā)。
你可能會想，單位轉(zhuǎn)換不就是乘以幾除以幾的事嗎？直接寫個公式讓程序處理不就行了？話是這么說，但真干起來的時候，你會發(fā)現(xiàn)事情遠(yuǎn)比想象中復(fù)雜。
首先，不同國家和地區(qū)用的單位系統(tǒng)就不一樣。歐美那邊，英制和公制都在用，有時候同一個國家里不同場景用的單位都不一樣。美國人日常說身高用英尺英寸，買菜用磅，跑步用英里，但開車?yán)锍逃钟糜⒗锛觼鲞@種組合。英國更離譜，公路上用英制，超市里卻開始慢慢改成公制了。這要是沒搞清楚，分分鐘給用戶整不會。
其次，單位轉(zhuǎn)換不是簡單的數(shù)學(xué)問題，還涉及到文化習(xí)慣。日本人買電器會說"18帖"來表示房間大小，這個"帖"翻譯成"平方米"雖然數(shù)學(xué)上對，但日本用戶看了就是覺得怪。德國人買東西會說"500毫升"，但說身高的時候又回到"1米85"了。這種習(xí)慣上的差異，不是簡單換個數(shù)就能解決的。
再說了，軟件里的單位呈現(xiàn)方式也各有不同。有些地方是純數(shù)字加單位，有些地方是帶符號的縮寫，還有些地方習(xí)慣用完整的單詞。日期時間格式有時候也會和單位摻和在一起，比如"2024年5月15日"和"05/15/2024"這種差異，也會影響到你的本地化策略。
在軟件本地化里，最常遇到的需要轉(zhuǎn)換的單位大概可以分成這么幾類，每一類都有自己的小脾氣。
溫度大概是最讓人頭疼的單位之一了。原因很簡單，這兩個溫標(biāo)之間的換算不是整數(shù)倍關(guān)系，公式是"(華氏度-32)×5/9"，翻譯的時候根本沒法用簡單的乘除法來處理。
更重要的是，用戶對不同溫度的感知是完全建立在本地習(xí)慣上的。一個習(xí)慣了攝氏度的人，看到"86度"第一反應(yīng)肯定是"熱死了"，而不是換算成"30攝氏度剛剛好"。反過來，習(xí)慣了華氏度的人看到"零下10度"也會一臉茫然。所以最好的處理方式不是讓用戶自己換算，而是在源頭上就把溫度轉(zhuǎn)換成用戶習(xí)慣的溫標(biāo)顯示出來。
長度單位的問題在于同一個數(shù)值在不同單位下感覺完全不一樣。1.8米的身高聽起來挺高，5.9英尺好像也還行，但如果你告訴一個美國人某樣?xùn)|西長2英寸，他腦海里浮現(xiàn)的可能是橡皮擦那么大，而告訴一個中國人"5厘米"，他想到的可能是手機(jī)寬度。
這里還要注意一些"文化陷阱"。比如中國傳統(tǒng)里的"里"其實不等于公里，古代的"尺"和現(xiàn)在的米也沒關(guān)系。日本的"寸"和英寸也不一樣。如果你的軟件涉及歷史內(nèi)容或者傳統(tǒng)文化，翻譯的時候可就得好好查查資料了，別鬧出"唐朝一尺等于現(xiàn)代三米"這種笑話。
重量和容量的麻煩在于單位換算的不直觀。1公斤等于2.2磅，這種換算關(guān)系用戶很難自己完成。盎司更離譜，它同時是重量單位也是容量單位，1盎司重約28克，1液體盎司約30毫升——對，重量和容量的盎司還不是一回事！
容量單位在英制系統(tǒng)里更是復(fù)雜。英制品脫等于20液盎司，美制品脫卻只有16液盎司。你要是在一個健身APP里把蛋白粉用量從"2勺"翻譯成具體的毫升數(shù)，可得先搞清楚用戶是英國人還是美國人，不然人家按你的說明加水，一沖出來可能稠得像漿糊。
房地產(chǎn)類軟件特別容易在這個上面栽跟頭。中國人習(xí)慣說"100平方米的房子"，美國中介卻常說"1000平方英尺的公寓"。這兩個數(shù)值換算一下，大約是93平方米對107平方米，看起來差距不大，但用戶要是拿這個做購房決策，誤差可就大了去了。
更隱蔽的問題是，有些單位在不同場景下表達(dá)習(xí)慣完全不同。土地面積用公頃和英畝，房間面積用平方米和平方英尺，屏幕尺寸用英寸但又說的是對角線長度。翻譯的時候不僅要換算正確，還得搞清楚在什么場景下用什么單位最自然。
說了這么多困難，總得聊聊解決辦法。根據(jù)我這些年的經(jīng)驗，處理單位轉(zhuǎn)換大概有幾種思路，各有利弊，得根據(jù)實際情況選擇。
最傳統(tǒng)的方式是在翻譯階段直接處理。譯員拿到源文本，看到"5 miles"就翻譯成"8公里"，看到"32°F"就翻譯成"0℃"。這種方式的好處是譯文里呈現(xiàn)的就是用戶直接能看的內(nèi)容，不需要程序再做額外處理。
但這種方式的問題也很明顯。首先，譯員得有相關(guān)的專業(yè)知識，知道什么單位對應(yīng)什么數(shù)值，不然很容易換算錯誤。其次，當(dāng)軟件允許用戶自己選擇單位偏好的時候，這種硬編碼的翻譯就不靈了——用戶明明想看英里，你給人家翻譯成了公里，這軟件用著就別扭。
我們康茂峰在處理這類項目的時候，一般會讓譯員準(zhǔn)備一份單位換算表放在手邊，遇到數(shù)值加單位的組合時格外小心。重要的數(shù)據(jù)還會安排校對環(huán)節(jié)專門核實，避免出現(xiàn)"100公里"被翻成"160公里"這種錯誤。
比較現(xiàn)代的做法是把數(shù)值和單位分開處理。源文本里不是寫死"5 miles"，而是寫成"{distance} {unit}"這樣的變量占位符。程序根據(jù)用戶的地區(qū)設(shè)置和偏好選擇，自動填入合適的數(shù)值和單位。
這種方式的優(yōu)勢在于靈活性強(qiáng)。用戶想看公里就看公里，想看英里就看英里，一個設(shè)置切換就搞定，翻譯文本本身不用改。維護(hù)起來也方便，萬一要新增一個單位類型，只用改程序邏輯，不用重新翻譯所有內(nèi)容。
缺點(diǎn)是實現(xiàn)起來稍微麻煩點(diǎn)，需要開發(fā)配合。而且對譯員來說，這種變量式的文本翻譯起來不太直觀，有時候上下文信息不足，很難準(zhǔn)確判斷這個數(shù)值該用什么樣的單位表達(dá)。比如"5"這個數(shù)字，如果是距離，用英里顯示可能需要顯示"5.0"或"5.00"來保持精度；如果是溫度，顯示為"5"可能就夠了。
實際操作中，最穩(wěn)妥的做法往往是混合使用。數(shù)值部分動態(tài)處理，單位標(biāo)識和描述性文本則由譯員來定。
比如天氣APP的預(yù)報，程序負(fù)責(zé)把氣溫數(shù)值從開爾文轉(zhuǎn)換成攝氏度或華氏度，但界面上的單位符號℃或℉的字體、位置、與數(shù)字的間距，則由本地化團(tuán)隊來調(diào)整，確保看起來和原生應(yīng)用一樣自然。跑步APP里距離顯示也是類似，數(shù)字是程序算的，但"每公里配速"這種表述的翻譯質(zhì)量就得靠譯員來把控。
理論說了不少，最后分享幾個實操中特別好用的建議。
首先是建立單位轉(zhuǎn)換的標(biāo)準(zhǔn)化流程。別讓譯員自己拿計算器算，最好有個統(tǒng)一的換算表或者工具。康茂峰內(nèi)部在處理這類項目時，會先整理出源語言和目標(biāo)語言之間的單位換算系數(shù)表，譯員和校對都按照同一份標(biāo)準(zhǔn)來，減少個人理解差異帶來的誤差。
其次是注意數(shù)值的精度處理。很多單位換算會產(chǎn)生小數(shù)，比如1英里等于1.60934公里。顯示的時候是保留兩位小數(shù)"1.61公里"，還是取整"2公里"，或者是精確顯示"1.6公里"，這個得根據(jù)具體場景來定。地圖導(dǎo)航軟件可能需要精確到小數(shù)點(diǎn)后兩位，買菜稱重可能四舍五入到整數(shù)就行。翻譯的時候要和開發(fā)確認(rèn)好顯示規(guī)則。
第三是處理復(fù)數(shù)和單數(shù)的差異。英文里"1 mile"和"2 miles"不一樣，俄語里不同數(shù)字后面對應(yīng)的單位詞尾變化更是復(fù)雜。翻譯的時候要注意目標(biāo)語言的單復(fù)數(shù)規(guī)則，別給用戶顯示"1公里s"這種笑話。有些語言系統(tǒng)有現(xiàn)成的復(fù)數(shù)規(guī)則庫，用起來會方便很多。
第四是考慮本地化后的界面布局。有些語言的單位名稱特別長，比如"平方千米"比"km2"長很多，原來剛好能顯示完的界面可能就放不下了。翻譯的時候要預(yù)估一下目標(biāo)文本的長度，必要時和設(shè)計開發(fā)溝通調(diào)整布局空間。
單位轉(zhuǎn)換的坑其實挺多的，我見過幾個特別典型的例子，寫出來給大家提個醒。
| 錯誤類型 | 典型案例 | 如何避免 |
| 單位類別混淆 | 把容量單位"fluid ounce"當(dāng)成重量單位"ounce"翻譯 | 確認(rèn)上下文，標(biāo)注清楚單位類型 |
| 換算系數(shù)錯誤 | 溫度轉(zhuǎn)換時忘記減32，直接用5/9乘以華氏度 | 使用驗證過的換算公式和工具 |
| 精度丟失 | 把"3.2 ounces"翻譯成"約90克"（實際91.25克） | 根據(jù)使用場景確定合適的精度范圍 |
| 硬編碼單位 | 在多語言文件中直接寫死"km"無法切換 | 使用變量或資源文件管理單位 |
| 文化習(xí)慣不符 | 向中國用戶顯示身高時用"6.2英尺" | 根據(jù)目標(biāo)市場默認(rèn)使用常用單位 |
測試環(huán)節(jié)也特別重要。建議在本地化測試階段，專門準(zhǔn)備一套覆蓋各類單位的測試用例。比如溫度要測0℃以下、正負(fù)轉(zhuǎn)換、極值等場景；長度要測小數(shù)、整數(shù)、大數(shù)值等不同情況。測試人員最好能用目標(biāo)語言母語人士，或者至少對當(dāng)?shù)爻Ｓ脝挝环浅Ｊ煜ぃ@樣才能看出顯示是否自然。
說真的，軟件本地化里的單位轉(zhuǎn)換看起來簡單，做起來全是細(xì)節(jié)。它不像翻譯語句那樣需要處理文化隱喻，也不像界面布局那樣講究視覺美感，但它就是那種"做對了沒人夸你，做錯了用戶罵娘"的關(guān)鍵小事。
我的經(jīng)驗是，與其后期補(bǔ)救，不如前期就把流程搭好。譯員手邊有換算表，開發(fā)那邊有靈活的配置，項目經(jīng)理在審閱時多問一句"這個單位處理了嗎"，比什么都強(qiáng)。
本地化這行當(dāng)，說到底就是替用戶多想一步。人家用你的軟件，圖的就是個省心。你把單位給人家換算得明明白白，清清楚楚，人家自然就覺得這軟件靠譜。反過來，三天兩頭看見個奇怪單位，用戶心里免不了犯嘀咕：這軟件會不會不太專業(yè)？
所以啊，單位轉(zhuǎn)換這件事，值得你認(rèn)真對待。
