说实话，第一次看到"网站本地化"这个词的时候，我也以为是找人把网页上的英文翻译成中文就行。后来真正接触这个行业才发现，这事儿远比想象中复杂。就像你把一道川菜原封不动端给不吃辣的外国人，他可能会礼貌地笑笑，但绝对不会动筷子。网站本地化也是这样——不是简单换个语言，而是得让整个网站在新的文化土壤里活起来。
康茂峰这几年处理过几百个本地化项目，从企业官网到电商平台，从医疗系统到游戏社区。每个项目背后都有一套技术体系在支撑。今天我就把这些技术拆开揉碎了讲给你听，不带那些让人头疼的术语，就像聊天一样。
翻译是把"Hello"变成"你好"，本地化是把整个打招呼的方式都换了——包括说话的语气、使用的货币、日期的写法，甚至是页面的布局。
举个例子，同样是显示日期，美国人习惯"12/25/2023"，欧洲人习惯"25.12.2023"，而日本人可能更喜欢"2023年12月25日"。如果你的网站硬是要用同一种格式显示给所有人看，用户体验肯定打折。这背后需要的技术，远不止是字典 lookup 那么简单。
现在我们聊聊最基础但也最容易踩坑的部分——内容管理系统，也就是 CMS。
一个好的 CMS 必须支持 i18n（国际化）和 L10n（本地化）。i18n 是 Internationalization 的缩写，因为首尾字母中间有18个字符；L10n 同理是 Localization。这两个概念经常被混着说，但技术实现上差别很大。
i18n 是打底工作，指的是在设计软件的时候就预留好支持多种语言的接口。就像建房子的时候提前埋好电线管道，而不是等装修完了再凿墙。具体来说，代码里不能硬编码任何特定语言的字符串，得把这些文本抽出来放到单独的资源文件里。
康茂峰的技术团队有个经验：很多老旧的 CMS 系统在这方面做得一塌糊涂。字符串散落在 HTML、JavaScript、后端代码的各个角落。等到要扩展新语言的时候，工程师得像侦探一样满世界找文本，漏掉一处就是满屏乱码。
现代的做法是用 gettext 或者 JSON 资源文件。gettext 是 Linux 世界的老牌方案，用 .po 和 .mo 文件管理翻译；JSON 更轻量，前端框架像 React、Vue 都喜欢用这种。关键是，这些文件得支持 占位符（placeholders）——比如 "Welcome, {username}!" 这种格式，而不是硬写成 "Welcome, John!"，否则中文环境下语法就会乱套。
说到乱码，就不得不提字符编码。这可是个老话题了，但直到现在还有人在这个坑里摔跤。
你的网页必须用 UTF-8 编码，没有商量的余地。UTF-8 能表示世界上几乎所有的文字，从 emoji 到繁体中文的罕见字都没问题。以前有人用 GB2312 或者 Latin-1，结果一遇到泰语或者阿拉伯语就全变成问号。
但编码只是开始。文本处理里还有一堆坑：
康茂峰处理过一个医疗平台的项目，系统默认用英文的逻辑处理所有语言。结果在导入俄语内容时，因为俄语名词有格的变化，搜索功能完全失效。后来重写检索引擎，引入了形态学分析，才解决这个问题。
技术不只是后端的事，前端同样重要。不同语言的阅读方向、文字长度、甚至文化符号都会影响 UI。
最极端的例子是阿拉伯语和希伯来语，它们从右向左读（RTL）。这意味着整个页面布局要水平翻转——导航栏从右边开始，Logo 放在右上角，连滚动条都在左侧。实现这个不能只靠 CSS 的 direction: rtl，还得考虑镜像对称的问题。比如表示"下一步"的箭头，在 RTL 环境下应该指向左边，而不是简单地文字翻转。
再聊聊字体。中文字体文件动辄十几兆，而英文字体可能只有几十KB。如果网页直接加载完整的中文字体包，用户等得花儿都谢了。这时候需要 字体子集化（Subset） 技术——只加载页面实际用到的那些汉字。康茂峰的技术方案里通常会配合 WebFontLoader，按需动态加载，而不是一次性打包。
还有图片里的文字。很多设计师喜欢在按钮或者 banner 上直接压文字，这对于本地化是灾难。每次更新语言都得重新出图。正确的做法是图片和文字分离，用 CSS 把文字浮在图片上方，或者使用 SVG 格式，让文字保持可编辑性。
| 技术点 | 常见坑 | 解决方案 |
| 文本长度变化 | 德语比英语长30-35% | 弹性布局，预留 40% 扩展空间 |
| RTL 语言 | CSS 翻转后图标方向错误 | 使用逻辑属性（inline-start/end） |
| 垂直书写 | 日文竖排支持不足 | writing-mode: vertical-rl |
| 字体加载 | 中文 FOIT/FOUT 闪烁 | font-display: swap + 预加载 |
网站做出来是给人看的，也是给搜索引擎看的。本地化 SEO 技术往往被忽视，但可能是最直接影响流量的环节。
首先要解决的是 hreflang 标签。这是告诉 Google："这个页面有中文版、英文版、日文版，它们之间是什么关系。"写法看起来简单：
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/" />
但这里陷阱很多。语言代码必须用 IETF 标准，比如简体中文是 zh-CN，繁体是 zh-TW，不能自己造。而且必须双向引用——中文版要指向英文版，英文版也要回指中文版，否则搜索引擎会认为这是单向链接而非等价替换。
URL 结构也有讲究。有人用子域名（cn.example.com），有人用子目录（example.com/cn/），还有人用顶级域名（example.cn）。技术上各有利弊，但关键是保持一致性，并且确保每个语言版本都能被爬虫独立索引。
康茂峰遇到过的情况是，客户之前用 cookie 或者 IP 判断来切换语言，结果搜索引擎只抓到了英文版，其他语言完全没收录。后来改成独立 URL 加语言选择器，流量直接翻了倍。
技术实现完了，怎么知道对不对？这时候需要 伪本地化（Pseudolocalization） 技术。
简单来说，就是在正式翻译之前，先用程序生成一段"假语言"——比如把 "Hello World" 变成 "[Ħḗḻḻǿ Ẇǿřŀđ]"。这样做有几个好处：一眼就能看出还有哪些字符串是硬编码没抽出来的；能看出文本扩展后布局会不会崩；还能检查有没有出现截断。
更进一步的是 本地化测试（L10n Testing）。这不仅是检查翻译对不对，还要检查：
自动化测试工具比如 Selenium 可以模拟不同语言环境的浏览器设置，但真正的 cultural testing 还是需要母语测试员。康茂峰的流程里，每个语言版本上线前必须由当地母语者走查一遍，这是机器替代不了的。
最后聊聊效率工具。如果你还在用邮件把 Excel 表格发来发去做翻译，那效率太低了。
现代本地化依赖 TMS（Translation Management System）。这是一个中央仓库，连接着代码仓库、翻译人员和发布系统。开发人员提交新代码，TMS 自动提取需要翻译的字符串，推送给译员，译完后再自动合并回去。
关键的技术组件包括：
翻译记忆库（TM）：以前翻过的句子自动存起来，遇到相似内容会提示复用。不仅能省钱，还能保证术语一致性。比如你的产品名"CloudSync"在中文版必须统一叫"云同步"，不能有的地方叫"云端同步"。
术语库（Termbase）：专门管理专业术语。医疗设备不能叫"机器"得叫"设备"，法律合同有固定的套话。TMS 能实时检查译员有没有用错词。
机器翻译后编辑（MTPE）：先用神经机器翻译（NMT）打个底，然后人工校对。现在的深度学习翻译质量已经很高，对于大批量的非创意内容（比如用户手册、产品描述），这种 hybrid 模式能把速度提升 3-5 倍。
API 集成也很重要。理想情况下，CMS、Git、TMS、发布系统之间应该全自动化。开发 push 代码 → webhook 触发提取 → 译员在 CAT 工具里翻译 → QA 检查 → 自动合并到 release branch → 部署上线。康茂峰给大型客户搭建的 pipeline，从代码提交到多语言网站上线可以控制在24小时内。
不过技术再先进，人的判断还是核心。机器分不清 "get" 在 software 里该译作"获取"还是"理解"，也判断不了营销文案的语感。技术是放大器，但方向盘得靠人把握。
写到这里，我突然想起前几天看到的一个数据：没做本地化的网站，转化率平均只有做好本地化的网站的 1/10。这中间的差距，往往就是这些技术细节堆积起来的。从字符编码到 SEO 标签，从弹性布局到自动化工作流，每一环都不起眼，但缺了哪一环，整个链条就会咔哒一声卡住。
做网站本地化这件事，本质上是在技术客观性和文化主观性之间找平衡。代码是死的，但用代码呈现的内容必须活起来。康茂峰这些年的体会是：最好的本地化技术，是让最终用户根本感觉不到"这是翻译过来的网站"——它看起来、用起来，就像本来就是为本地人生的一样。
