有道翻译软件界面文案指南：按钮语境、占位符保护与交付验收
翻译一个按钮，有时比翻译一段说明更难。“Open”可能表示打开文件，也可能表示当前状态；“Apply”可能是应用设置，不一定是提交申请。把所有短词逐条送去翻译，得到的句子即使通顺，也未必能放回原来的软件界面。
有道翻译可以作为文本理解和译稿辅助工具，但软件本地化还需要开发者提供语境，并在实际界面测试。本文讲的是可执行的整理、翻译和验收流程，不假定当前客户端拥有特定资源文件导入或自动校验能力。配图为工作场景示意。
一、不要只有原文，先补齐使用位置
准备一份工作表，至少包含原文、资源标识、出现位置、使用者要完成的动作、目标语言和译文。资源标识是供程序匹配的键，不是需要翻译的正文。保留它，才能把结果准确交还开发者。
例如，同样一个“Save”，出现在编辑页通常与保存修改有关；出现在收藏菜单可能是保存到列表。把完整句子、附近按钮和截图一起提供，比只问“这个单词怎么译”更容易获得合适的结果。Microsoft 的本地化资料也强调，为字符串和占位符提供上下文有助于避免歧义。
二、先划出不能改动的部分
界面文案经常混有程序插入的内容。像 {name}、{0}、%s 这样的片段可能是占位符；代码标签、转义字符、网址、快捷键和产品标识也可能需要保留。它们的具体含义由项目规定，不能仅凭外观判断。
- 让开发者说明每个占位符会填入什么，以及是否允许改变位置。
- 将资源键与用户可见文字分开，避免把键名一起改译。
- 保留原有符号的大小写、括号类型和数量，不把半角程序符号换成中文全角。
- 对不确定的格式先标记待确认，不用猜测的“更自然写法”替代它。
假设原句是“Hello, {name}”，翻译时可以调整自然语言部分，但占位符不能变成一个真实姓名。某些系统允许重新排列位置，某些系统要求顺序一致；应由项目格式规则决定，而不是照搬另一个项目的经验。
三、按功能分批，而不是随机混在一起
把登录、设置、文件处理、错误提示等模块分别整理。翻译前说明目标用户和语气：面向普通用户的提示应清楚，开发工具可以保留必要技术名词。一次输入一组有关联的内容，让上下文保持一致。
如果使用有道翻译的文本或语言辅助功能，先对少量条目试译，再核对输出是否保持资源编号和必要格式。当前版本是否支持某种文件、额度是多少，应查看实际页面；不要为了批量方便，上传包含密钥、真实账号或未获授权的内部代码。
需要统一的术语，使用现有项目规范或经过确认的词表。不要把某个词在一个模块译成“工作区”，另一个模块又随意改成“空间”。同时也不能为了统一，把不同语境硬压成同一种说法。
四、短文案要说明动作，而不是只求简短
按钮最好让人知道点击后发生什么。破坏性动作尤其要区分“移除关联”“删除文件”“清空记录”，不能都用含糊的“清除”。如果界面已有确认提示，按钮与提示必须描述同一件事。
错误消息应保留问题和可行下一步。例如“无法连接，请检查网络后重试”比只有“失败”更有帮助，但不能凭空添加“数据已安全保存”等原文没有保证的结论。翻译人员可以提出改写建议，是否改变产品承诺需要负责人确认。
不要先把每条译文压到最短，再试图恢复丢失信息。先正确表达，再根据布局限制调整。有明确字符限制时把限制写进工作表，并区分字符数、显示宽度和实际控件空间。
五、回到界面验证，而不是在表格里验收
- 检查资源数量、键名和占位符是否与原件对应。
- 打开实际页面，确认按钮、菜单和提示没有截断或重叠。
- 用代表性的长用户名、不同数量和日期数据测试动态句子。
- 检查键盘操作、换行和大小写是否符合产品要求。
- 沿一个完整任务操作，确认文案前后没有相互矛盾。
同一句话在宽屏上能显示，不代表小窗口或手机屏幕也合适。截图只能展示一个状态，测试还要覆盖空列表、加载中、权限不足等实际会出现的情况。语言检查与功能测试应协同进行，但不要把机器翻译工具当成软件测试工具。
六、交付时把确定结果与疑问分开
最终文件保留资源标识和版本信息，注明目标语言、检查范围及待确认条目。疑问不要藏在译文里，例如“也许是删除？”会直接进入界面。可以单独列出原文、候选译法、缺少的语境和建议决策者。
当产品更新原文时，核对变化的是文字、占位符还是实际行为。旧译文不是永久可用的答案。对于行为已变的功能，重新检查整个提示组合，不能只替换新增的几个词。
常见问题
可以把整个资源文件直接翻译吗？先确认格式支持与保密要求，并用副本试验。即使翻译成功，也要校验结构和受保护内容，再由项目工具验证。不要让普通文本处理覆盖唯一原件。
回译成原语言就足够了吗？回译可辅助发现一些意思变化，但不能验证占位符有效、按钮显示完整或操作范围正确。最终仍需原文对照和界面测试。
相关阅读与核验资料
有道翻译AI语言助手使用与复核 · Microsoft：本地化上下文信息 · Microsoft：可本地化资源与占位符说明