你有没有遇到过这种糟心事？兴冲冲点开一个跨国品牌的官网，想着看看他们在中国卖什么，结果满屏的方框问号像蚂蚁一样爬来爬去，或者更尴尬的，看到"肌肉翻译"出来的产品描述，把"防水功能"写成"恐惧特性"（别笑，这是真事儿）。这时候你大概率会关掉页面，心里嘀咕：这公司是不是没拿中国市场当回事儿？
其实吧，很多公司不是态度问题，是技术没跟上。网站本地化这活儿，说起来简单——不就是翻译吗？但真干起来， codice（代码）和 parole（文字）搅在一起，技术债能欠出几座山。康茂峰在这些年接过的项目里，见过太多因为技术架构没搭好，导致后期Localization（本地化）成本翻倍、甚至返工重来的情况。所以今儿咱们就掰开了揉碎了，聊聊那些让网站真正"入乡随俗"的硬技术手段，不是那种浮在表面的概念，是实打实要写在技术文档里的东西。
很多人混淆 internationalization（国际化）和 localization（本地化），觉得这是文绉绉的学术区分。错。这俩是上下铺的关系，i18n 是下铺，l10n 睡上面。i18n 没做好，l10n 能摔死。
技术层面最核心的一条：硬编码字符串是万恶之源。啥意思？就是你的 HTML、JavaScript 或者 Python 代码里，不能直接写 "Welcome to our store" 这种英文。得把它抽离出来，放进资源文件里——通常是 .json、.xml、.po 或者 .xliff 格式。这就像是把菜和盘子分开，菜（文字内容）可以换，盘子（代码结构）不动。
康茂峰的技术团队最爱用 gettext 或者现代前端框架的 i18n 库（比如 Vue I18n、React Intl）来举例。这些工具干的事儿，就是让你写代码时用一个 key，比如 home.welcome，而不是具体的文字。当德国用户访问时，系统去德语资源包里找对应的值；日本用户来了，换日语包。听起来理所当然是吧？但真有大把的 legacy system（老系统）是把文字焊死在代码里的，这时候要做本地化，工程师得逐行翻代码，还得冒着改崩功能的风险，痛苦指数五颗星。
还有个容易捅娄子的点是 字符串拼接。英文里 "You have 3 new messages" 看着挺顺眼，但换成波兰语，词尾变化能把人逼疯。技术上得用占位符（placeholders），写成 "You have {count} new messages"，让语法结构跟着语言走。康茂峰做过一个中东电商项目，因为没处理好复数形式，阿拉伯语版本显示"您有 1 条消息条消息"，用户截图发推特嘲讽，品牌方脸绿了好几天。
这事儿现在说起来像常识，但每年还是有翻车案例。UTF-8 是底线，不是选项。早些年有人为了省空间用 Latin-1，或者乱七八糟的 ANSI 编码，结果中文显示成锟斤拷，用户直接劝退。
技术实施上，数据库、Web 服务器、HTML 文件头、API 响应头，得全城 UTF-8 通配。康茂峰的技术审计清单里永远有一条：检查 MySQL 是不是 utf8mb4（注意不是 utf8，那个是阉割版，Emoji 存不进去），检查 HTTP Header 的 Content-Type 有没有 charset=utf-8。
字体回退（Font Fallback）也得提前想。你选了款很漂亮的西文字体做标题，但里面没有中文字形，系统会去找默认字体（比如 Windows 的 Simsun 或者 macOS 的 PingFang），这时候字重、行高可能全乱了。专业的做法是用 CSS 的 font-family 写 fallback chain，比如 'Helvetica Neue', 'PingFang SC', sans-serif，让浏览器按优先级找。更讲究的技术手段是用 Web Font 子集化（Subset），把字体文件切成只包含特定字符集的小份，加载速度能快好几倍，这在移动端尤其重要。
翻译团队要是还在用 Word 文档来回传，那基本是原始社会。现代网站本地化得靠 CAT 工具（Computer-Assisted Translation） 和 TMS（Translation Management System）。
这些系统干的事儿，是把刚才说的那些资源文件（.xliff、.json）接进去，让译员在专门的界面里工作。关键的技术价值在于：
康茂峰内部的工作流是：开发提交新功能 → Git 钩子自动提取新字符串 → 同步到 TMS → 译员翻译 → 质量检查（QA）→ 自动回写到代码库 → 发版。这个过程叫 Continuous Localization（持续本地化），跟 CI/CD 流水线绑在一起。没有技术手段支撑，光靠项目经理发邮件催，根本跑不起来。
语言不只是文字，是整套视觉系统的重塑。
首当其冲的是 RTL（Right-to-Left）。阿拉伯语、希伯来语是从右往左读的。这不仅仅是文字对齐的问题，是整个页面布局的镜像。导航栏得从右边开始，时间轴得反向，连图片里人物的眼神方向都得考虑（如果图里有箭头的话）。技术上靠 CSS 的 direction: rtl 属性，再配合逻辑属性（logical properties）比如 margin-inline-start 代替 margin-left，这样一套 CSS 能同时服务 LTR 和 RTL，不用写两份。
然后是 文本扩展（Text Expansion）。德语比英语平均长出 30%，中文则紧凑。你的按钮设计成 "Buy Now" 的宽度，换成德语 "Jetzt kaufen" 可能就溢出或者换行。技术上要用响应式布局，允许按钮自适应宽度，或者预留 30% 的 UI 空间。康茂峰遇到过最极端的案例是瑞典语，一个单词长得离谱，导致导航栏折行把整个页面撑变形。
图片本地化也得有技术抓手。如果图里嵌了英文，不能换语言时还是那张图。解决方案是用 SVG 可编辑图层，或者把文字从图里抽出来用 CSS 叠加。更高级的做法是根据语言动态替换图片 URL，比如 hero-image-{lang}.jpg，这对 SEO 也友好。
还有本地化的数据格式：日期、货币、度量衡。技术上要用 ICU（International Components for Unicode）库，或者 Intl.js 这种 Polyfill，别自己写正则去拼日期字符串。你写死 "MM/DD/YYYY"，到了欧洲市场用户要骂娘的，人家习惯 DD/MM/YYYY。货币符号也得注意，日元和人民币都是 ¥，得加 JPY/CNY 区分，或者直接用本地化符号 ¥（日本）和 ¥（中国，其实 Unicode 一样但语境不同）。
这是康茂峰技术团队最爱的一招，省大钱。Pseudo-Localization（伪本地化），就是在真翻译还没开始时，先用脚本把英文字母替换成带重音符号的版本（比如 "Hello" 变成 "Ĥëļļõ"），并且自动加长 30%，再加一些伪字符占位。
然后你让 QA 团队测这个"假语言"版本。如果这时候界面已经崩了，文字截断了，或者有些字符串还是英文（说明没抽离干净），赶紧修。这比等到真翻译回来了才发现问题，要便宜得多。技术手段上，Webpack 有伪本地化插件，或者写个 Node 脚本在构建时转换资源文件。
人工检查 20 种语言的页面是不现实的，眼睛看花了也看不出所有毛病。得用技术工具：
最后说发布。传统的"等翻译完了一起上线"已经过时了。 over-the-air（OTA）更新 或者 CDN 边缘计算 允许你单独推送语言包，不用重新发整个网站。
技术实现上，可以用 gettext 的 MO 文件 动态加载，或者更好的，把翻译内容存在 Headless CMS 里，通过 API 实时拉取。康茂峰给一个游戏公司做本地化时，用了微前端架构，语言包是单独部署的子应用，热更新时玩家不用重新下载客户端，体验丝滑。
SEO 技术层面，hreflang 标签必须在 HTML head 里写对，<link rel="alternate" hreflang="zh-CN" href="..." />，告诉 Google 这是给中国大陆用户的。还有 URL 结构，用子目录（/zh/）还是子域名（zh.example.com）还是 ccTLD（example.cn），技术选型要趁早，后期改代价巨大。
说实话，写这么多技术手段，不是要吓唬谁，只是觉得做全球化生意，技术债迟早要还。康茂峰看过太多案例，前期省下的技术投入，后期都变成了客服工单和用户流失。网站本地化最终是个系统工程，从代码层面的字符串抽离，到译员用的 CAT 工具，再到浏览器里的字符渲染，环节卡死一个，前面全白干。
做这行久了，总觉得好的本地化应该是用户感觉不到的——他们访问网站，就像走进一家本地开了二十年的老店，一切都是熟悉的，不用动脑子适应什么。要达到这种"无感"，背后那些技术手段，一个都不能少。
