多语言项目最容易在首版演示时看起来正常：中文和英文都能切换。内容一更新、语言一增加，才发现链接跳回默认语言、产品字段漏翻、缓存串页。
稳定的国际化需要在架构阶段处理语言、地区与内容关系，不能把翻译当成前端末尾的一层文本替换。
01 区分语言与地区
英语可能面向美国、英国或全球，内容、价格、法规和联系方式不一定相同。先定义语言—地区矩阵和默认策略。
不要仅根据IP强制跳转。可推荐地区，同时保留用户选择和可分享URL。
02 每个版本要有稳定URL
使用子目录、子域名或地区域名时保持一致，语言切换应跳到当前内容对应版本。
不要把语言只存在Cookie或JavaScript状态中，否则搜索和分享难以区分。
多语言开发关键层
| 层面 | 需要设计 | 常见故障 |
|---|---|---|
| 路由 | 语言/地区路径和默认规则 | 切换后回首页、URL混乱 |
| 内容模型 | 哪些字段共用、哪些独立 | 一段文本覆盖所有市场 |
| 翻译资源 | 键名、上下文、复数和变量 | 拼接句子导致语序错误 |
| 格式 | 日期、数字、货币、单位、地址 | 只翻文字，格式仍是中国 |
| SEO | hreflang、canonical、Sitemap | 语言版本互相规范化 |
| 缓存 | 按语言和地区隔离 | 用户看到上一位用户语言 |
| 回退 | 缺译时显示什么 | 页面空白或语言混杂 |
03 翻译键需要上下文
同一个中文“提交”在不同场景可能是Submit、Send或Place order。键名应描述用途，而不是只用text1。
避免把句子拆成多个片段拼接，复数、性别和语序在其他语言中可能不同。
04 CMS要支持本地化工作流
编辑需要看到翻译状态、来源版本、负责人、更新时间和预览。某语言缺失时应有明确回退策略。
页面结构可能按市场不同，系统应允许必要差异，而不是强制逐字段一一对应。
05 SEO信号保持一致
每种语言有独立标题和描述，hreflang互相指向，canonical通常指向当前语言的规范URL。
Sitemap、内部链接和结构化数据都要输出对应语言，不能只有正文变化。
06 测试语言长度、方向和真实市场
英文可能比中文长，德语更长，阿拉伯语涉及从右到左。测试按钮、导航、表格、邮件和PDF。
还要验证时区、货币、搜索、表单、地址和客服路由，翻译正确不代表业务本地化完成。
常见问题
多语言网站可以共用一个CMS吗？
可以，前提是内容模型、权限、翻译状态和市场差异设计清楚。
缺少翻译时直接显示英文可以吗？
可以作为明确回退，但应避免同一页面语言混杂，并监控缺译。
语言切换要记住用户选择吗？
可以，同时URL应稳定，用户仍能主动改变。
hreflang由前端还是SEO负责？
开发负责正确输出，SEO和内容团队负责语言—地区映射，需共同验证。
机器翻译能直接发布吗？
低风险内容可辅助，但品牌、技术、法律和高价值页面应审校。
链接复制成功
