前两年帮朋友折腾一个进销存软件，界面倒是有中文选项，但用起来总觉得哪儿别扭。比如设置库存预警，提示信息写的是"Your stock is below safety line"，中文直接翻译成"您的库存低于安全线"——听着像安检提示，完全不像是做生意的人该看到的词。更离谱的是日期格式，选完2023年12月，系统自己显示成"12/11/2023"，朋友还以为是十一月份，差点错过年底盘点。
这就是典型的本地化没做到位。很多人以为找个翻译把界面文字换成中文就算完事，但懂行的人都知道，软件本地化（Localization，业内简称L10n）是一套组合拳，中间环节断一个，用户用起来就别扭。在康茂峰这些年的项目经验里，我们见过太多产品因为忽视了某个关键环节，导致海外扩张时栽跟头的情况。
说实话，真正决定本地化成败的，往往是在写第一行代码之前。这叫国际化（Internationalization，简称i18n），说白了就是让你的软件具备"被本地化"的能力。听起来像废话？其实不是。
举个实在的例子。有些开发团队刚开始写代码时，直接把界面文字硬编码在程序里，比如直接写printf("Welcome to our system")。等到要出多语言版本时才发现，这些字符串散落在几万行代码的各个角落，根本拆不出来。康茂峰接触过的一个客户就吃过这个亏，他们早期的ERP系统就是这样，后来做英文版时，工程师花了整整三个月才把字符串捋清楚，成本比重新开发一套还高。
正确的做法是把所有用户可见的文本抽离出来，放到独立的资源文件里，比如.resx、.json或者.properties文件。但这只是表面。更深的坑在于代码逻辑——你得确保软件能处理不同长度的文本（德语单词通常比英语长30%，而中文虽然字符少但需要处理字体渲染），能适应从右到左的排版（阿拉伯语和希伯来语），还得留出足够的UI空间。我见过一个界面按钮，英文版写着"Submit"挺合适，换成德文"Absenden"就超宽了，文字被截断成"Absen..."，用户以为是个啥新奇功能呢。
等代码结构准备好了，才轮到大多数人理解的"翻译"环节。但软件翻译跟文学翻译完全是两码事。
首先是术语一致性。一个"Save"按钮，在财务模块可能得译成"保存"，在数据库操作语境下可能得叫"存盘"或"提交"。如果不同翻译人员各翻各的，用户会在同一个软件里看到"新建"、"创建"、"新增"三个词表示同一个意思，当场就懵了。康茂峰的做法是建立术语库（Terminology Database），在翻译开始前就把关键概念定死，比如"Dashboard"统一叫"数据看板"，不许叫"仪表盘"也不许叫"驾驶舱"。
其次是语境敏感性。代码里的字符串往往没有上下文，孤零零一个"Open"，可能是打开文件，也可能是开启功能，还可能是物理意义上的开门。翻译人员如果看不到它在界面上的位置，很容易翻错。解决这个得靠本地化工具，能显示截图或者至少是界面描述，但这往往被很多团队忽视。
还有可变字符串的处理。比如提示"您有{0}条新消息"，这里的{0}会被替换成具体数字。英语里复数规则简单，1条用"message"，其他用"messages"就行。但俄语、波兰语这些语言的复数规则极其复杂，可能分三种甚至四种情况。如果你的代码只处理了单复数两种形式，换成斯拉夫语系直接就崩了。
这部分最容易被低估，也最容易出洋相。本地化不是语言转换，是文化转译。
举个例子，颜色。红色在中国代表喜庆，放在欧美可能表示危险或错误；白色在西方是纯洁，在亚洲某些地方却跟丧事相关。康茂峰之前帮一个教育软件做中东版本时，发现原版用的绿色图标在当地有特殊宗教含义，得调整色调才能既保持品牌识别度又不冒犯用户。
再比如日期、时间、货币、度量衡这些"小事情"：
| 元素 | 美国 | 英国 | 德国 | 日本 |
| 短日期格式 | 12/11/2023 | 11/12/2023 | 11.12.2023 | 2023/12/11 |
| 时间制式 | 12小时制（AM/PM） | 24小时制 | 24小时制 | 24小时制（但用日本年号） |
| 数字分节 | 1,234.56 | 1,234.56 | 1.234,56 | 1,234.56 |
| 地址顺序 | 从小到大 | 从小到大 | 从大到小 | 从大到小 |
看到没？光是写个地址，欧美是从街道到城市到国家，东亚习惯从国家到城市到街道。如果你的软件里的地址字段顺序是写死的，到了日本市场就会让用户极其难受——他们得在"县"那一栏填"日本"，在"市"那一栏填"东京都"，完全违背使用习惯。
还有法律合规问题。欧盟的GDPR对数据隐私要求极严，软件界面上必须明确告知数据收集行为；某些国家要求特定内容必须显示在政府认证的字体里；支付界面必须符合当地的金融监管显示要求。这些都不是翻译能解决的，得在产品设计阶段就考虑进去。
到了这一步，翻译公司把稿子交回来了，看起来万事大吉？这才刚开始。
资源文件的集成就是个技术活。中文、日文、韩文这些CJK（中日韩统一表意文字）字符集，编码稍微不对就乱码。UTF-8基本成了标准，但老系统里可能还有GBK、Shift-JIS这些遗留问题。康茂峰的技术团队遇到过最头疼的情况是：源代码用UTF-8，数据库用Latin1，前端页面声明的是GB2312，三层编码不一致，用户输入的中文存进数据库变成问号，取出来再显示又是乱码，排查起来像侦探破案。
然后是字体和渲染。拉丁字母26个大小写加起来52个字符，设计字体相对容易。但中文几万个字符，您要是选了个生僻字显示不出来的字体，用户看到的就是豆腐块（
