WordPress 多语言站点用户与权限管理：译者角色创建与权限分配

引言：多语言团队里谁该改哪种语言

当你雇了 3 个兼职译者分别负责英、日、法版本，又不想让他们互相改乱对方的稿件时，默认管理员账号就不再合适。WordPress 的权限是”全站级别”的，一个编辑能改所有语言，这会带来内容被覆盖、未审稿件直接发布的风险。多语言站点的权限管理，核心是把”能看哪些语言”和”能发布哪些语言”拆开控制。

原理分析：WordPress 角色与多语言插件的叠加

WordPress 内置角色（Subscriber、Contributor、Author、Editor、Administrator）只管”文章层级”的权限，不区分语言。以 WPML 为例，它在用户编辑界面提供了”翻译者可以使用以下语言”勾选项，数据存于 wp_usermeta 的 wpml_capabilities 中。Polylang 本身不带译者角色，需要配合 Members 这类角色编辑器赋予 edit_posts 等能力。下表对比常见方案：

保姆级实操

1. WPML 创建译者：后台”用户→添加用户”，角色选” Translator（翻译者）”，保存后在用户编辑页勾选该译者允许翻译的语言，如只勾英语和日语。
2. 限制为草稿：在 WPML→设置→翻译管理中，将译者权限设为”可以编辑翻译但需审校发布”，这样译者保存的是待审状态。
3. Polylang 自定义角色：装 Members 插件，复制”投稿者”角色命名为”日文译者”，移除 publish_posts，仅保留 edit_posts 与 edit_ja 类自定义能力（需在代码中 add_cap）。
4. 审校账号：另建”多语言审校”角色，拥有 edit_others_posts 与 publish_posts，负责统一发布。
5. 代码赋予能力：在主题的 functions.php 中 add_role('lang_editor','语言编辑',['read'=>true,'edit_posts'=>true]);，再用 WP_User->add_cap('publish_ja_posts') 精细控制。

常见踩坑

• 案例：某外贸站把 5 个译者都设为 Editor，结果 A 译者误删了 B 已发布的德文页，且回收站未开启，无法恢复。应始终用最小权限原则。
• WPML 勾选语言后未点”更新用户”，权限不生效，必须保存两次。
• Polylang 不限制语言，仅靠角色编辑器会放开发布权限，需额外代码拦截。
• 多站点（Multisite）下角色是每站独立的，主站授权不会同步到子站。
• 译者账号若拥有 manage_options 会看到插件设置，存在安全隐患。

总结

多语言站点权限的本质是”角色 × 语言”二维控制。能用 WPML 内置 Translator 就用内置，不能用就用 Members + 自定义 capability 兜底，并始终遵循最小权限。上线前用 多语言站点内容审核与发布节奏 规划好各角色上线顺序，再用 多语言站点翻译协作流程 把分工固化到流程里。