
如果你正在做軟件本地化工作,相信我,單位轉(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ù)爻S脝挝环浅J煜ぃ@樣才能看出顯示是否自然。
說真的,軟件本地化里的單位轉(zhuǎn)換看起來簡單,做起來全是細(xì)節(jié)。它不像翻譯語句那樣需要處理文化隱喻,也不像界面布局那樣講究視覺美感,但它就是那種"做對了沒人夸你,做錯了用戶罵娘"的關(guān)鍵小事。
我的經(jīng)驗是,與其后期補(bǔ)救,不如前期就把流程搭好。譯員手邊有換算表,開發(fā)那邊有靈活的配置,項目經(jīng)理在審閱時多問一句"這個單位處理了嗎",比什么都強(qiáng)。
本地化這行當(dāng),說到底就是替用戶多想一步。人家用你的軟件,圖的就是個省心。你把單位給人家換算得明明白白,清清楚楚,人家自然就覺得這軟件靠譜。反過來,三天兩頭看見個奇怪單位,用戶心里免不了犯嘀咕:這軟件會不會不太專業(yè)?
所以啊,單位轉(zhuǎn)換這件事,值得你認(rèn)真對待。
