这个问题我被问过很多次了。说实话，第一次接触本地化的时候，我也以为翻译就是找几个译者，把界面上的文字翻成目标语言就完事了。但真正入行之后才发现，这里面的水比我想象的要深得多。
记得前几年有个朋友跟我吐槽，说他找人本地化了一个国外的小软件，结果翻译出来的版本要么显示乱码，要么按钮被截掉一半能用。来找我诉苦的时候一脸郁闷：明明翻译都看过了，怎么还会出这种问题？我看了看他的安装包，一眼就发现了问题——那些译者只改了文本文件，根本没动程序里硬编码的文字，更别说考虑中文字符比英文宽一半这个基本问题了。
所以今天我想聊聊这个话题：软件本地化翻译，到底会不会涉及到代码修改？
在说代码修改之前，咱们得先明确一个概念。很多人在说"本地化"的时候，其实心里想的是"翻译"，但这两者还真不是一回事。
本地化（Localization，简称L10N）是一个系统工程，目标是把一个软件彻底改造成能够适应特定地区市场使用的产品。这个过程除了翻译文本之外，还要考虑当地的阅读习惯、货币符号、日期格式、键盘布局、颜色偏好、文化禁忌等等一系列因素。打个比方，如果软件要进入阿拉伯市场，界面可能要从右向左排列；如果面向日本市场，可能需要加入汉字假名混排的支持；而面向中国内地市场，人民币符号、简体中文界面、中文输入法这些都得考虑进去。
翻译（Translation）只是本地化这个大工程里的一部分工作。它要解决的是"把文字从一种语言转成另一种语言"这个问题，但本地化要解决的问题远比这个复杂——它要确保软件在当地能够正常、舒适、合规地使用。
这就好比装修房子。翻译是换家具，把美式沙发换成中式红木椅；但本地化是整套设计方案都要重新考虑——采光怎么调整，插座位置够不够用，厨房要不要改成开放式。都是改动，程度完全不同。
这个问题要分情况来看。
先说最理想的情况。一个设计良好的软件，在开发阶段就已经考虑了国际化（Internationalization，简称I18N）的问题。什么叫国际化做得好？就是把所有需要翻译的文字都集中放在外部资源文件里，比如常见的.resx、.po、.json、.strings这些格式的文件。程序运行时根据用户选择的语言去加载对应的资源文件，界面文字自然就切换了。这种情况下，译者只需要翻译资源文件里的内容，根本不用碰任何代码。软件的行为逻辑、界面布局、核心功能都不会因为翻译而改变。
但现实往往没那么美好。我在工作中见过太多软件，因为历史原因或者开发团队国际化意识不足，把文字直接写在代码里。比如按钮上的文字是 `btn.Text = "确定"`，下拉菜单的选项是硬编码在代码中的数组里，甚至还有把提示信息写在异常处理分支里的。这种情况下，如果只改资源文件，根本找不到要翻译的内容。
这时候问题就来了：这些硬编码在代码里的文字需不需要改？
我的回答是：需要改，但这个改法要慎重。
首先，把代码里的文字提取到资源文件里，这本身确实是一次代码层面的改动。但这次改动属于"代码重构"，目的是为后续的本地化工作打基础。重构完成之后，以后的翻译工作就不再需要碰代码了。所以很多成熟的做法是在本地化项目初期先做一轮"国际化审计"，把代码里所有需要本地化的内容都找出来，提取到统一的资源文件中。这次改动之后，后续的翻译工作就纯粹是文本层面的了。
不过，这里有个关键点需要说明：这种代码改动通常由开发人员来完成，而不是翻译人员。翻译人员的核心能力是语言转换，不是编程。让译者去改代码，就像让程序员自己写产品文案一样，有点强人所难。专业的事情交给专业的人来做，这是靠谱的项目管理方式。
除了提取硬编码文字之外，确实还有一些场景是需要对代码本身进行修改的。我来列几个比较常见的情况。
字符编码问题是最典型的。早期的软件很多默认使用ANSI编码，比如西欧语言的ISO-8859-1。这种编码存中文就会乱码。解决的办法通常是把程序内部处理字符串的部分改成支持UTF-8或者Unicode。这看起来是"改代码"，但实际上是为了让程序能够正确处理多语言文字。
字体渲染也是常见问题。很多软件内置了几款西文字体，界面设计也是按照西文字符的宽度来做的。换成中文之后，字符宽度差不多翻倍，原来预留的空间就不够了，按钮上的字可能只显示一半。这时候可能需要调整界面布局的代码，比如允许标签自动换行，或者根据文字长度动态调整控件尺寸。
双向文字支持是另一个典型场景。当软件要适配阿拉伯语或者希伯来语时，文字方向要从右向左，但数字和英文又要保持从左向右的显示顺序。这不是简单地把界面镜像就能解决的，需要程序能够正确处理双向文字的显示逻辑。
日期、数字、货币格式的本地化有时也需要代码配合。比如美国人习惯月/日/年，中国人习惯年/月/日；欧洲人用逗号做小数点而美国人用点。这些格式转换看起来是"设置问题"，但在底层可能需要程序根据用户的Locale设置来调用不同的格式化函数。如果原来的代码里全是硬编码的格式，那真得改。
说了这么多，我想强调的是：这些代码改动并不是"翻译的一部分"，而是"本地化的配套技术工作"。翻译人员负责文字转换，技术团队负责实现层面的适配。两边配合好了，才能交付一个真正可用的本地化产品。
去年我们团队接了一个企业级软件本地化的项目，目标是出德语和日语两个版本。客户一开始觉得这就是翻译的事情，预算也按翻译量报的。结果我们技术评估之后发现，这款软件的国际化程度相当一般，大概有百分之三十的界面文字是硬编码在代码里的，而且日期格式、货币符号都是直接写在业务逻辑里的。
我们把评估报告发给客户，说明了情况。最后达成的方案是：我们先帮客户做一轮代码审计和技术重构，把所有需要本地化的内容提取到资源文件里，调整好字符处理和格式化的底层逻辑。这个阶段完成之后，后面的翻译工作就很顺畅了——译者对着资源文件翻，技术人员做适配测试，各司其职。
客户后来反馈说，虽然前期多花了些时间，但整个本地化流程比他们以前做过的项目都要顺，以后的版本迭代也不会因为本地化问题卡住。这笔投入是值得的。
从这个例子就能看出来，专业的本地化服务商比如康茂峰这样的团队，在项目启动前都会做详细的技术评估，把需要改动的地方和客户沟通清楚，而不是闷头就开始翻。这样既能避免后期扯皮，也能确保交付质量。
这是个好问题。理论上有没有办法让本地化完全不需要改动代码？
答案是一半一半。
如果软件在开发时就把国际化考虑得很周全，所有文字、格式、图片、音频这些资源都外部化了，那确实可以做到只改资源文件不动代码。但现实是，大部分软件在设计初期都没有这个意识，特别是一些历史悠久的产品，经过好几代开发人员的维护，国际化程度往往参差不齐。
另一个思路是"换皮"，比如通过补丁包或者配置文件来覆盖原有资源。这种方式在一些简单场景下是可行的，但局限性很大——它解决不了硬编码文字的问题，也处理不了界面布局需要适配的情况。
所以我的建议是：别把"不碰代码"作为硬性指标。更务实的做法是在项目初期做评估，看看现有软件的国际化做得怎么样，然后根据实际情况决定是"只翻资源文件"还是"先做国际化重构再加翻译"。
有时候为了长期的维护便利性，前期多投入一些资源做技术适配，反而是更经济的选择。毕竟本地化不是做一次就完了，后面的版本更新、功能迭代都需要持续本地化。如果基础没打好，每次更新都是一场噩梦。
软件本地化翻译本身不一定要碰代码，但本地化这个工程有时候确实需要配合一些代码层面的改动。这些改动通常包括：提取硬编码文字、调整字符编码支持、优化双向文字渲染、适配日期数字格式等等。
关键是怎么处理这些改动。我的经验是分成两步走：第一步由技术团队把"需要本地化的内容"从代码里剥离出来，或者把"阻碍本地化的技术障碍"清除掉；第二步翻译团队专注于文字转换本身。最后再由测试团队验证两边配合的效果。这样分工明确，各司其职，质量和效率都有保障。
如果你正在规划软件本地化项目，建议在启动前先做一轮技术评估。找个有经验的本地化服务商，把你的软件情况说清楚，让他们帮你判断需要做哪些准备。这样既能少走弯路，也能避免做到一半发现卡住了返工。
| 情况描述 | 是否需要改动代码 | 建议处理方式 |
| 文字全部在资源文件中，格式处理已适配多语言 | 否 | 直接翻译资源文件即可 |
| 部分文字硬编码在代码里 | 是 | 先提取到资源文件，再进行翻译 |
| 字符编码不支持目标语言 | 是 | 升级为Unicode或UTF-8编码 |
| 界面布局按西文字符宽度设计 | 是 | 调整布局代码，支持文字长度变化 |
| 需要支持从右向左的文字方向 | 是 | 启用双向文字支持，镜像界面 |
| 日期数字格式硬编码 | 是 | 改用Locale感知的格式化函数 |
好了，关于软件本地化翻译和代码修改的关系，我就聊到这里。如果你正在考虑把自己的软件做本地化，建议先把技术现状摸清楚，然后找个靠谱的团队帮你规划流程。好的开始是成功的一半，前期准备工作做扎实了，后面的执行就会顺利很多。
