多语言不是翻译，是口径

系统要支持多语言，第一反应是"找个翻译公司把词条翻了"。

翻完上线，业务方会发现：字都认识，但意思不对。

五个容易翻错的词

第一，整车。中文里指"完整的车"，英文里可能是 CBU、complete vehicle、finished vehicle，每个词的报关含义不同。

第二，现车。中文指"可立即交付的车"，但"可交付"的条件各市场不同：有的是完成清关，有的是完成 PDI，有的是完成上牌。

第三，库存。仓库里的车、在途的车、已售未交付的车，中文都可能叫"库存"，但财务口径完全不同。

第四，交付。有的市场指"交钥匙"，有的指"完成登记"，有的指"客户签收"。三种口径对应三种责任时点。

第五，保修。法定的、厂家的、经销商的、延保的，四层责任在各市场的边界不同。

口径错了会怎样

第一，算错钱。库存口径不一致，资金占用算少，毛利算多。

第二，判错责。交付时点定义不同，车损责任归属就不同。

第三，赔错款。保修范围翻译偏差，客户索赔时双方各执一词。

三种后果都不会立刻爆发，会在半年后集中出现。

翻译错的是字，口径错的是账。

三层做法

第一层，术语表。每个业务词给出：中文名、英文名、定义、对应字段、各市场的差异说明。

第二层，字段级说明。系统里每个字段都有一句口径注释：这个字段统计什么、不含什么、什么时候更新。

第三层，本地复核。由当地业务负责人确认术语与口径，不是由翻译确认。

三层里，第一层是基础，第三层是保障。缺任一层，术语表就会漂移。

谁来维护术语表

不能交给翻译公司，因为翻译不懂业务。

不能交给 IT，因为 IT 不定义业务。

正确的归属是业务方：由懂业务的人维护，翻译只负责语言层面的表达。

维护节奏也要定：新增市场、新增车型、法规变动，三件事触发更新。

多语言的工程做法

第一，文案与代码分离。所有用户可见文字走资源文件，不硬编码。

第二，字段级语言包。不是整页翻译，是按字段翻译，因为口径差异在字段级。

第三，日期、货币、单位本地化。这些格式错误比用词错误更伤专业感。

第四，回退机制。缺翻译时回退到英文或中文，不能显示空白或键名。

第五，术语一致性校验。同一个词在不同页面必须同一种译法，用工具检查。

五条都是工程细节，但没有一条能靠"多招几个翻译"解决。

落在哪个环节，谁在痛

第四行是最实际的痛点：多国数据合不起来，因为每个国家的人对同一个字段的理解不同。

一个常见的误解

"多语言就是界面翻译。"

界面翻译只是最表层。真正决定系统能不能用起来的，是当地员工看到字段时，理解的是不是同一件事。

一个真实的翻车现场

一个企业把"现车"直译成当地语言，上线后经销商看到的库存数字比实际大出一截。

查了三周才发现：中文的"现车"包含了"已清关但未 PDI"的车，而当地语言里那个词只指"可立即交付"。

结果销售按系统数字承诺客户三天提车，实际要等两周。投诉集中爆发。

这不是翻译错误，是口径错误。字没错，指的东西错了。

修的办法不是改翻译，是在字段上加一句说明：本字段包含哪些状态、不包含哪些状态。

一句收尾

多语言的本体是口径 —— 词翻对了只是能读，口径统一了才能算账。

相关页面：产品矩阵、区域与海外交付、案例与演示、资源与洞察；如需按自己的链路逐项核对，可 联系我们。

说明：本文为〈算数·海辕〉实务观察，用于说明出海业务链路与系统能力，不含真实客户数据与虚构经营数字；所列税率、门槛与认证要求以目的国当期法规为准，数据来源见文末。