Odoo 多语言网站为什么不是“加个语言切换器”就够了：默认语言、URL 前缀与 hreflang 主链路讲透

先说结论

Odoo 多语言网站的难点，从来不是“能不能翻译页面”，而是：

• 默认语言是谁；
• 哪些语言真的对这个网站开放；
• URL 里什么时候要带语言前缀；
• 搜索引擎该把哪些语言版本理解为互相关联页面；
• 用户进站时要不要按浏览器语言自动跳转。

所以 website 和 res_lang 这套实现，本质上不是 UI 小功能，而是一整套 多语言公开策略。

一个多语言网站是否稳定，关键不在翻译按钮，而在 URL、默认语言和公开语言边界是不是统一。

一、为什么 Odoo 要先定义“这个网站有哪些语言”，再谈翻译

在 website.models.website 里，语言不是全局启用完就结束，而是每个网站单独维护：

• language_ids
• default_lang_id
• auto_redirect_lang

这意味着 Odoo 的思路非常明确：

• 系统里安装了什么语言，是一回事；
• 当前网站真正开放哪些语言，是另一回事；
• 默认语言必须属于该网站的语言集合。

源码里的 onchange 甚至会在默认语言被移出时自动回退，避免网站处在“默认语言失效”的尴尬状态。

这看似小细节，实际上很关键。

因为多语言站最怕的不是翻得慢，而是 语言集合和默认语言失配，最后导致：

• 某些 URL 打不开；
• 某些页面找不到基准语言；
• 编辑器、翻译、前台路由都开始出现奇怪行为。

二、为什么 Odoo 不允许你随便停用仍被网站使用的语言

res_lang.write() 里有一条很硬的校验：

如果某个语言仍被网站 language_ids 使用，就不能直接停用。

这条限制的意义非常大。

它说明 Odoo 把网站语言当成“公开承诺的一部分”，不是后台随手开关的配置项。

因为一旦语言被停掉，影响的不只是后台数据字典，还包括：

• 前台语言切换入口；
• 某些带语言前缀的 URL；
• 已经被搜索引擎抓到的多语言页面；
• 已存在的翻译内容和访问路径。

所以 Odoo 宁可拦你一下，也不让你把一个还在公开站点中使用的语言突然抽掉。

这其实是在保护线上稳定性。

三、为什么 hreflang 不是简单把语言代码原样吐出去

res_lang._get_frontend() 里有一段非常有意思的逻辑：

• 它会根据当前网站真正开放的语言集来生成前台语言列表；
• 对 hreflang 做“缩写一份”的处理；
• 西班牙语还有 es_419 的特殊规则。

这说明 Odoo 很清楚：

系统语言代码 和 搜索引擎理解的 hreflang 信号，不是完全一回事。

比如：

• 某些语言组里，需要保留一个短码版本；
• 其他变体再用完整代码；
• 否则 hreflang 会既冗余又不规范。

这类细节如果自己手写，很容易做得一团糟。

Odoo 的实现虽然不花哨，但它抓住了重点：

多语言公开站，语言标识首先要稳定、可预测、对搜索引擎友好。

四、为什么默认语言版本的 URL 处理特别敏感

ir_http 里能看到好几处和默认语言有关的判断。

例如：

• 获取默认语言时，前台上下文直接取当前网站的 default_lang_id；
• 某些编辑上下文在当前语言就是默认语言时，会关闭翻译编辑模式；
• 去尾斜杠重定向时，如果当前语言不是默认语言，会把语言前缀补回路径里。

这些细节共同说明：

Odoo 把“默认语言页面”视为主版本，把“非默认语言页面”视为在主版本上衍生出来的公开路径。

这会影响很多事情：

• canonical 理解；
• URL 是否带语言前缀；
• 编辑器到底是在改原文还是改翻译；
• 用户切语言后是否应落到新路径。

如果默认语言没想清楚，后面所有语言切换行为都会变得混乱。

五、为什么自动语言跳转既方便又危险

website 上有 auto_redirect_lang 字段，这说明 Odoo 支持按用户语言环境做自动跳转。

很多团队会觉得这功能越激进越好，但实际上它是把双刃剑。

好处当然有：

• 海外访客首次进入时更自然；
• 降低语言选择成本；
• 让转化入口更贴近本地语言。

但风险也很明显：

• 分享链接时，用户看到的路径和你发出去的不一致；
• 搜索引擎、缓存、统计可能出现理解偏差；
• 某些明明想访问默认语言的人被自动带走。

所以自动跳转不是“开了就高级”，而是要看你的站点目标：

• 是品牌展示站？可以适度使用；
• 是文档站、教程站、SEO 内容站？就要更谨慎。

六、为什么多语言问题经常不是翻译质量，而是信息架构问题

实施里最常见的误区，是把多语言全部交给翻译团队，技术团队只负责“加语言按钮”。

但从源码看，真正决定稳定性的恰恰是这些架构项：

• 语言集合归谁管；
• 默认语言怎么定；
• URL 前缀策略是否一致；
• hreflang 是否规范；
• 自动跳转是否克制；
• 哪些页面真的准备好公开成第二语言版本。

换句话说，多语言站失败，很多时候不是翻得不好，而是：

站点从来没有先决定自己想用怎样的多语言公开模型。

七、给实施团队的实战建议

如果你在上 Odoo 多语言官网，建议按这个顺序决策：

1. 先定每个网站开放哪些语言；
2. 明确唯一默认语言；
3. 再考虑是否开启自动跳转；
4. 审核语言前缀和页面路径是否稳定；
5. 最后再做大规模翻译铺开。

同时要记住：

• 不要轻易停用还在网站中使用的语言；
• 不要把 hreflang 当附属功能；
• 不要默认所有页面都适合立即做多语言公开。

最后的结论

Odoo 多语言网站真正管理的不是“翻译文本”，而是：

• 网站对外开放哪些语言；
• 默认语言如何定义主版本；
• URL 如何表达不同语言版本；
• 搜索引擎如何理解这些版本之间的关系。

所以它绝不只是“加个语言切换器”。

真正的主链路是：

默认语言、公开语言集合、URL 前缀和 hreflang 一旦统一，多语言站点才会稳定。