在多个区域中定位电子邮件活动以前是一个缓慢的、重复性的任务,有许多手动步骤。 多个审查员在不同的版本上工作,同一内容被重写了几次,并且在多达13种语言中管理一致性需要大量协调。 而不是引入新的平台或外部工具,我运行了一个内部实验: Could localisation be automated using only the tools already available inside a standard enterprise Microsoft environment? 该原型主要依赖于 SharePoint、Power Automate 和 Teams,其中一个附加组件 - GPT-4.1 mini 通过 Azure OpenAI 访问 - 用于严格控制的 QA 步骤,这使过程能够从基于 LLM 的推理中受益,同时将所有数据保存在同一个企业环境中。 为了支持此工作流程,我设置了一个名为 SharePoint 结构化库。 包含代表本地化生命周期的每个阶段的文件夹: Email translations Folder Purpose 01_Incoming_EN Source English files; Power Automate trigger 02_AI_Drafts Auto-translated drafts from Copilot + GPT 03_In_Review Files waiting for regional review 04_Approved Final approved translations 99_Archive Archived or rejected versions 01_Incoming_EN 来源:英文文件; Power Automate trigger 02_AI_Drafts Copilot + GPT 的自动翻译草稿 03_In_Review 等待区域审查的文件 04_Approved 最后批准的翻译 99_Archive 已归档或拒绝的版本 文件在这些文件夹之间自动移动,取决于它们的状态。 目标不是建立一个完美的定位系统 - 只是看看原型可以使用内部工具走多远。 它最终删除了大量重复工作,并创造了一个更有结构的审查过程。 The Problem: Process, Not Language 问题:过程,而不是语言 在许多地区手动定位内容产生了几个一致的问题: 每个区域都编辑了自己的文件,所以同时存在多个不同的版本。 当源文本发生更改时,并非所有区域都更新了其版本,导致内容不匹配。 文件存储在不同的位置和不同的名称,这使得很难确定哪个版本是当前的。 评论需要时间,特别是当团队处于不同的时区时。 在多个文件中重复相同的编辑增加了小错误的风险 Attempt 1: Copilot-Only Translation 试点一:只使用 Copilot 翻译 虽然Copilot现在运行在更新的GPT-5系列模型上,但这个原型是建立在一个早期的版本上,翻译行为反映了那些早期的功能。 工作流的第一个版本很简单: 一个文件被上传到 01_Incoming_EN。 电源自动启动。 Copilot为每个区域创建了一个翻译。 由于 SharePoint 触发器可以在文件完成上传之前启动,因此流中包含了文件大小完成检查(在继续之前等到大小 > 0)。 然而,主要问题很快就变得清晰了:Copilot的翻译不够可靠,无法实现端到端的本地化。 共同问题包括: CTA翻译过于字面 语音和风格不同语言 被移除或更改的座位持有人 在列表、间隔和结构中的格式差异 这使得Copilot仅用于生成第一草案。 第二层质量检查是必要的。 Attempt 2: Adding GPT-4.1 Mini for QA 尝试2:为QA添加GPT-4.1 Mini 下一个版本添加了审查步骤: Copilot 初始翻译 GPT-4.1 mini (Azure) → QA 和一致性检查 GPT-4.1 小型改进: 调节一致性 保留地点 格式稳定性 与源头的含义相一致 提示需要调节以避免不必要的重写,但经过调整后,输出变得足够一致以在工作流中使用。 Engineering Work: Making the Workflow Reliable 工程工作:使工作流程可靠 架构很简单,但实际使用时出现了几个问题,需要修复。 Platform behaviour: SharePoint 触发程序并不总是立即启动,因此添加了检查和重置。 当频道更名时,团队路由失败,因此必须更新地图。 Design issues: 一些平行步骤在第一次跑步中失败了,因此引入了重复逻辑。 JSON 响应有时缺少预期的字段,因此添加了验证。 文件名不一致,因此定义了一个单一的命名格式。 经过这些调整后,工作流在正常条件下可靠地运行。 Final Prototype Architecture 最终原型架构 下面是系统的完整工作结构。 1. SharePoint Upload & Intake 这个过程开始时,一个文件被上传到 Email translations / 01_Incoming_EN 电源自动化: 检查文件是否已完全上传(零字节保护) 回收的元数据 提取的文本 确定目标区域 SharePoint 作为所有阶段的单一真理来源。 2. Power Automate Orchestration Power Automate 控制了工作流程的每个部分: 阅读英语来源 调用 Copilot 翻译草案 将草案发送到 GPT-4.1 mini for QA 根据区域创建一个分支机构 向本地团队发送电子邮件 发布团队批准卡 捕捉“批准”或“要求更改” 保存已批准的文件在 04_批准 在 03_In_Review 中保存更新版本 在 99_Archive 中存档旧版本 所有路由、重置和状态过渡都是由Power Automate处理的。 3. Copilot Translation Pass Copilot 翻译了提取的内容,并保存了大部分电子邮件结构 - 列表,间隔和格式 - 比单独 GPT 更好。 4. GPT-4.1 Mini QA Pass GPT-4.1 小型检查: 调节一致性 定义 定义 格式稳定性 位置完整性 这为区域审查提供了更可靠的草案。 5. Regional Review (Email + Teams) 对于每个区域,Power Automate: 通过电子邮件发送翻译的文件 发布了Teams 适应性卡 与批准 / 请求更改 如果提交了更改,则更新的文件返回到 然后重新进入工作流程。 03_In_Review 6. Final Storage 已批准的翻译被存储在 使用一致的命名格式。 04_Approved 被拒绝或过时的版本被移动到 这确保了完整和清洁的审计轨道。 99_Archive. Results 结果 在实际工作流程中测试原型之后: 翻译时间从几天减少到几分钟 更少的版本冲突 最小手动重写 更快的审查周期 在 Microsoft 环境中处理的所有数据 这并没有取代专用定位系统,但取消了大量重复的手动工作。 Limitations 限制 一些语言仍然需要风格调整 团队批准取决于评审员的响应时间 流需要对过渡错误的重复逻辑 色调一致性在长或复杂的电子邮件上有所不同 这对原型来说是可以接受的。 Next Step: Terminology Memory 下一篇:术语记忆 The next planned improvement is a vector-based terminology library containing: 格洛萨里 产品名称 限制条款 区域特征词汇 同义词组 东方规则 两种模型都会在生产或检查翻译之前使用此库。 Final Thoughts 最后的想法 该项目是一项内部实验,旨在了解本地化工作流程的自动化程度,仅使用标准的 Microsoft 工具和一个由 Azure 托管的 LLM。 它不是一个完整的本地化平台,但它展示了现有企业堆栈中的简单、结构齐全的工作流程可以实现什么。