一个网站，数十种语言：电商国际化实践

电商网站的国际化一旦超出几种语言，就会暴露原本为单一语言区域构建的代码中隐含的各种假设。字符串提取、按语言区域格式化、从右到左布局调整等加固工作，原理上已很清楚，实际操作却十分繁琐。人们较少理解的是，一系列决策的先后顺序，会决定最终结果是真正本地化的体验，还是仅仅使用正确文字呈现、却明显带有机器翻译痕迹的表面文章。

为面向数十个语言区域的网站完成这一过程后，最突出的发现是：技术实现只是问题中较小的一部分。翻译管道、URL 架构和 hreflang 配置都是可解决的工程问题。多数本地化项目做得不足的是文化适配：理解什么样的产品页在日本、德国或巴西具有可信度。这项工作无法完全自动化，所需知识的获取成本也很高。

URL 结构：后期最难更改的决策

多语言网站首先要决定 URL 结构，这也是最难回头的决策。常见的三种方式是：每个语言区域使用独立域名（example.de、example.fr）、独立子域名（de.example.com、fr.example.com），或独立子目录（example.com/de/、example.com/fr/）。它们对 SEO 权重、部署复杂性和运营开销的影响各不相同。

独立域名的用户体验最清晰，也允许各市场完全独立托管，但会分散域名权重：多年积累的 example.com 反向链接带来的效益不会直接传递给 example.de。对于已有稳定自然流量的网站，这是显著成本。对于刚起步、面向将本地顶级域名视为信任信号的市场的网站，权衡则不同。

对于希望集中 SEO 权重的网站，按语言区域划分子目录是最常被推荐的方法。如果没有充分理由在域名层面分离市场，它通常也是电商网站的正确选择。代价是所有语言区域共享基础设施，影响某个语言版本的部署可能影响所有版本。对多数团队而言，这是可接受的运营约束。

最重要的是尽早有意识地做出选择，并充分了解 SEO 和运营影响。网站积累了外部链接并被搜索引擎索引后，更改 URL 结构的成本很高，因此即使原有方案的弱点已经显现，它通常仍会长期沿用。

翻译管道

覆盖数十种语言的翻译管道包含三项常被混为一谈的活动：先用机器翻译建立初稿，再由人工审校纠错并调整语气，最后在源内容变化时持续维护。每项活动的成本结构和质量上限都不同。

机器翻译已足以为多数西欧语言提供可靠的起点；对于日语、中文及敬语体系复杂的语言，也能提供可用但局限更多的初稿。无论输出质量如何，都需要审校：并非机器翻译总是出错，而是它经常产生技术上正确、语气却不合适的文字。机器翻译的法律文案读起来仍像机器翻译，这会削弱本地化内容本应建立的可信度。

在内容更新时维护翻译，是市场扩张计划经常低估的运营挑战。一种语言的源内容更新，就会让所有其他语言版本产生待更新的翻译。如果不明确追踪哪些译文仍与源内容一致，过期内容就会悄然积累，直到非英语市场的用户看到仍用去年价格的产品页，或被描述为可用的已停用功能。

无论采用翻译管理系统、基于普通文件的方案，还是数据库驱动的内容管理层，工具选择都应取决于维护流程，而非初次翻译量。普通文件方案初期搭建很快，但如果缺少识别翻译积压和确定处理优先级的工具，规模扩大后就会成为负担。

hreflang：实现方法与常见错误

hreflang 标签告诉搜索引擎，应向哪些用户展示页面的哪个语言和区域版本。文档中的实现看起来很简单：在每个页面添加一组 <link rel="alternate"> 标签，每个语言区域一个，并使用正确的语言代码（ISO 639-1 语言代码，可选择在后面加上 ISO 3166-1 alpha-2 区域代码，例如 de 或 de-AT）。实际中，出错方式很多，hreflang 实现有误反而十分常见。

最常见的错误是 hreflang 集合不完整。每个语言版本都必须在 hreflang 标签中引用所有其他版本，也包括自身。如果共有八个语言区域，而页面只列出七个，缺失的那对页面就不再互相引用，Google 会忽略没有双向引用的页面之间的 hreflang 注释。从统一的受支持语言区域列表生成这些标签可以避免问题，但前提是在增删语言区域时准确维护列表。

第二类常见错误是 hreflang 引用不匹配：英文页的标签指向 /de/product-name，但德文页的规范网址实际是 /de/produktname。在重视本地语言关键词的市场，为 SEO 翻译 slug 是合理的；如果翻译后未更新 hreflang 引用，就会出现这种问题。规模化时，只有自动审计才能可靠发现这些差异：抓取网站，验证每个 hreflang 标签都指向真实的规范网址。

x-default 的 hreflang 值常被误解。它不是“默认语言”，而是“面向不匹配任何指定语言区域标签的用户”。多数网站应将其指向主语言版本；对于设有语言区域选择页或按地理位置重定向的网站，指向其他页面也可能是正确的。

RTL：不只是翻转布局

从右到左的语言支持，涵盖阿拉伯语、希伯来语、波斯语（法尔西语）、乌尔都语以及其他从右到左的文字系统。多数项目将其视为 CSS 问题：给根元素添加 dir="rtl"、反转 flex 方向、镜像内外边距，就认为完成了。实际上，RTL 支持会暴露许多在布局方向改变前看不到的假设。

最常被忽略的是图标方向。导航箭头、进度指示器，以及指向左或右的方向图标都具有语义，应该在 RTL 环境中镜像：LTR 中指向左的“返回”箭头，在 RTL 中应指向右。CSS 的 transform: scaleX(-1) 可以实现翻转，但仍需逐一审查界面中的方向图标，确保只在适当时镜像。

数字、电话号码和邮政编码即使出现在 RTL 文本中，也仍从左到右读取，不应镜像翻转。由于 Unicode 双向算法将数字及其分隔符视为弱类型或中性字符，它们的位置取决于周围文本，因此这些值往往需要隔离处理，例如使用 <bdi> 或 dir="ltr"。在同一文本块中混排 LTR 和 RTL 内容，例如含有型号的产品描述，需要显式使用 Unicode 双向控制，或谨慎设置 HTML dir 属性，避免浏览器的双向文本算法产生混乱的显示顺序。

超越翻译的文化适配

本地化与翻译不是同一项工作。翻译转换文字，本地化转换含义，因此需要理解文化语境如何影响特定受众对信息的解读。

商业上影响最大的差异体现在信任信号。让产品页显得可信的因素因市场而异：德国客户重视认证标志和技术规格，日本客户重视品牌声誉与包装质量，美国客户重视他人认可的证据，以及清晰可见的退货政策。即使译文质量相同，在一个市场转化良好的产品页，在另一个市场也可能表现不佳，因为布局和重点强调了不适合当地的信任信号。

支付方式也是一个文化维度，却经常被视为技术集成问题，而非本地化问题。在德国，银行转账（Überweisung）和 SEPA 直接借记仍是重要的支付途径；在日本，便利店付款仍有大量用户使用。在这些市场只提供信用卡和 PayPal，从翻译角度看不算本地化失败，但从实际角度看，就是没有满足当地客户需求。

坦率地说，多数多语言电商网站只是翻译了文字，并未真正本地化。文字使用了正确的语言，体验却没有适配市场。对于要与本土企业竞争的公司，翻译与本地化之间的差距，正是自然流量转化率出现差异的原因。