首页新闻和文章01.02 是 2月1日还是 1月2日？本地化中那些让人花钱的陷阱

01.02 是 2月1日还是 1月2日？本地化中那些让人花钱的陷阱

字符串“01.02.2025”在一个国家表示2月初，在另一个国家却表示1月初。如果网店或应用在显示这样的日期时没有考虑区域设置，客户可能会读出与原意不同的日期。这类细节很少写进技术任务书，却往往导致退货、错过截止日期以及令人尴尬的客服邮件。下面我们梳理最常见的本地化陷阱，并看看如何避免。

日期和时间：同一天，三种读法

日期各部分的顺序因国家而异。在俄罗斯、德国和欧洲大部分地区，通用的格式是“日.月.年”。在美国，月份排在前面，因此“03/04/2025”在那里表示3月4日，而不是4月3日。在日本、中国和韩国，顺序则相反：先写年，再写月和日。

时间也是如此。在俄罗斯、欧洲大部分地区和拉丁美洲，人们习惯使用24小时制；而在美国、加拿大、澳大利亚和印度，则广泛使用带AM和PM标记的12小时制。不加标记的“5:00”在不同国家会被读成不同的时间，一场约在“五点”的会议，可能会与计划时间相差十二个小时。

为了避免猜测，在数据和API中最好采用ISO 8601标准（例如2025-02-01T14:30）。而在界面中，应通过区域设置功能来显示日期，而不是手动输入。

“1 500,75”在俄罗斯与“1,500.75”在美国表示的是同一个数值。在德国和巴西，千位用点号分隔，小数部分用逗号：“1.500,75”。在瑞士则使用撇号：“1'500.75”。在印度，数字的分组方式也不同：“1,00,000”表示十万。

这里的错误尤其隐蔽。如果价格“1.500”本意是一千五百，而系统却将其读作一点五，买家只会在收银台才发现差异。因此，在代码中切勿手动拼接数字字符串，应使用按区域设置的格式化功能，并在导入文件时检查数字的解析结果。

货币符号看似是小事，却很容易造成混淆。“$”符号在美国、加拿大、澳大利亚以及其他若干国家都在使用，因此如果没有货币代码，“$”可能指其中任何一种美元。正因如此，在国际化场景中通常会使用ISO 4217标准的三字母代码，如USD、EUR、RUB。

符号的位置也各不相同。在英语国家写作“$100”，在法国写作“100 €”（中间是不间断空格），在俄罗斯则写作“100 ₽”或“100 руб.”。有时问题会在翻译中显现：一句“价格含增值税”的话，在某种语言中需要另一种句式；如果文本是由若干片段拼接而成、再嵌入金额，词序就会被打乱。

舍入规则同样因货币而异。日元通常没有小数位，而科威特第纳尔则精确到千分位。如果系统对所有货币都统一保留两位小数，计算结果可能与银行对账单相差几分钱；在大额交易中，差额则可能相当可观。

公制与英制

世界大部分地区使用公制，但美国仍使用英尺、磅、加仑和华氏度。在英国，路标以英里为单位，牛奶则按品脱出售，不过那里的品脱比美国的大：约568毫升，而美国的约为473毫升。加仑在大西洋两岸的容量也不相同。

对于网店而言，这意味着商品尺寸、包裹重量和包装容积应以买家熟悉的单位显示，同时保证数值的准确性。处理说明书的译员需要判断，应当翻译单位还是换算数值。例如，若说明书中写有“10英寸”，在俄罗斯版中更合理的做法是写“25厘米”，但如果原始数值对技术参数很重要，则应在括号中保留原值。

注册表单最常在三个字段上出问题。电话：在俄罗斯可能是“+7 (999) 123-45-67”，而在德国号码长度并不固定，许多使用固定掩码的模板无法通过其验证。最好使用带国家区号选择的字段，并配合号码验证库。

地址：在日本，地址从大到小书写（都道府县、市、区、街区门牌号），而在俄罗斯和欧洲则相反。美国的邮政编码由五位数字组成，英国则是字母与数字的组合。若设置“邮编，仅限数字”的字段，就会拒绝许多真实存在的地址。

姓名：在西班牙和拉丁美洲，人们常有两个姓氏；在冰岛，人们用父名代替姓氏；还有一些人根本只有一个名字。姓氏中的撇号（如“O'Brien”）或连字符不应导致错误。最基本的要求很简单：不要把本不必要的两个字段设为必填，并接受任何Unicode字符。

处理格式问题不应等到检查阶段，而应从设计阶段就开始。以下做法有所帮助：

主要结论很简单：格式本身就是意义的一部分。优秀的翻译不仅保留词语，还保留读者如何理解日期、价格和距离。如果提前将本地化纳入计划，这些陷阱几乎不会增加成本；如果等到上线后才发现，修复的代价将远高于其他一切。