产品文案多语言更新怎么协作？用流程图防止旧文案和旧截图回流

产品文案多语言更新，不能以“翻译表已填完”作为结束。一次中文按钮修改，可能同时影响英文按钮、提交后的提示、帮助文章和操作截图。应先确认改动表达的行为，再把文案版本、语言、出现位置和验收结果连起来，避免新按钮配旧提示、帮助截图仍指向上一个版本。

在可共同评审的流程图中，把产品确认、翻译、界面核对和发布分成不同步骤，相关人员就能看到自己接收的是哪一版。Boardmix 适合整理影响范围和审查记录，实际字符串、构建与上线仍由产品使用的文案管理和发布系统负责。

先问行为有没有变，再问怎么翻译

以一款报销应用为例：提交费用单的按钮原来写“提交”，团队希望改成“提交审批”，同时把成功提示从“提交成功”改成“已提交，等待审批”。本例业务行为没有改变，目的只是让使用者知道下一步仍需审批，而不是误以为报销已经完成。

产品负责人应先确认这条边界。若真实需求其实是新增审批步骤、改变提交后能否撤回，就不再是单纯文案更新；流程、权限和帮助内容都要重新核对。不能让译者根据一句“改得更清楚”自行猜测业务动作。

英文在这里是待结合语境确认的候选，不表示所有产品都应采用同一套写法。影响清单也不是要求每次改遍所有材料：没有变化的通知可以记录“不受影响及理由”，而不是为了让各列整齐而改写。

给译者一张语境卡，比只给两个字更有用

“提交”可能指发送表单、递交审核或执行一次操作。只有源文和目标语两列，很难判断。为本次变更建立 L-17 语境卡，将以下信息放在同一处：

• 用户与位置：报销申请人，费用单编辑页底部的主要操作按钮。
• 点击前后：点击前是可编辑草稿；成功后进入等待审批，尚未表示费用获批。
• 文案对象：按钮和成功提示分别记录，不能拼接几个零散词组成整句。
• 引用版本：中文源文 v2、对应设计稿或开发预览位置、语境确认人。截图应注明版本，不靠聊天发送时间判断新旧。
• 约束：按钮需在目标设备上完整可读；变量、术语和格式占位符由实现方列清，不能因为翻译方便而改掉其含义。

L-17 是这次变更的编号，还需要给按钮和提示分别绑定稳定的文案对象。例如按钮使用 expense.submit_for_approval，成功提示使用 expense.submitted_message；每个对象再记录语言、源文版本与页面位置。其他页面即使也写“提交”，也可能提交的是评论或搜索条件，不能只按中文字面全局替换。实际项目沿用已有文案键或稳定编号，不为了这次改字随意重建标识。

如果源句中含“已提交 {count} 张费用单”，还要给出变量的含义和允许值，并说明目标语言可能需要不同的语法形式。不要把“已提交”“张”“费用单”分别翻译后直接拼接；完整消息的结构应与实际本地化方案一致，由实现和语言审查共同确认。

翻译过程中中文从 v2 改到 v3，已完成的译文不能继续保留一个笼统“通过”。先看受影响的是哪些语义：按钮从“提交审批”改成“保存草稿”，会改变用户预期，需要重新审查；仅纠正中文错别字，也应记录核对结果，但不必无理由重译所有语言。

把“语言通过”和“界面通过”分成两道检查

在 Boardmix 上画出一条主线：确认源文与范围 → 提供语境 → 翻译 → 语言审查 → 实际界面检查 → 发布核对。每一步都写明接收条件，退回线指向具体缺口，不统一绕回“重新翻译”。

语言审查检查意思是否准确、术语是否一致、动作与结果是否匹配；实际界面检查则要打开对应语言和设备上的真实页面。英文按钮即便语法正确，也可能截成“Submit for…”，使“提交审批”中的审批意图不可见。W3C 关于翻译文本长度的说明提醒，翻译后字符长度、字形宽度和行高可能变化，布局不能只按源语言刚好装下。

语境卡可以放左侧，流程放中间，右侧放 zh-CN、en 两张验收卡。每张验收卡分别记录源文版本、语言审查、界面版本、实际截图和未决问题。语言数量增加时复制字段结构，不复制“已通过”状态；一张绿卡不能代表所有语言都看过。

检查提示语时，要真的走到相应状态。仅看到按钮不等于验证了提交后消息，成功状态也不能证明失败状态正确。对本例至少走读草稿、送审成功和提交未成功三条路径，记录实际文案与预期差异；不要在白板上拼出理想画面后就当成产品验收。

发布不齐时，明确差异；发布后，切断旧材料的误用路径

如果中文已经核对完成，英文仍有布局问题，先确认产品是否支持按语言分开发布，以及相关帮助页怎样对应。可以分开时，明确当前各语言实际版本与后续负责人；不能分开时，就按正式发布约定处理整项变更。不要默认“其他语言先回退中文”一定可用，也不能把未核对语言标为完成。

发布核对从使用者入口走一次：打开费用单，确认按钮；成功送审后，确认等待审批提示；再进入对应语言帮助页，核对步骤与截图。若有旧版本用户仍在使用，要保留适用版本提示，不能把尚在使用的旧说明直接删除。

被替换的截图保留在历史目录，并注明适用版本；当前帮助页和素材索引只指向当前材料。下次改稿时，从源文对象与变更编号找到引用位置，不从聊天里随手取一张看起来相同的旧图。如果帮助内容由多个团队维护，可以接入知识库审核流程，让产品确认结果进入同一份内容更新记录。

最终交付不是一张译文满格的表，而是一组能互相对应的对象：源文版本、译文、真实界面、帮助步骤与截图。任何一处改变，都能找到受影响的位置和重新核对的人，多语言更新才不会在下一次发布时把旧内容带回来。