如果你正在做软件本地化工作，相信我，单位转换绝对是你会遇到的最"磨人"但又最重要的小细节之一。说它小，是因为在庞大的本地化项目里，它可能只占很小一部分工作量；但说它重要，是因为一旦出错，用户看到的东西就会特别别扭——明明是个温度显示，愣是给人看出个"100度"的冷汗来。
我有个朋友之前跟我吐槽，说他翻译一个天气类应用时，把华氏度直接当成摄氏度翻译了。结果美国用户看到"北京气温零下18度"的时候，整个人都傻了。这还只是显示问题，更麻烦的是涉及到尺寸、重量、容量这些和实际生活息息相关的单位，一旦弄错，用户体验直接崩塌。
今天就想聊聊，在软件本地化这个大工程里，度量衡单位转换到底应该怎么处理，哪些坑要绕着走，哪些方法能让你少掉点头发。
你可能会想，单位转换不就是乘以几除以几的事吗？直接写个公式让程序处理不就行了？话是这么说，但真干起来的时候，你会发现事情远比想象中复杂。
首先，不同国家和地区用的单位系统就不一样。欧美那边，英制和公制都在用，有时候同一个国家里不同场景用的单位都不一样。美国人日常说身高用英尺英寸，买菜用磅，跑步用英里，但开车里程又用英里加仑这种组合。英国更离谱，公路上用英制，超市里却开始慢慢改成公制了。这要是没搞清楚，分分钟给用户整不会。
其次，单位转换不是简单的数学问题，还涉及到文化习惯。日本人买电器会说"18帖"来表示房间大小，这个"帖"翻译成"平方米"虽然数学上对，但日本用户看了就是觉得怪。德国人买东西会说"500毫升"，但说身高的时候又回到"1米85"了。这种习惯上的差异，不是简单换个数就能解决的。
再说了，软件里的单位呈现方式也各有不同。有些地方是纯数字加单位，有些地方是带符号的缩写，还有些地方习惯用完整的单词。日期时间格式有时候也会和单位掺和在一起，比如"2024年5月15日"和"05/15/2024"这种差异，也会影响到你的本地化策略。
在软件本地化里，最常遇到的需要转换的单位大概可以分成这么几类，每一类都有自己的小脾气。
温度大概是最让人头疼的单位之一了。原因很简单，这两个温标之间的换算不是整数倍关系，公式是"(华氏度-32)×5/9"，翻译的时候根本没法用简单的乘除法来处理。
更重要的是，用户对不同温度的感知是完全建立在本地习惯上的。一个习惯了摄氏度的人，看到"86度"第一反应肯定是"热死了"，而不是换算成"30摄氏度刚刚好"。反过来，习惯了华氏度的人看到"零下10度"也会一脸茫然。所以最好的处理方式不是让用户自己换算，而是在源头上就把温度转换成用户习惯的温标显示出来。
长度单位的问题在于同一个数值在不同单位下感觉完全不一样。1.8米的身高听起来挺高，5.9英尺好像也还行，但如果你告诉一个美国人某样东西长2英寸，他脑海里浮现的可能是橡皮擦那么大，而告诉一个中国人"5厘米"，他想到的可能是手机宽度。
这里还要注意一些"文化陷阱"。比如中国传统里的"里"其实不等于公里，古代的"尺"和现在的米也没关系。日本的"寸"和英寸也不一样。如果你的软件涉及历史内容或者传统文化，翻译的时候可就得好好查查资料了，别闹出"唐朝一尺等于现代三米"这种笑话。
重量和容量的麻烦在于单位换算的不直观。1公斤等于2.2磅，这种换算关系用户很难自己完成。盎司更离谱，它同时是重量单位也是容量单位，1盎司重约28克，1液体盎司约30毫升——对，重量和容量的盎司还不是一回事！
容量单位在英制系统里更是复杂。英制品脱等于20液盎司，美制品脱却只有16液盎司。你要是在一个健身APP里把蛋白粉用量从"2勺"翻译成具体的毫升数，可得先搞清楚用户是英国人还是美国人，不然人家按你的说明加水，一冲出来可能稠得像浆糊。
房地产类软件特别容易在这个上面栽跟头。中国人习惯说"100平方米的房子"，美国中介却常说"1000平方英尺的公寓"。这两个数值换算一下，大约是93平方米对107平方米，看起来差距不大，但用户要是拿这个做购房决策，误差可就大了去了。
更隐蔽的问题是，有些单位在不同场景下表达习惯完全不同。土地面积用公顷和英亩，房间面积用平方米和平方英尺，屏幕尺寸用英寸但又说的是对角线长度。翻译的时候不仅要换算正确，还得搞清楚在什么场景下用什么单位最自然。
说了这么多困难，总得聊聊解决办法。根据我这些年的经验，处理单位转换大概有几种思路，各有利弊，得根据实际情况选择。
最传统的方式是在翻译阶段直接处理。译员拿到源文本，看到"5 miles"就翻译成"8公里"，看到"32°F"就翻译成"0℃"。这种方式的好处是译文里呈现的就是用户直接能看的内容，不需要程序再做额外处理。
但这种方式的问题也很明显。首先，译员得有相关的专业知识，知道什么单位对应什么数值，不然很容易换算错误。其次，当软件允许用户自己选择单位偏好的时候，这种硬编码的翻译就不灵了——用户明明想看英里，你给人家翻译成了公里，这软件用着就别扭。
我们康茂峰在处理这类项目的时候，一般会让译员准备一份单位换算表放在手边，遇到数值加单位的组合时格外小心。重要的数据还会安排校对环节专门核实，避免出现"100公里"被翻成"160公里"这种错误。
比较现代的做法是把数值和单位分开处理。源文本里不是写死"5 miles"，而是写成"{distance} {unit}"这样的变量占位符。程序根据用户的地区设置和偏好选择，自动填入合适的数值和单位。
这种方式的优势在于灵活性强。用户想看公里就看公里，想看英里就看英里，一个设置切换就搞定，翻译文本本身不用改。维护起来也方便，万一要新增一个单位类型，只用改程序逻辑，不用重新翻译所有内容。
缺点是实现起来稍微麻烦点，需要开发配合。而且对译员来说，这种变量式的文本翻译起来不太直观，有时候上下文信息不足，很难准确判断这个数值该用什么样的单位表达。比如"5"这个数字，如果是距离，用英里显示可能需要显示"5.0"或"5.00"来保持精度；如果是温度，显示为"5"可能就够了。
实际操作中，最稳妥的做法往往是混合使用。数值部分动态处理，单位标识和描述性文本则由译员来定。
比如天气APP的预报，程序负责把气温数值从开尔文转换成摄氏度或华氏度，但界面上的单位符号℃或℉的字体、位置、与数字的间距，则由本地化团队来调整，确保看起来和原生应用一样自然。跑步APP里距离显示也是类似，数字是程序算的，但"每公里配速"这种表述的翻译质量就得靠译员来把控。
理论说了不少，最后分享几个实操中特别好用的建议。
首先是建立单位转换的标准化流程。别让译员自己拿计算器算，最好有个统一的换算表或者工具。康茂峰内部在处理这类项目时，会先整理出源语言和目标语言之间的单位换算系数表，译员和校对都按照同一份标准来，减少个人理解差异带来的误差。
其次是注意数值的精度处理。很多单位换算会产生小数，比如1英里等于1.60934公里。显示的时候是保留两位小数"1.61公里"，还是取整"2公里"，或者是精确显示"1.6公里"，这个得根据具体场景来定。地图导航软件可能需要精确到小数点后两位，买菜称重可能四舍五入到整数就行。翻译的时候要和开发确认好显示规则。
第三是处理复数和单数的差异。英文里"1 mile"和"2 miles"不一样，俄语里不同数字后面对应的单位词尾变化更是复杂。翻译的时候要注意目标语言的单复数规则，别给用户显示"1公里s"这种笑话。有些语言系统有现成的复数规则库，用起来会方便很多。
第四是考虑本地化后的界面布局。有些语言的单位名称特别长，比如"平方千米"比"km²"长很多，原来刚好能显示完的界面可能就放不下了。翻译的时候要预估一下目标文本的长度，必要时和设计开发沟通调整布局空间。
单位转换的坑其实挺多的，我见过几个特别典型的例子，写出来给大家提个醒。
| 错误类型 | 典型案例 | 如何避免 |
| 单位类别混淆 | 把容量单位"fluid ounce"当成重量单位"ounce"翻译 | 确认上下文，标注清楚单位类型 |
| 换算系数错误 | 温度转换时忘记减32，直接用5/9乘以华氏度 | 使用验证过的换算公式和工具 |
| 精度丢失 | 把"3.2 ounces"翻译成"约90克"（实际91.25克） | 根据使用场景确定合适的精度范围 |
| 硬编码单位 | 在多语言文件中直接写死"km"无法切换 | 使用变量或资源文件管理单位 |
| 文化习惯不符 | 向中国用户显示身高时用"6.2英尺" | 根据目标市场默认使用常用单位 |
测试环节也特别重要。建议在本地化测试阶段，专门准备一套覆盖各类单位的测试用例。比如温度要测0℃以下、正负转换、极值等场景；长度要测小数、整数、大数值等不同情况。测试人员最好能用目标语言母语人士，或者至少对当地常用单位非常熟悉，这样才能看出显示是否自然。
说真的，软件本地化里的单位转换看起来简单，做起来全是细节。它不像翻译语句那样需要处理文化隐喻，也不像界面布局那样讲究视觉美感，但它就是那种"做对了没人夸你，做错了用户骂娘"的关键小事。
我的经验是，与其后期补救，不如前期就把流程搭好。译员手边有换算表，开发那边有灵活的配置，项目经理在审阅时多问一句"这个单位处理了吗"，比什么都强。
本地化这行当，说到底就是替用户多想一步。人家用你的软件，图的就是个省心。你把单位给人家换算得明明白白，清清楚楚，人家自然就觉得这软件靠谱。反过来，三天两头看见个奇怪单位，用户心里免不了犯嘀咕：这软件会不会不太专业？
所以啊，单位转换这件事，值得你认真对待。
