多语言 WordPress 中的菜单和导航是结构化数据

导航不只是翻译后的文字

多语言菜单同时承担两项工作：它要以当前语言呈现可读标签，还要保留告诉 WordPress 每个项目应去向何处的结构。这个结构包括父子关系、每个项目背后的目标类型，以及项目应当解析的语言上下文。

如果你只翻译可见文字，菜单仍可能指向错误内容。标签可以正确，但目标却不对，尤其当菜单混合了页面、分类归档、自定义 URL，以及由插件或主题逻辑创建的项目时。

是什么让菜单成为结构化数据

WordPress 菜单不是一个扁平的字符串列表。每个项目除了标题之外还承载着含义。菜单可以编码层级关系，因此一个项目可以嵌套在另一个项目之下。它也可以编码目标类型，因此某个菜单项可能指向页面、分类术语归档、自定义 URL，或插件生成的端点。

这意味着翻译必须尊重关系，而不只是词语。如果父级项目切换了语言，而其子级项目没有映射到对应的语言内容，导航树就会变得不一致。结果不仅仅是措辞别扭，而是该语言版本的信息架构被破坏。

为什么目标映射很重要

同一个菜单标签在不同语言中可能代表不同的底层目标。翻译后的页面可能有不同的固定链接。某个分类归档可能在一种语言中存在，而在另一种语言中要等术语创建并关联后才会出现。自定义 URL 可能需要语言特定路径，而不是直接复制源语言链接。

这就是为什么多语言导航不能被当作简单的文本替换任务。菜单项必须在当前语言中解析到正确目标，否则用户会进入错误内容、回退语言，或陷入死路。就实际而言，菜单是路由的一部分，而不只是展示。

语言特定路由会改变菜单的形态

在多语言站点中，同一个概念性版块可能需要不同的 URL、不同的归档目标，或者根据语言版本采用不同的菜单层级。这是因为路由是具备语言感知的：在一种语言中有效的路径，在另一种语言中未必是规范路径。

当路由不同，菜单就必须反映这些差异，而不是把它们隐藏起来。一个指向源语言 URL 的翻译导航项，会造成可见语言与实际内容路径之间的不匹配。这种不匹配会影响可用性，也会让站点在运维上更难理解，因为菜单不再映射站点的语言结构。

把菜单当作字符串翻译时的常见失败模式

一种失败模式是层级漂移：父级项目被翻译了，但其子级没有映射到对应的语言内容，因此子菜单不再代表同一个概念分组。

另一种是目标漂移：标签被翻译了，但项目仍指向原始页面、分类归档或自定义 URL。第三种是插件项目漂移，即由插件拥有的数据生成的菜单项被复制了，却没有保留底层对象关系。在每种情况下，菜单看起来都完整，但导航逻辑却不一致。

当站点混合多种内容类型时，这些问题尤其明显。包含页面、分类归档和自定义链接的菜单，需要根据各自的路由行为分别处理每一类项目。

对 WordPress 站点所有者和实施者的运营影响

对于 WordPress 站点所有者来说，实际要做的决定是：多语言导航是作为一组具备语言感知的关系来管理，还是作为一组翻译后的标签来管理。第一种方式能在页面、归档和自定义链接之间保持一致性。第二种方式可能生成看似本地化、但行为并不像本地化导航的菜单。

对于开发者和实施者来说，关键的工程权衡在于简单性与正确性之间。简单的翻译流程起初更容易维护，但它无法保留菜单所依赖的结构性依赖关系。结构化方法需要更多关注项目映射和语言路由，但它能让导航树与每种语言的内容模型保持一致。