说实话，我刚入行那会儿也搞不清楚这件事。那时候觉得本地化嘛，不就是找几个译者把界面文字翻一翻吗？后来才发现，这里面的水比我想象的要深得多。
先说个事吧。前几年有个朋友的公司花了十几万做了款软件，要推向东南亚市场。结果找的翻译公司只做了文字层面的翻译，结果在泰国上线的时候，用户输入泰文用户名系统就崩溃。日本那边更离谱，日期格式显示错乱，财务报表日期全乱套了。花了更多钱回头做二次适配，这就是没搞清楚"本地化翻译"到底包含什么导致的后果。
很多人把本地化和翻译画等号，这其实是个根本性的误解。翻译解决的是"说什么"的问题，而本地化解决的是"怎么说""在什么环境下说"的问题。打个比方，翻译是把你写的信翻译成外语，而本地化是把这封信改成符合收信人文化习惯的表达方式，可能还得调整信纸格式、称呼礼仪之类的。
软件本地化涉及到哪些内容呢？我给你列一下你就明白了：
你看，上面这些内容，有些确实只需要翻译文字就行，但有些就必须涉及到技术层面的调整。这也是为什么有些本地化项目花不了多少钱，而有些项目光技术评估就要花好几个月。
这个问题其实可以拆成两个层面来看。
如果你要本地化的软件满足这几个条件，那大概率只需要做文字翻译层面的工作：软件结构比较简单，不涉及复杂的数据格式处理；目标语言的文字方向和中文一致，都是从左到右；没有特殊的市场合规要求；软件本身的技术架构对国际化支持比较好，文字都是外部资源文件，不硬编码在程序里。
我举个例子你就明白了。像一些工具类的小软件，界面上的按钮、菜单、提示信息这些，把这些文字提取出来翻成目标语言，替换回去基本就能用。这种项目做起来很快，成本也相对低。
但现实中的软件往往没那么简单。以下几种情况是肯定需要技术介入的：
首先是字符编码和字体问题。中文在软件里显示正常，换成日文或者泰文就出现乱码，这往往是因为软件没有使用UTF-8编码，或者没有内置目标语言的字体支持。这种情况必须改代码，把字符集处理逻辑重新写一遍。
然后是界面布局的调整。德语翻译出来往往比中文长很多，一个按钮上的文字从"确定"变成"Bestätigen"，长度翻倍都不止。如果按钮宽度是写死的，那新文字就会显示不全。这时候要么改代码让按钮宽度自适应，要么重新设计界面布局。同样，俄语的句子普遍比较长，阿拉伯语则是从右向左写，这些都会影响界面显示。
还有就是数据格式的处理。日期格式在中国是"2024年3月15日"，在美国是"03/15/2024"，在欧洲很多地方是"15.03.2024"。时间格式、货币格式、数字的小数点千分位写法，这些在不同地区都不一样。如果软件里这些数据是直接按某种格式写死的，那就得改代码让系统根据用户所在地区自动识别和转换。
最后是功能逻辑的调整。这个听起来有点抽象，我给你解释一下。比如某些国家有法律要求，收集用户数据时必须明确告知并获得确认，这个确认弹窗的内容和逻辑就得根据当地法律重新做。还有些地方对密码强度有特殊要求，或者对某些功能的使用年龄有限制，这些都不是翻译能解决的，得改程序逻辑。
这里我要分享一个实用的思路。正规的本地化项目在动手之前，都会先做一个叫"国际化评估"或者"本地化可行性分析"的工作。这个环节做的事情说起来也简单，就是把软件的技术架构过一遍，看看哪些地方是写死的、哪些是预留了扩展口的。
举个具体的例子。我之前接触过一个电商系统的本地化项目，技术团队在评估后发现，商品价格显示的模块是按照"人民币-两位小数"写死的，要支持不同国家的货币显示就必须重构这个模块。而用户姓名地址输入这块，架构设计时就考虑过多语言支持，只需要把提示文字翻译一下就行。
这个评估过程大概是这样的：
| 评估维度 | 检查要点 | 常见问题 |
| 资源文件管理 | 文字是否存储在独立的资源文件中 | 文字硬编码在程序里，提取困难 |
| 字符处理 | 是否使用UTF-8编码，字体是否支持目标语言 | 缺少字体文件，编码转换出错 |
| 界面布局 | 控件宽度是否固定，文字长度变化时如何处理 | 固定宽度导致文字截断或溢出 |
| 数据格式 | 日期、时间、数字、货币的处理逻辑 | 硬编码的格式不符合当地习惯 |
| 功能适配 | 是否有针对特定市场的功能需求 | 缺少必要的功能调整或删减 |
做完这个评估，你就能清楚地知道哪些部分只需要翻译，哪些部分需要技术改造，预算和时间该怎么分配心里就有数了。
说完了理论，我再聊点实际操作中的体会。
很多客户一开始会觉得本地化就是翻译嘛，找个懂外语的就能做。结果做到一半发现这也要改那也要改，工期一拖再拖，预算也超支。所以我的建议是，在项目启动前，宁可多花点时间做技术评估，也不要匆匆忙忙开始翻。前期发现十个问题和做到一半发现十个问题，解决起来的成本能差出十倍去。
还有一点很重要，技术和翻译这两个环节不能完全割裂开。我见过有些团队是这样的：技术团队先把软件架构调整好，确认没问题了，再把文字交给翻译公司翻，翻完了再贴回去。这种流程不是不行，但效率往往不高。更好的做法是让译者早期就介入，了解软件的语境和限制条件。比如译者知道某个标签字符长度不能超过20个，那翻译时就会主动控制译文长度，而不是翻完了发现太长再删删改改。
另外就是测试环节。本地化做完了一定要在实际的目标环境中测试，而不仅仅是看看界面上的文字对不对。你得实际输入当地语言的文字试试看显示是否正常，使用当地的日期格式货币格式看看计算是否正确，请当地的用户试试操作流程顺不顺手。这些测试往往能发现很多意想不到的问题。
说到专业这个话题，我想提一下我们康茂峰的做法。我们内部有个说法：本地化不是简单的语言转换，而是跨文化的技术适配工程。
每次接到本地化项目，我们首先会和技术团队一起做那个前面提到的评估工作，把软件里所有可能涉及本地化的点都过一遍。然后根据评估结果，制定详细的项目方案，明确哪些部分需要技术改造、改造到什么程度，需要翻译的内容有多少、有什么特殊限制，时间怎么安排、风险点在哪里。
在执行过程中，技术团队和语言团队是并行工作的。技术团队负责代码调整和程序适配，语言团队负责翻译和文化适配。两个团队定期同步进度，遇到问题及时沟通。比如语言团队发现某段文字在目标语言中必须用敬语表达，会比原文长很多，这时候就要及时反馈给技术团队看界面能不能处理。
测试阶段我们也会参与，确保翻译内容在实际环境中能够正确显示和使用。有时候还会请目标市场的当地人员做一轮用户验收，看看有没有文化层面的问题。
这样做下来，项目推进会比较顺利，最终交付的质量也更有保障。虽然前期评估和协调会花一些时间精力，但整体算下来，其实比做到一半发现问题再返工要高效得多。
回到最初的问题：软件本地化翻译需不需要涉及代码层面的修改？
答案是看情况。如果你的软件在设计之初就考虑了国际化需求，架构预留了足够的扩展空间，那需要改动的地方可能就少一些。反之，如果软件是在国内使用的基础上开发出来的，很多地方都是按中文的使用习惯定制的，那需要调整的地方就会比较多。
说白了，本地化这件事没有统一的标准答案。每款软件的情况不同，每个目标市场的情况也不同。关键是在动手之前搞清楚自己的软件是什么情况，目标市场有什么特殊要求，然后针对性地制定方案。
希望这篇文章能帮你对本地化这件事有个更清楚的认识。如果你正在考虑做软件的本地化，不妨先花点时间评估一下自己的软件现状，这一步走对了，后面能少走很多弯路。
