如何为现有业务应用界定翻译集成范围
规划业务应用中的翻译功能。在申请报价前，明确内容、语言、审核、数据规则、故障处理和验收测试。
从团队需要用另一种语言完成的一项完整任务入手。然后明确翻译如何融入这项任务。与“添加一个翻译按钮”这样的请求相比，这能为软件供应商提供更清晰的估算依据。
范围应涵盖文本、人员、数据和结果，还应说明翻译失败时会发生什么。在选择技术方案之前，请按照以下步骤准备这份范围说明。
为首个版本选择一个工作流程
写明源文本来自哪里，以及经批准的译文必须送到哪里。例如，客服人员可能需要阅读收到的消息，并用客户的语言准备回复。这只是一个示例要求，并非某个 Vavus 安装项目的报告。
列出每个步骤：打开消息、请求翻译、对照结果阅读原文、编辑回复，并批准发送。决定翻译是自动开始，还是仅在员工选择后才开始。
首个版本要保持小规模。测试一个界面和一项明确的业务任务，比测试应用中的每个文本字段更容易。
明确内容和语言需求
列出需要翻译的字段。把简短标签、自由文本、文档和语音分开，它们可能需要不同的处理方式和测试。同时列出必须保持不变的字段，例如订单号和产品代码。
指明源语言和目标语言，包括任何地区变体。记录典型的文本长度和预计的每日处理量。询问拟用服务支持哪些语言组合和输入格式。
对于短文本，上下文可能很重要。例如，DeepL 的文本 API 支持上下文参数，它可以影响翻译结果，而上下文本身不会被翻译。其文档还指出，同一请求中的不同文本条目不会共享上下文。[1] 您的范围说明应写明有用的上下文从何而来。
确定术语和人工审核
收集贵公司经常使用的术语，包括首选译法、产品名称和应保持不变的词语。指定一人负责维护这份清单。
部分翻译服务支持术语表。Google Cloud Translation 将其术语表描述为一种自定义词典，用于保持特定领域术语的一致性。[2] 请针对您的具体语言组合和所选服务核实这项功能。有术语表并不能证明整条消息都正确。
决定哪些输出需要合格的语言审核人员。让审核人员能够查看原文。在面向客户的文本发送或发布之前，设置明确的批准步骤。
设定数据和访问规则
说明该工作流程处理哪些信息。早期测试时使用虚构示例。不要为了看一个按钮是否能用，就把真实的客户记录复制到试用环境中。
询问文本将在哪里处理、应用会存储什么、谁可以读取，以及何时删除。讨论时也要涵盖日志和备份。确认服务提供商的现行条款，以及所选套餐提供的控制功能。
定制界面本身并不会让外部翻译服务变得私密或可离线使用。如果您的项目需要本地处理，请在一开始就提出这一要求，并据此测试完整的数据流。
为延迟和错误做好规划
写明预期的响应时间，以及服务不可用时员工应采取的措施。应用应显示清晰的状态，例如等待中、待审核或失败。保留原文。
请开发人员区分临时故障和需要修改才能解决的错误。例如，DeepL 的文档说明，遇到速率限制错误时应延迟后重试，而配额用尽则需要采取不同的处理方式。[3] 重复的请求不应造成重复的业务操作，例如把同一条回复发送两次。
就用量提醒以及由谁负责支持达成一致。比较项目成本时，请计入服务费用、维护和未来的变更。
在开发前编写验收测试
为每个所需的语言组合选择有代表性的示例，包括长消息、特殊字符、缺失字段以及已批准清单中的术语。测试完整的任务，从源记录一直到已保存或已发送的结果。
设定人们可以核查的通过标准：产品代码保持不变、未经批准的译文无法发送、失败的请求清晰可见，以及审核人员可以返回查看原文。请合格的审核人员评估意思和语气。记录缺陷，并在修改后重复同样的测试。
准备一份清晰的报价请求
发送工作流程、示例字段、语言组合、预计处理量、数据规则和验收测试。将每一项标注为上线必需或可留待后续版本。要求以书面形式列明前提假设和不包含的内容。
Vavus 为定制项目提供书面范围界定服务。[4] 请通过报价页面介绍您现有的应用以及希望改进的任务。拟议的集成、部署和测试应在您的项目范围中加以确认。