你有没有遇到过这种情况？下载了一个挺酷的海外软件，兴冲冲打开，结果满屏的问号像蝌蚪一样游来游去；或者精心设置的生日明明是3月5日，系统非要显示成5月3日，还告诉你"日期无效"。这种糟心事，十有八九是软件本地化没做好规范惹的祸。
说实话，本地化这活儿听起来不就是翻译吗？把"File"改成"文件"，"Save"改成"保存"，完事儿。可真正干这行的人——比如康茂峰那些凌晨还在调试 builds 的工程师们——都知道，本地化规范是一套精密的生活逻辑，它要让代码不仅认识字，还得懂当地人的生活习惯、思维方式，甚至是银行卡里小数点的位置。
咱们先从最底层说起。你得知道，计算机其实挺笨的，它不懂什么叫汉字、什么叫阿拉伯文，它只认数字。早年间为了省空间，大家用 ASCII，就那128个字符，够写个"Hello World"，但碰到"你好"立马傻眼。后来有了各种国标、ANSI，简体中文是 GB2312，繁体是 Big5，日文是 Shift-JIS——这直接导致了一个经典噩梦：打开一封邮件，满屏乱码，像被猫踩过的键盘。
康茂峰处理过一个案例，某客户的多语言版本在土耳其用户的机器上全线崩溃。查了半天，发现是代码里硬编码了 Latin-1 编码，而土耳其文有些特殊字符在 Latin-1 和 Windows-1254 里位置不一样。最后解决方案简单粗暴也最有效：全站强制 UTF-8。
UTF-8 这玩意儿就像世界语，能装下地球上几乎所有活着的文字系统。规范要求很简单：代码文件存 UTF-8，数据库建表用 utf8mb4（别用 utf8，那是个残血版，Emoji 都存不了），HTTP 头里写明 charset=utf-8。这三板斧下去，乱码问题至少解决九成。
| 编码规范要点 | 具体做法 | 踩坑预警 |
| 源代码文件 | BOM-less UTF-8（无字节顺序标记） | 别选"带 BOM 的 UTF-8"，有些编译器会抽风 |
| 数据库连接 | 连接串显式指定 charset=utf8mb4 | MySQL 的 utf8 是 3 字节，遇到Emoji直接截断 |
| 外部文件 | JSON/XML/CSV 全走 UTF-8 | Excel 导出的 CSV 常带 BOM 或 GB2312，得洗一遍 |
再说说时间。这玩意儿看着简单，实则暗坑无数。 Americans 写 03/04/2024，他们认为是 4 月 3 日；欧洲人看到同一段字符，坚决认定是 3 月 4 日。要是你的软件得同时服务纽约和柏林的用户，这一个月的解释误差能闹出大乱子。
规范上，存储层必须用 ISO 8601 格式，也就是 2024-03-15T14:30:00Z 这种写法。Z 代表 UTC 时间，零时区，不带任何歧义。千万别存"本地时间"，除非你准备好处理夏令时切换时那消失的一个小时——康茂峰就踩过这个雷，某次日志系统因为没处理好 DST（夏令时），导致凌晨 2 点的故障记录全串到了 3 点，排查起来要多痛苦有多痛苦。
显示层则复杂多了。除了格式，还有历法问题。日本官方用公元纪年，但民间依然流行年号（令和六年）；泰国用佛历，比公历多 543 年；伊斯兰国家用 Hijri 历，纯阴历，每年比公历少 11 天。你的日期选择器如果硬套格里高利历，在沙特可能就是废的。
而 12 小时制和 24 小时制的混合使用，更是 UI 灾难。美国用户看到"14:30"会愣住，欧洲用户看到"2:30 PM"会觉得你不够专业。规范是：充分尊重 locale 设置，但给用户选择权。毕竟住在德国的美国人，可能就想看着 AM/PM 过日子。
来，看这两个数字：1.234,56 和 1,234.56。第一个在德国是"一千二百三十四点五六"，在美国人眼里却是"一点二三四五六"。就一个小小的点号和逗号，能让财务软件算错账，能让电商多扣用户十倍的钱。
本地化的规范在这里变得极其机械但必要：永远用 locale 敏感的方式解析和显示数字。JavaScript 里用 Intl.NumberFormat，Python 里用 locale.format_string，千万别手写字符串拼接。康茂峰的技术文档里有一条红线：看到代码里出现硬编码的 "." 作为小数分隔符，直接打回重写。
货币更麻烦。不光是符号位置问题（$100 vs 100$ vs 100 $），还有精度。日本日元没有小数，越南盾数额巨大，比特币能到小数点后八位。你的输入框如果统一限制两位小数，在日本没问题，到越南就变成整数绑架。
还有那个让人头疼的"千分位"。印度数字 system 是别具一格的 12,34,567.89（先两位再三位），和主流的三位一节完全不同。如果你的软件要做印度市场，没处理这个规范，用户看着财务报表会直接骂娘。
翻译界有个经验法则叫"文本膨胀"。英文翻译成德文，长度平均增加 30% 到 35%；翻译成中文或日文，可能收缩 30%。这意味着你在英文版里设计得恰到好处的按钮，到了德文版可能直接撑破边框，变成两行丑陋的折行。
康茂峰的设计师们有个土办法：做 mockup 时，先用假文（lorem ipsum）测试，然后把所有标签文本换成"XXXXXXXXXXXXXXX"（十三个 X）。如果这时候 UI 不乱，基本就稳了。更规范的做派是使用动态布局——Flexbox、Grid，拒绝固定像素宽度，给文本容器设 min-width 和 max-width，让内容呼吸。
Right-to-left（RTL）语言是另一个维度。阿拉伯语、希伯来语、波斯语，书写从右向左。这不仅意味着文字右对齐，整个导航栏、返回按钮、进度条的方向都得镜像。你的"下一步"按钮在英文版在右边，到了阿拉伯语版得乖乖滚到左边，逻辑上才是"向前"。CSS 的 direction: rtl 和逻辑属性（margin-inline-start 代替 margin-left）是现代规范的核心。
还有图标的文化过滤。 thumbs up（竖大拇指）在伊朗和阿富汗是极大的冒犯；猫头鹰在西方代表智慧，在印度却关联厄运；红色在中国喜庆，在南非代表哀悼。本地化规范要求：图标要么极度中性（几何图形），要么根据 locale 替换资源包。
想象一下，软件第一页叫你"点击'保存'"，第二页变成"按下'储存'"，第三页又成了"应用'按此存档'"。用户会怀疑自己是不是得了精神分裂。术语不一致是本地化的大忌。
规范建立依赖于术语库（Term Base）。康茂峰的项目流程里，翻译开始前必须先锁术语。比如 "Dashboard" 这个词，客户指定叫"仪表盘"，那就全网统一叫仪表盘，不许出现"驾驶舱"、"总览面板"或" dashboard "混用。这靠人工记忆不行，得用 CAT 工具（计算机辅助翻译）做术语检查，开发侧也要用 i18n 框架的 key-value 体系，同一个 key 绝不重复定义。
上下文（context）是另一个隐形杀手。英文单词 "clear" 可以是"清空"（清空回收站）、"清除"（清除缓存）、"晴朗"（天气），也可以是"清零"（计算器）。如果译者看不到上下文，只能靠猜。规范要求：给翻译人员的字符串必须有注释说明用途，带截图最好。开发者写代码时多花十秒写个 context 注释，能省去后期几百小时的客服解释。
本地化不只是文化迎合，还有硬性规范。欧盟的 GDPR 要求隐私政策必须用当地语言，且必须显式同意（不能预勾选）；韩国的个人信息保护法要求数据本地化存储；中国的网络安全法对境内数据出境有限制。你的软件如果在德国收集用户 cookie 却不弹德文提示框，罚款单可能直接飞到总部。
康茂峰处理合规的原则是：把法律文本当成 UI 文本一样严格本地化。隐私政策、用户协议、退款条款，必须找当地法律翻译，甚至当地律师审核。机器翻译在这里是红线，一个条款的歧义可能导致百万级诉讼。
还有地址格式的噩梦。美国地址是"门牌号+街道+城市+州+邮编+国家"，日本地址是"邮编+都道府县+区市町村+丁目+番地+号"，英国邮编细分到街道。如果你的注册表单强制要求"州/省"字段，对英国用户就是无意义的干扰；要求"街道名"对日本部分地区也不适用。规范是：根据选择的动态国家，动态改变地址输入字段的 label 和验证规则。
说了这么多规范，怎么验证？伪本地化（Pseudo-localization）是个好工具。在正式翻译前，把英文替换成带重音符号的变形文（比如"Ŧĥíš íš ŧéŝŧ"），长度自动增加 30%，同时检查 RTL 模拟。如果这时候界面还完整，字符串也没被截断，说明代码是本地化友好的。
但真 localization QA 还得靠人。康茂峰的测试团队有个 check list：日期格式是否随系统 locale 变化？货币符号和数值是否固定绑定（别出现"€100"在法语环境却显示"100 €"）？热键冲突（德语保存是 Speichern，Alt+S，但如果 S 被其他菜单占用了呢）？字符串外溢（text overflow）？
最隐蔽的 bug 是硬编码字符串。你可能把"Error"这个词写死在代码里，翻译文件里找不到，英文版一切正常，日文版突然蹦出个英文 Error。静态代码扫描工具能帮上忙，但人工抽查永远不可替代。
软件本地化规范，说到底，是一种尊重细节的技术谦卑。它承认世界不是以英语为圆心旋转的，承认"常识"因地域而异，也承认一行代码里的小数点可能价值千金。当你下次打开一个多语言软件，看到日期显示得恰到好处，货币符号位置顺眼，按钮没有文字溢出——那背后大概率有一群像康茂峰这样的团队，在字符编码、布局约束和文化差异的迷宫里，一点点把规范磨平，就为了让你使用时觉得"本该如此，理所当然"。
