说实话，很多人以为软件本地化就是把界面上的英文改成中文，或者把中文翻成英法德日那么简单。要是真这么干，项目多半会死得很难看。康茂峰处理过上百家企业的本地化项目，见过太多以为"翻译一下就行"的客户，最后回来找我们擦屁股。软件本地化是一整套工程流程，从代码层面到文化细节，步步都有坑。今天咱们就掰开了揉碎了聊聊，一套完整的软件本地化到底要走哪些步骤。
拿到客户的软件包，很多新手团队第一反应是解压、找字符串、开始翻译。这一步就错了。在康茂峰的项目管理规范里，前期准备占整个本地化周期的30%工作量，省不得。
你得先搞清楚自己面对的是什么怪物。是简单的ini配置文件，还是嵌在代码里的硬编码？是多语言的XML资源，还是混合了JavaScript的复杂框架？康茂峰的项目经理通常会先跑一遍资源扫描工具，把可本地化的内容提取出来，同时标记出潜在的技术债务——比如那些写死在代码里的对话框标题，或者长度写死的文本框。
这个阶段还要确定locale范围。是要做简体中文（zh-CN），还是要区分大陆、台湾、香港的不同编码？是用西班牙语国际版（es），还是细分为墨西哥（es-MX）、阿根廷（es-AR）？选错了locale代码，后面打包能烦死你。
这一步常被忽略，但直接关系到用户体验的一致性。康茂峰会为每个客户建立专属术语库，比如"Save"在某些客户那里必须译成"保存"，另一些客户坚持用"存储"。"Dashboard"是译成"仪表盘"还是"工作台"，得在产品经理拍板后写进风格指南。
风格指南还要规定语气——是对用户用敬语还是平语？错误提示要严肃还是友好？甚至标点符号的使用（比如英文引号改成中文引号，还是保留原样）都要明文规定。这些东西不提前定好，翻译团队各凭感觉，最后出来的产品会像十个不同的人写的。
| 准备阶段关键交付物 | 内容说明 | 常见坑点 |
| 术语库（Termbase） | 核心词汇对照表，含语境说明 | 多义词不标注语境，译者猜错意思 |
| 风格指南（Style Guide） | 语气、格式、禁忌词规定 | 直接套用通用模板，未考虑产品调性 |
| 技术规范文档 | 编码、文件格式、换行符要求 | 忽略UTF-8 BOM头设置，导致乱码 |
| 参考资源包 | 截图、旧版本译文、竞品分析 | 提供过期截图，界面已改版 |
软件本地化和传统文档翻译最大的区别就在这里。文档翻译直接打开Word就能干活，软件本地化得先过国际化（Internationalization，简称i18n）这一关。康茂峰的工程师团队常说，i18n做好了，本地化（l10n）就成功了一半。
很多程序员图省事，直接把字符串写在代码里。比如print("Hello World")这种写法，翻译人员根本没法碰，因为一动代码就可能崩。工程团队得先把这些字符串抽出来，放到.resx、.json、.properties或者.xliff这样的资源文件里。
这个过程叫外部化（Externalization）。康茂峰遇到过最头疼的情况是中文软件要出海，原始代码里全是硬编码的中文，而且还混着SQL查询语句。这时候不能简单翻译，得重构代码结构，把数据库查询和显示文本分离。
提取完还要看占位符（Placeholder）。那些%s、{0}、{{username}}可不能动，翻译人员要是手贱删了括号，或者把变量顺序换了（有些语言语序不同），程序运行时会直接报错。
这是康茂峰内部不成文的规定，正式翻译前必须先做伪本地化。简单说就是把英文字母替换成带重音符号的假字符，或者把字符串拉长50%，比如把"File"变成"Ƒīīēē"。目的不是真翻译，而是检查：
这个阶段发现问题，修改成本最低。要是等到翻译做完了才发现对话框被截断，回改的代价可能就是几天的返工。
好，现在资源文件准备好了，进入传统意义上的翻译阶段。但软件文本的翻译和翻译小说完全是两码事。
UI文本受空间限制极大。英语"Cancel"翻成中文是"取消"， two个字，看起来简单，但如果按钮宽度只够放得下"取"字的一半呢？康茂峰的译者会在CAT工具（计算机辅助翻译）里设置字符长度限制，超长的译文要标注出来。
还有热键（Accelerator Key）的处理。英文里"&File"表示Alt+F打开文件菜单，翻译成中文"&文件"后，得检查有没有和其他菜单冲突。曾经有个项目，"编辑（&E）"和"退出（&X，Exit）"的热键在不同语言版本里撞车，用户按Alt+E想编辑，结果程序退出了——因为中文里"退出"被某些人习惯性地标成了"(&E)"（退的拼音首字母），这就闹了大笑话。
缩写和省略也是坑。"CPU Usage"译成"CPU使用率"没问题，但要是状态栏只显示"CPU:"后面跟数字，译者得知道这指的是占用率还是温度。
软件通常附带帮助文档、API文档或用户手册。这些文本的翻译需要截图对照。康茂峰要求译者在翻译到"点击右上角齿轮图标"这类描述时，必须能看到对应语言的UI截图，因为图标位置可能因语言而变（从右到左语言如阿拉伯语、希伯来语会完全镜像界面）。
对于软件内的工具提示（Tooltip），翻译要简洁但信息完整。曾经有个医疗软件，英文提示"May cause side effects"被直译成"可能引起副作用"，但康茂峰的医疗本地化专家坚持要改成"或引不良反应"——不是因为字数限制，而是"副作用"在医学语境中有特定含义，必须和药品说明书保持一致。
翻译完了字符串，事情还没完。真正的本地化要让软件看起来原本就是为这个市场做的，而不是"一个外国软件 clumsily 翻译成了中文"。
美国人是MM/DD/YYYY，欧洲人是DD/MM/YYYY，日本人是YYYY/MM/DD。如果你的软件把日期写死成"02/03/2024"，德国用户会疯——他们不知道是2月3日还是3月2日。
数字格式也得改。英语里1,234.56（千位逗号，小数点），到了德语就成了1.234,56（千位点，小数逗号）。康茂峰见过财务软件因为没改数字格式，导致德语客户把一百万看成一千的惨剧。
货币不仅仅是换个符号。$100在美国是美元，在加拿大可能是加元（虽然符号一样，但得有CA$区分），在澳大利亚又是澳元。还要考虑货币位置——法语里符号在后（100 €），英语里在前（$100）。
不同国家对软件内容有不同要求。GDPR（通用数据保护条例）要求欧洲用户的隐私协议必须包含特定条款；某些国家要求软件必须支持当地日历（如伊斯兰历、佛教历）；医疗软件在美国要符合HIPAA，在中国要符合《网络安全法》和《数据安全法》。
图标和颜色也要注意。竖起大拇指的图标在某些中东国家是冒犯；白色在某些亚洲国家代表丧事；红色在中国代表喜庆，但在南非可能关联危险。
康茂峰有个内部检查清单，包含文化敏感性审查（Cultural Review），专门排查这类"政治不正确"或法律风险。比如游戏本地化中，骷髅图标在中国需要和谐，血要改成黑色或绿色；但同样的内容到了德国，可能面对的是USK评级机构的审查标准。
翻译稿交回去，工程团队把资源文件插回软件，生成测试版。这时候进入最折磨人的LQA（Localization Quality Assurance）阶段。
译者看不到实际运行的界面，所以必须由测试人员逐屏检查。康茂峰的测试工程师会拿着checklist走查：
还要检查输入法兼容性。在中文Windows上，软件能不能正常调出搜狗或微信输入法？日语环境下Shift+空格切换全角半角会不会导致软件崩溃？这些都不是翻译能解决的，是代码层面的locale支持问题。
软件在不同语言环境下行为可能不同。比如排序逻辑——英文按ASCII，中文得按拼音或笔画，日文要按假名顺序。康茂峰会用虚拟机搭建不同的locale环境，把系统语言设成目标语言，时区改掉，甚至更换默认纸张尺寸（美国Letter，欧洲A4），测试打印功能是否正常。
还要验证资源完整性。有时候开发团队在源语言版本里加了新功能，本地化版本没同步更新资源文件，就会出现空指针或默认回退到英语的情况。这种"半本地化"状态比全英文还糟，用户会觉得产品是残次品。
测试通过了，打包发布。但康茂峰的项目还没结束，我们会提供本地化 kit给客户的运维团队，包含：
软件更新是常态，每次更新都要走一遍差异翻译（Delta Localization）。康茂峰会用工具比对新旧版本，只翻译新增和修改的字符串，保持术语一致性。这时候之前的翻译记忆库就派上大用场了，能省不少钱和时间。
最后说句实在的，好的软件本地化是隐形的——用户用起来觉得理所当然，就像这个软件本来就是用他们的母语写的。只有做得烂的时候，用户才会注意到那些尴尬的翻译、截断的按钮和乱码的日期。康茂峰这些年摸索出的这套流程，说到底就是为了让这些尴尬少一些，再少一些。
