术语创建、审批和更改的流程清楚且可自定义。创建/更改术语的请求可通过在线方式轻松提交。
- 术语创建/更改提议、审批和公布全部相互独立
- 所有术语相关的历史记录都存储在数据库里，包括创建/更改术语的时间和原因、创建人等。
- 所有术语专家都遵循一个涉及所有细节和说明的集中式流程
目标术语创建/更改流程是完全自动化的。并且要求客户的参与。
- 特定语言的反馈会立即计入考量
- 澄清、要求和修改就构成我们内部流程的全部
- 告别不当添加术语或缺失说明相关的问题
- 无需耗费时间或金钱进行询问或源术语改进
高级流程图表如下所示：
如果术语流程中涉及客户子公司或其他供应商，则工作流程会相应调整。
-
提议由注册术语贡献者发起
- 提议可包括译文中的新术语或术语更改
- 可能被 Logrus 术语经理或专家立刻拒绝，或
- 创建/更改术语并发送给客户【供应商/子公司】进行审批
-
查看客户【供应商/子公司】评论
- 最终确定术语
- 某些情况需要多次反复操作
可以轻松自定义特殊工作流程，以便优先符合客户的术语创建和审批流程。
我们需要客户做的
为进行源术语工作，我们需要：
- 产品名称和版本
- 产品团队内的支持联系人
- 可靠的术语数据和作者的所有权
- 相关产品和领域的参考资料和/或术语
- 决定术语数据库（客户的数据库或 Logrus IT 数据库）或双方协定的模板
- 用于采集术语的文件（如果需要）
为进行目标术语工作，我们需要：
- 目标语言列表（支持几乎所有语言）
- 截止期限
- 客户端的支持联系人
- 如果术语由客户和/或第三方代表审查，需要目标语言的联系人
- 元数据用以查找产品中的源术语
应预先讨论和定义的特殊方面。
实际运行方式
提前讨论流程细节非常重要。准备好流程需要包括以下方面：
-
由谁开始创建新的源术语？
- 某些情况下，所有源术语均由客户开发/维护
- 其他情况下，这个工作被部分或完全外包
- 谁能发起术语请求（客户、Logrus IT、其他供应商）？
- 谁能批准这些提议（客户的本地化团队、Logrus IT、分公司）？
- 谁能发布术语或更改（客户、Logrus IT）？
- 客户是否区分内部术语人士和子公司审校员？
- 术语属性要求/统一了什么？
- 是否有对于流程的其他特殊要求？
- 对于所有外部术语数据库用户，应提供什么访问权限？
通常情况下，提议可由各方发起：
- 客户（新软件或概念/术语出现时）
- 供应商（翻译中出现新概念/术语表面时）
- 术语供应商（视客户请求而定或收到不一致或更改请求时）