易歪歪软件操作规范是一套把复杂流程拆成简单动作的规则，目的是让团队在翻译、校对、交付时少出错、速度可控、品质可衡量。遵守这些规范，可以减少术语混乱、版式错位和交付延迟，让客户满意度和团队效率双提升；以下内容会一步步讲清每个环节该做什么、为什么这么做、怎么检查，方便你一边学一边马上用。
前言：为什么需要操作规范
说白了，软件里跑的人多了就会有“我以为是这样，你以为是那样”的问题。尤其是翻译类工作，术语、版本、格式、交付标准如果不统一，结果会很糟糕。*易歪歪*的规范不是为了束缚人，而是把共同知识写出来，做到人人能快速上手、出错率低、审计有据可查。
总体原则（四条）
- 清晰可复现：任何操作都要能被同事复现，必要时写成步骤文档。
- 最小惊讶原则：界面反馈与结果应一致，不要做出“看起来完成但没生效”的操作。
- 术语与记忆一致：统一术语表与翻译记忆库（TM），避免同一产品出现两套名称。
- 可追溯与日志：每次修改、审核、导出都应记录操作者与时间。
角色与责任（谁做什么）
明确角色能避免踩雷。下面表格概述常见角色与主要职责：
| 角色 | 主要职责 |
| 项目经理（PM） | 需求沟通、排期、资源分配、客户确认、质量放行 |
| 主译（Translator） | 按术语与TM翻译原文，初步格式化，标注疑问 |
| 审校（Reviewer） | 检查术语一致性、语言流畅、功能术语是否符合目标市场 |
| 排版/工程（L10n Engineer） | 处理文件格式、编码、字符串占位、导出与打包 |
| QA/测试 | 在目标环境中校验显示和功能性问题，回归检查 |
工作流分解（一步一步看）
1. 项目初始化
- PM在系统建单：上传源文件、明确语言对、给出参考资料（品牌词表、风格指南、前案）。
- 分配资源：选择匹配的译员与审校，确认交付日期与里程碑。
- 建立项目记忆库（TM）与术语表（TB）：导入已有术语，标记必用词。
2. 翻译阶段
翻译不是直接把一句话替换成另一句，得按步骤来：
- 预处理：检查文件编码（UTF-8优先），清理多余空格、隐藏字符，确认占位符格式（如%1$s、{0}）。
- 使用TM与术语表：优先采纳高匹配度的TM建议，术语表为强制参考（若客户要求勾选“强制”）。
- 机器翻+人工：若使用神经机器翻译先做初译，人工则负责意图、语境与品牌调性修正。
- 自检清单：句子完整性、数字/单位正确、链接与邮箱保留、占位符不改动、HTML标签不破坏。
3. 审校阶段
- 重点检查术语一致性、品牌语气、可读性及目标市场文化敏感点（避免禁忌词）。
- 核对格式：列表、表格、按钮文案长度是否超出界面限制。
- 使用QA工具逐条比对源文与译文差异（比如术语被误译或遗漏）。
4. 排版与工程适配
这一环节容易被低估，但非常关键：
- 导出测试文件到目标环境（APP、网页、帮助中心），观察换行、溢出、占位符显示。
- 处理右到左语言（阿拉伯语、希伯来语）或字符扩展（德语、俄语）导致的UI问题。
- 对字符串进行长度测试并提供缩写或重写建议。
5. 最终验收与交付
- 生成交付包：译文源文件、TM增量、术语表更新、变更清单（CHANGES.md）与质量报告。
- PM与客户做交付确认，记录接收人和时间，存档版本号以便后续回溯。
常见问题与解决办法（实践贴士）
术语表老是不同步怎么办？
把术语表设为单一来源（中央TB），并在PM流程中强制“导入最新TB”步骤。*每次变更都写变更理由*，谁改了什么、什么时候改的要记录。
机器翻出来很机械，质量不行
把机器翻做“起稿器”，人工要做三件事：检查意图、调整风格、修正模糊句子。对于品牌文案，优先人工创译。
占位符被译掉或格式变了
- 在翻译工具里把占位符标记为只读。
- 在交付前做一个占位符一致性检查脚本，自动列出不匹配的条目。
工具与自动化建议
别试图把所有事都手工做。下面是推荐的自动化点：
- 自动化预处理脚本：去隐字符、标准化换行、导出字符串清单。
- 连续集成（CI）流程：每次提交触发术语检查与占位符验证。
- 质量报告自动化：输出未译段、TM利用率、字数统计与常见错误汇总。
质量指标（KPI）与度量方法
定量比空口说更有用。常用指标包括：
- TM利用率（高说明复用率好，低说明新内容多）
- 每千字人工编辑时间（PME）：机器+人工后的净编辑消耗
- 术语一致性异常数：每次审校发现的术语问题数量
- 客户反馈率：交付后xx天内的返修/投诉率
安全与合规
翻译工作常涉及敏感信息，规范里必须有数据安全要求：
- 访问控制：按需授权，定期审查权限。
- 传输与存储加密：敏感文件使用加密传输与加密存储。
- 保密协议（NDA）：对外协译员签署并归档。
- 删除策略：项目结束后按合同删除或归档源文件与临时文件。
典型操作清单（Checklist）
拿来即用的日常检查表，PM和译审都应该一项项过：
- 有没有使用最新术语表与TM？
- 占位符、变量、HTML标签完整吗？
- 数字、单位、货币格式正确吗？
- 交付文件编码为UTF-8？
- 交付包包含TM增量与变更说明吗？
- 有执行UI/功能性回归测试吗？
- 客户确认与签收记录齐全吗？
示例场景：从接单到交付的实际操作（一步步列举）
举个例子，好让你把抽象变成具体：收到一个产品说明书本地化需求，英语到法语，3万字，交期两周。
- Day0：PM建单，上传源文件，导入客户TB与历史TM，分配译者A与审校B。
- Day1-4：译者A机器初译+人工，使用TM命中50%，标出50处文化敏感点并提出询问单（Q&A）。
- Day5：审校B校对，调整品牌语气，修正40处不当缩写，生成审校备注。
- Day6：工程导出PTF到测试环境，发现按钮文案超长，给出缩写建议并回译确认。
- Day7：PM汇总QA报告，客户预览并提出两处修改意见。
- Day8：最终修订、生成交付包（译文、TM增量、术语表、QA报告），客户签收。
常用模板与范例
把模板放在共享目录，避免每次从头写。
- 项目建单模板（包括交付格式、验收标准、联系人）
- 术语变更登记表（谁改了什么，理由）
- 交付包清单模板（文件名、版本、校验签名）
最后说两句实用的心法
第一，不要把规范想成“条条框框”，它是为了省时间和避免大错；第二，遇到例外要记录原因并把新流程纳入规范，持续改进才有用。写着写着我发现，还有不少细节要边做边改——比如客户突变要求或语言特殊性，都会让流程长出小枝来，正常的。