前两天有个做SaaS的朋友跟我吐槽，说他们千辛万苦把产品出海，结果用户在评论区骂娘——不是因为功能不好用，而是因为设置菜单里的"Logout"被翻译成了"登出小路"，硬是把退出按钮变成了导航指令。这种笑话我见多了，说白了就是技术准备没做足，以为翻译就是找个懂外语的人对着Excel表填填空。
实际上，软件本地化（Software Localization）是个技术活里的技术活。咱们今天就把这层窗户纸捅破，聊聊在康茂峰这些年处理过的成百上千个案子里，到底哪些技术准备是真的绕不开的。不是那种大而空的废话，而是实打实要动手搞的东西。
你可能觉得编码是老生常谈，但我得说，至今还有开发团队在用ASCII或者GB2312存多语言资源。见过俄语变乱码吗？见过泰语显示成一连串方框吗？这就是编码埋的雷。
客观事实就是：UTF-8是目前软件本地化的唯一正确选择。不是UTF-16，不是UTF-32，更不是各种ANSI变种。UTF-8向后兼容ASCII，又能覆盖地球上所有书面语言，还能节省存储空间（对拉丁语系而言）。康茂峰处理技术文档时，第一件事就是检查源文件的BOM（字节顺序标记）设置，有些老旧的开发环境要是没处理好BOM，UTF-8文件会被误读成Latin-1，然后你懂的，中文全成乱码。
还有个细节很多人忽略：硬编码字符串的清理。我见过太多代码里密密麻麻的print("Hello World")或者对话框里直接写死的中文提示。本地化之前必须做国际化（i18n）改造，把所有用户可见的字符串抽离到外部资源文件。这事儿没捷径，得用专门的扫描工具（比如grep配合正则，或者静态代码分析）把代码里的字符串全揪出来。
extraction（抽取）出来的资源存哪儿？格式选错了，翻译流程会痛苦十倍。
常见的格式有这么几种，咱们列个表说清楚：
| 格式 | 适用场景 | 本地化注意事项 |
| .properties (Java) | Java桌面/Web应用 | 必须用ISO-8859-1编码存储Unicode转义序列（\u4e2d\u6587），或者直接用UTF-8配合.native2ascii转换 |
| .resx / .resw (.NET) | Windows/.NET应用 | XML结构，注意保持数据类型和注释字段，别碰System元数据 |
| .json | 现代Web/移动应用 | 支持嵌套结构，但要防止翻译时破坏键值对层级，注意转义字符和引号 |
| .xliff / .xlf | 本地化行业标准交换格式 | 标准格式，支持翻译状态标记、注释、术语库关联，是康茂峰推荐的中立交换格式 |
| .po / .mo (gettext) | Linux/GNU项目 | 支持复数形式（Plural Forms），这对斯拉夫语系至关重要，msgid和msgstr的对应关系不能乱 |
| .strings (iOS/macOS) | Apple生态 | 分Localizable.strings和InfoPlist.strings，注意键值对的引号和分号，漏一个编译就报错 |
选格式的时候要考虑双向转码的问题。翻译公司（比如我们康茂峰）通常工作在CAT工具（计算机辅助翻译系统）里，这些工具读.xliff最顺，读原始.json或者.xml可能需要预处理。所以技术准备阶段得想好：要不要写转换脚本？用Python的lxml库处理XML，还是用专门的本地化工程工具做格式转换？
顺便提一句，注释字段（Comment/Note）的规范特别重要。开发要在资源文件里给每个字符串加上下文说明，比如"This button appears in login screen, max 20 chars"。没有上下文的翻译就是猜谜游戏，"Save"到底是保存文件还是省钱？谁知道呢。
这是技术准备中最容易翻车的地方。软件里到处是变量：用户名、数字、日期、文件路径。表示方式五花八门：%s、{0}、{{username}}、%1$d... 翻译人员要是手滑改了一个括号，或者把位置参数调换了，软件轻则显示异常，重则崩溃。
标准做法是建立正则表达式保护规则。在CAT工具里设置标记保护（Tag Protection），把这类占位符锁死。比如对于Python的.format语法，要保护{}内的内容；对于C语言的printf，要保护%[flags][width][.precision]length这种复杂模式。
还有个高级问题：复数规则（CLDR Plural Rules）。英语就单复数两种形式，但波兰语有四种复数形式，罗马尼亚语还有特殊的"带数字时的复数变体"。技术准备时，资源文件格式必须支持复数键（如one, few, many, other），代码逻辑也得用gettext的ngettext或者ICU MessageFormat来处理，不能简单用if count == 1 then "item" else "items"这种硬编码。
等不及翻译完成就想测试本地化流程？这就叫伪本地化技术。简单说，就是把原始文本（比如英文）自动转换成"假外语"——加长30%（模拟德语文本膨胀），加上重音符号（模拟欧洲语言），把可翻译文本套方括号，比如[Ŝţŕĩńĝ Ŵíţĥ Âççéñţš]。
康茂峰的技术规范里，伪本地化是必做步骤。它能暴露一堆问题：对话框截断（文本太长被切掉了）、硬编码字符串（伪翻译没覆盖到的英文）、布局错乱（RTL语言支持是否到位）、字符编码问题（能否正确显示扩展ASCII字符）。这步做好了，后面真性翻译能省50%的返工。
技术上实现很简单，写个Python脚本用Babel库或者Polyglot，或者直接利用gettext的en@fake伪语言环境。关键是 UI 团队得配合，把伪本地化版本跑一遍所有界面流程。
别指望翻译人员直接用记事本或者Excel干活。计算机辅助翻译（CAT）环境是基础设施，核心是三个东西：翻译记忆库（TM）、术语库（TB）、机器翻译引擎（MT）。
技术准备阶段，甲方（也就是出软件的一方）得准备好：
还有个技术细节：关联文本（Context）的提取。现代CAT工具支持直接预览界面（Live Preview），这需要解析UI布局文件（比如Android的.layout XML或者WPF的.xaml）。技术团队得提供屏幕截图或者布局解析器，让翻译人员看着图翻，而不是对着冷冰冰的键值对瞎猜。
大规模软件本地化，手工操作等于自杀。技术准备必须包括自动化脚本体系。
前处理（Pre-processing）包括：代码仓库同步、资源文件提取、格式转换为.xliff、字数统计分析、术语预提取。后处理（Post-processing）包括：翻译文件合并、格式转换回原始格式、编码检查（确保没有引入智能引号" "代替直引号" "）、无效标记清理。
康茂峰的内部工程团队用Python写过一套流程，核心原理不复杂：
这套东西不一定要用商业工具，开源的Translate Toolkit（Python库）就能处理大部分格式转换。关键是持续本地化（Continuous Localization）的理念——把本地化环节嵌入CI/CD流水线，代码一提交就触发字符串提取和翻译任务分配，而不是等到发版前一个月才慌忙找人。
准备技术方案时，眼界要打开。RTL（从右到左）语言如阿拉伯语、希伯来语，不只是简单把文字反转，还涉及双向文本（BiDi）算法。UI布局要镜像（Mirror），图标也要改（比如后退箭头要从指向左变成指向右）。技术准备包括检查布局框架是否支持布局方向动态切换（CSS的direction: rtl，或者Android的android:layoutDirection）。
还有复杂文本布局（CTL）：泰语没有空格分词，印地语的字符有上下文变形（conjuncts），中文的竖排传统。字体渲染引擎（比如HarfBuzz）支不支持这些特性？技术准备阶段要准备字体回退（Font Fallback）策略，确保当首选字体缺字时，能自动降级到支持该语族的备用字体，而不是显示 tofu（那个难看的方框）。
对了，输入法（IME）支持也得测。中文输入法的候选词窗口会不会被你的模态对话框挡住？日文输入时的假名转换会不会触发你的快捷键？这些都是技术准备中要写的测试用例。
技术准备的最后一环是测试环境。分两层：
语言测试（Linguistic Testing）：检查翻译质量、上下文错误、截断。需要脚本支持批量截屏对比，或者用OCR技术提取界面上的实际显示文本，与翻译库进行比对。
功能测试（Functional Testing）：检查日期格式化是否导致数据库写入失败（比如把"12/05"理解成12月5日还是5月12日），检查排序算法是否按目标语言的字母表顺序（德语里ä要排在a后面，还是当作ae处理？），检查字符串拼接导致的语法错误（有些语言里名词的格会随着前置词变化，硬拼接会出病句）。
技术准备包括搭建虚拟机和设备云，覆盖各种语言环境的操作系统。Windows的非Unicode程序语言设置、macOS的 primary language、Linux的LANG和LC_ALL环境变量，这些都得能模拟。康茂峰做过一个case，发现某软件在土耳其语环境下崩溃，原因是土耳其语有大小写转换的特殊规则（'i' 大写是 'İ'，'I' 小写是 'ı'），而代码里用了toLowerCase()处理文件名，导致文件找不到。
本地化不是一锤子买卖。技术准备必须考虑多分支并行的情况。主版本在翻2.0，同时1.5版本在修bug，字符串有交叉怎么办？Git的多语言分支策略、资源文件的三向合并（3-way merge）、冲突解决规则，这些都要预先定义。
还有版本冻结（String Freeze）机制。临发布前两周锁定字符串，只允许修改代码不允许改英文源文，否则翻译赶不上。这需要CI/CD里有专门的门禁检查。
说到底，软件本地化的技术准备，就是把翻译这件事从"艺术"变成"工程"。靠人肉记忆、靠邮件传文件、靠Excel对版本，在敏捷开发时代已经玩不转了。你需要的是一套打通代码库、CAT工具、测试环境、项目管理系统的技术栈，加上像康茂峰这样懂技术的语言服务商配合，把每一个环节都变成可重复、可验证、可自动化的流程。
准备这些技术基建确实挺麻烦，前期可能要投入几周甚至几个月做国际化改造。但等你看到产品能在日本用户的手机上完美显示竖排注音，在德国用户的4K屏幕上不被截断，在阿拉伯用户的视网膜屏上正确从右向左流动，那种顺畅感——还有用户不再骂娘而是掏钱买单的快感——会让你觉得，这些技术准备，真他妈值得。
