商丘企业为外贸网站调整语言，有时先将WordPress后台切到英文，再发现产品正文仍是中文。需要分清给编辑看的界面、网站自动生成的文字和人员写入的内容。它们可能由不同设置、主题、扩展和资料维护，不会因一个语言下拉选项全部变成已审核译文。
先分清三类文字
修改用户语言会翻译产品资料吗？
不能从界面语言设置得出这种结论。产品事实与正文仍需实际翻译和审核。
后台是中文，网站一定不能用英文吗？
不能这样判断，后台使用与访客页面应分别核对。
| 层面 | 例子 | 实际检查 |
|---|---|---|
| 用户界面 | 编辑人员看到的管理文字 | 当前用户语言与相关设置 |
| 站点生成文字 | 主题或扩展提供的按钮、提示 | 实际站点配置与译文 |
| 编辑内容 | 产品标题、正文和图说 | 翻译、事实及页面对应 |
| 操作状态 | 错误与提交反馈 | 正常与异常路径实际显示 |
WordPress站点健康资料分别列出站点语言和用户语言，并说明两者的使用范围。这里不按一份旧界面截图给出固定菜单操作，也不假设所有扩展都能自动翻译全部文字。当前实现需要实际检查。
把翻译当作资料工作交接
语言交付记录
实际面向的读者与语言：
产品正文及事实审核范围：
主题和扩展生成的文字：
表单及异常反馈：
页面与语言入口对应关系：
暂未覆盖内容：
后续更新责任：先验证一条完整任务路径
- 从真实入口进入对应语言页面。
- 读正文，确认对象、条件和术语准确。
- 操作表单或必要功能，检查提示。
- 切换语言后确认仍是对应资料。
- 记录尚未翻译或未审核的部分。
1范围明确哪类文字由谁提供。
2翻译保留真实对象与条件。
3操作核对正常和异常状态。
4维护更新时同步相关位置。
一份清楚的多语言交付应能指出已完成的页面和状态，以及尚待补齐的资料。这样运营人员后续改产品时，知道哪份译文需要同步，而不是反复切换后台语言期待正文自动变化。