游戏译员收到一份字符串表后，往往还不能直接判断每句话应该怎样表达。按钮文字、角色对白和系统提示可能长得相似，却承担不同任务。
一份好的交接资料，应帮助译员理解这些差异，也让开发团队能够把语言问题带回实际游戏中验证。
给字符串一个可识别的位置
保留稳定的标识，并说明文字出现的界面、触发条件或说话者。必要时提供截图、演示或可用的参考环境，而不是只给一列没有上下文的文本。
相同原文在不同场景里不一定使用相同译法。若系统复用同一条资源，需要说明它出现的各个位置，避免其中一个场景被忽略。
把技术限制写清楚
变量、格式标记、换行方式和长度限制，都应作为交接信息。哪些部分不能修改，哪些限制可以与开发团队讨论，需要明确区分。
字体是否覆盖目标字符、文字放入界面后是否完整显示，需要实际检查。译员可以报告问题，但不能仅靠文档保证最终渲染结果。
角色与术语参考要可用
角色关系、语气和专有名称，可以帮助解释对白中的指代与态度。已批准译名应标明状态，暂定名称则不能被当作最终标准。
参考资料应与当前版本一致。与其提供大量无法判断有效性的旧文件，不如明确哪些材料可以采用，以及缺失信息由谁确认。
问题反馈需要形成闭环
提问时可以记录字符串标识、原文、疑问与相关画面。开发或内容负责人答复后，应让受影响的译文与词表同步更新。
仅在聊天里回答一次，可能难以让其他参与者知道结论。可以使用项目已有方式保存确认结果，不必为此建立复杂新系统。
集成后再次看实际语言
语言稿完成后，还要查看真实界面、对话顺序和动态内容。发现问题时区分翻译、源文、资源映射或显示问题，交给对应负责人处理。