设计相互连接的体验，而不是复制页面
不同语言的访问者应能到达功能等价的页面，同时每个版本可以调整词汇、案例与论证顺序。
优秀架构共享结构和数据，但不强迫所有语言使用完全相同的文案。
- 等价路由
- 共享组件
- 本地化内容
- 按语言生成元数据
- 切换语言时保留页面上下文
在翻译前建立内容模型
结构化内容将标题、摘要、章节、行动按钮、元数据与关联关系分开，便于发现差异并减少遗漏。
技术键可以保持一致，实际表达仍应自然符合本地语境。
等价不等于逐字翻译。不同版本应服务相同意图，并保持相同事实。
使用独立且可预测的 URL
每种语言应有稳定 URL。切换语言时应保留当前页面上下文，而不是总是返回首页。
规范链接、语言标注和站点地图必须与用户及搜索引擎实际可访问的路径一致。
- 清晰地区前缀
- 必要时使用本地化路径
- 页面之间建立映射
- 避免无法退出的强制识别
- 内部链接使用正确语言
用最长文案测试组件
英文中正常的菜单或按钮，在其他语言中可能溢出。应在小屏幕和高倍缩放下测试所有语言。
自定义控件也必须使用各语言正确表达状态，方便辅助技术识别。
- 导航
- 表单
- 错误提示
- 日期和数字
- 折叠面板
- 对话框
明确发布、审核与同步责任
技术无法自行保证所有语言长期一致。发布流程应明确谁负责撰写、调整、审核和批准。
按语言记录状态和复审日期，能够更好地管理内容差异。
- 内容负责人
- 语言审核
- 业务批准
- 发布规则
- 更新周期
根据本地搜索意图调整内容
搜索行为并不会逐字翻译。不同市场的标题、描述和主题重点可能不同。
不要为了堆叠关键词而创建大量近似重复页面。
- 本地搜索意图
- 不同标题与描述
- 一致的内部链接
- 准确的结构化数据
- 真正有用的内容
为更多语言留出扩展空间
良好架构能减少重建，但每种语言仍需要内容、审核、测试与持续负责。
应尽早规划本地化字段、格式、文字方向和地区变体。
- BCP 47 地区代码
- 日期和数字格式
- 文字方向
- 字体
- 搜索
- 运营支持
把多语言交付变成产品能力
只有把多语言视为系统能力和编辑责任，而非上线前最后一步翻译，体验才能长期保持一致。
这会改善一致性、可发现性与平台后续演进能力。