本文约 3,143 字，预计阅读 8 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：装了个好插件，可惜只有英文
这是国内站长最高频的处境：某个小众但好用的插件没有中文包，或者官方中文包只翻了 60%，剩下的英文混在中文界面里特别别扭。自己下载源码改？下次插件一升级，改动全被覆盖。找翻译平台提交？周期长，还不一定有人接。
Loco Translate 就是为这个场景存在的：它是 WordPress 官方目录里一款免费的翻译文件编辑器，能在后台直接看到插件里所有待翻译的字符串，逐条填中文，保存后自动生成 .mo 并生效，全程不碰 FTP、不改源码。但要真正用稳，必须搞懂”翻译文件该放哪”——这一步做错，轻则升级丢翻译，重则整站后台变成半中半英。
原理分析：三个语言目录，优先级完全不同
WordPress 加载插件翻译时，查找顺序是有讲究的。Loco Translate 把目录分成三类，理解它们的差别就理解了 80% 的坑：
| 位置 | 典型路径 | 特点 |
|---|---|---|
| 系统目录（System） | wp-content/languages/plugins/{domain}-zh_CN.mo |
WordPress 官方语言包、Loco 的”系统”位置；插件升级不会覆盖，优先级最高，推荐 |
| 自定义/作者目录（Custom / Author） | wp-content/plugins/{plugin}/languages/{domain}-zh_CN.mo |
插件作者自带的语言包；插件一升级就可能被覆盖 |
| 第三方目录（Third party） | wp-content/languages/loco/plugins/{domain}-zh_CN.po |
Loco 自己管理的目录，实际生效文件仍在系统目录 |
关键点：Loco Translate 默认会把新建的语言文件写到系统目录。你在后台看到”Custom”位置时，一定要主动改成系统位置再保存，否则翻译跟着插件目录走，升级即丢。
另一件事是 PO 文件的结构。一个条目长这样：
#: includes/class-admin.php:42
msgid "Export Orders"
msgstr "导出订单"
msgid 是源码里的英文原文，msgstr 是你的译文，#: 是它在源码中的位置。Loco 的 Sync（同步） 按钮做的就是：重新扫描源码里的字符串，和 POT 模板比对，把新增的加进来、把源码里已删除的标记为”废弃”。插件升级后第一件事就是点 Sync。
保姆级实操
第一步：安装并确认文件可写
后台”插件 → 安装插件”搜索 Loco Translate 安装启用。进入 Loco Translate → 主页，先做一次自检：
# 若后台提示目录不可写，用 SSH 确认属主与权限
ls -ld wp-content/languages wp-content/languages/plugins
id www-data 2>/dev/null || ps aux | grep -E 'php-fpm|nginx|apache' | head -5
大多数虚拟主机是 PHP 以站点属主身份运行，wp-content/languages 可写就没问题；如果是 root 属主，需要改成 Web 服务用户，或在 Loco 的”设置 → 文件系统访问”里开启写入。
第二步：找到目标插件，新建中文语言文件
进入 Loco Translate → 插件，在列表里点你的插件。此时通常会出现几个按钮：
- Create template（创建模板）：插件没自带
.pot时点它，Loco 会扫描源码生成 POT； - New language file（新建语言文件）：点它，语言选
Chinese (China)，即zh_CN； - 位置一项，务必选 “System”（系统目录），不要选 Custom。
第三步：逐条翻译并保存
编辑器界面左侧是待翻译条目，右侧输入框填中文。几个实用功能：
- 顶部筛选器可只看”未翻译”；
- 勾选 “Fuzzy（模糊）” 的条目表示源码字符串被改过，译文可能不匹配，要重点复查；
- 填完点 Save，Loco 会同时写
.po和编译.mo；
%s、%d、%1$s 这类占位符必须原样保留，数量和顺序都要对。
第四步：验证是否生效
# 确认 mo 文件真的生成了
ls -l wp-content/languages/plugins/ | grep zh_CN
# 切到中文站点语言后，确认 WordPress 读到了它
wp eval "load_plugin_textdomain('your-plugin'); var_dump( is_textdomain_loaded('your-plugin') );"
如果返回 bool(true)，说明加载成功；返回 false，先检查文件名是否是 {text-domain}-zh_CN.mo 的格式，text domain 大小写和连字符都要和插件头部一致。
第五步：插件升级后同步
插件更新后回到 Loco Translate → 插件 → 该插件，点 Sync，Loco 会把源码里新增的字符串并入现有语言文件，已翻译的部分不会丢。同步完再补翻新增条目即可。
常见踩坑
- 语言文件建在了插件目录里。升级一次全没，最典型的翻车。新建时一定选 System 位置。
- 改了半天的翻译没生效。多半是文件名不对，或者是站点语言（设置 → 常规）没切到”简体中文”。也有可能是对象缓存把翻译缓存住了，需要清一次。
- 翻译里有
%s被吃掉。填中文时顺手删掉了占位符，结果前台显示”本次共导出 条”，数字不翼而飞。 - JS 构建产物里的字符串翻不到。现代插件用 React 写后台，源码里的
__()已经编译进build/index.js，Loco 扫描 PHP 源码扫不到。这类插件需要用wp_set_script_translations()机制，或等官方语言包。 - 案例：一位站长用 Loco 给一个表单插件做了完整汉化，位置选了默认的 Custom。三个月后插件自动更新，前台表单提示全部变回英文，客户投诉”网站被改坏了”。排查发现
wp-content/plugins/xxx/languages/被新版本整目录替换。后来把.po/.mo两个文件复制到wp-content/languages/plugins/才彻底解决，之后再没丢过。 - 开了自动翻译 API 导致译文质量参差。Loco 支持接第三方翻译 API 批量机翻，但技术术语（如 “hook”、”nonce”）常被译成莫名其妙的词，建议机翻后人工过一遍关键界面。
- 把主题和插件搞混。主题翻译在 Loco Translate → 主题 下，路径是
wp-content/languages/themes/，别在插件页里找。
总结
用 Loco Translate 汉化插件，判断标准只有一条：语言文件最终落在 wp-content/languages/plugins/{domain}-zh_CN.mo，而不是插件自己的目录。在此基础上，每次插件升级后点一次 Sync，翻译就能长期存活。对于需要长期维护的站点，建议把 wp-content/languages/ 整个目录纳入备份范围 —— 它才是你所有汉化工作的真正资产。
想从开发侧根治这个问题，可以看 插件国际化与文本域规范；如果你的插件还涉及前台多语言切换，建议配合 WordPress 多语言插件选型 一起规划。
