在混沌初开的文档系统中，如果没有对术语进行系统地规划和管理，那么可以想见，出现在文档中的术语，往往随意且凌乱，存在着同义不同词；同词不同义；中英文混杂；使用范围不当；语义不清；关联模糊等问题。以至于在浩瀚的文字海洋中，淹没了事实真相，留下了一个深深困扰我们的哲学难题：你所说的Being（存在），和我所理解Being，究竟是不是同一个Being？
但是，在技术写作的世界中，精确高效地传递信息，是一切努力付出的目的所在。而含糊不清的术语，可能会引起不必要的误解，不仅无法实现预期目标，反而增加了沟通成本；在对外交付的场景中，还可能引起用户对产品专业性的质疑。
如何解决这个——不大，却很讨厌的——“蟑螂”问题？大家好，我是睿齐，一个技术传播者。
什么是术语
术语（terminology）主要用于专业领域交流活动，是在专门领域中表示专业概念的专门用语或表达，可以是单词，也可以是短语，概念边界须清晰，应避免多义和歧义现象。
术语最重要的特征是：
专业性：用于指代特定领域或行业中的重要概念。
单义性：理想状态下，术语在特定领域中仅与唯一一个概念对应。术语的单义性对于保障专业领域知识的顺畅沟通具有关键作用。
系统性：术语与概念并非单独存在，而是彼此之间相互关联。
相应地，术语管理，就是对术语资源进行加工处理的一系列活动，包括术语的收集、筛选、描述、使用、更新、维护、翻译等诸多方面。
实施方案
基于现有文档积累，梳理并建立术语库：
创建。从既有文档中，识别并手动提取术语，按术语库定义，填写相关内容，创建初始术语库。
去重。从术语库中识别重复术语，精简合并。
开发。基于术语库定义，开发术语相关内容。
规范。制定术语使用/运维规范，明确责任人和相关操作，实现系统改进。
评审。评审术语库；评审术语使用/维护规范；就相关内容进行确认，达成最终一致。
发布。指导后续文档开发，内外部交流使用。
使用/维护。按照既定规范使用/维护术语库。
在这里需要说明的是，与专业的语言服务商所提出的解决方案相比，我们的实施方案可能无法面面俱到，实现“一步到位”的好，但对于初创公司而言，当务之急需要解决“从无到有”的问题，因此，结合公司现状和需求，尽可能考虑可扩展性，快速推进落地，后续迭代改进，也许是最好的选择。
术语库定义
术语库与术语表有所不同。通常意义上的术语表，是术语定义和说明的集合；而术语库，则是在术语表的基础上，附加了使用方法、编辑记录等信息，对术语更进一步说明。
分组 | 内容 | 说明 |
术 语 及 说 明 | 中文术语 | - |
英文术语 | - | |
中文缩写 | 即简称。 | |
英文缩写 | 【写作说明】需考虑大小写 | |
中文说明 | 说明术语的含义。可考虑包含，但不限于，以下内容：
【示例】
| |
术 语 使 用 说 明 | 优先使用 | 说明在技术文档中，优先使用那种术语类型。 【取值范围】
【是否必选】是 【使用说明】在文档中使用该术语时：
|
禁用同义术语 | 原则上，同义术语应去重合并，以保证术语使用的一致性。 【是否必选】如存在同义术语，则指定唯一术语，并禁用其他同义术语 | |
允许同义术语 | 如存在同义术语，需进一步说明使用场景。即在什么场景下使用A，在什么场景下使用B。 【是否必选】否 【使用说明】为避免额外的理解成本，不建议使用同义术语。 | |
固定搭配 | 说明该术语使用时的固定搭配。 【是否必选】如术语指代的对象为一个实体，则必须说明其所属分类 【使用场景】包括但不限于模块/组件/接口/UI控件（例如按钮）等 【示例】
| |
使用场景 | 说明术语的使用场景。 【是否必选】如存在相似术语，则需要区分使用场景 | |
使用说明 | 补充说明术语相关使用方法。 | |
元 数 据 | 元数据 | 自定义典型的术语分组，便于后续筛选查询。例如，适用产品，发布范围，术语表等。 |
适用产品 | 如术语为产品自定义术语，则说明适用的产品类型。 | |
发布范围 | 说明术语的适用范围。 【取值范围】
说明：对外发布术语具有较高质量要求，和开发优先级。 | |
术语表 | 说明该术语是否在交付文档的术语表中呈现。 说明：在交付文档术语表中呈现的术语，具有较高质量要求，和开发优先级。 | |
编 辑 信 息 | 责任人 | 指定术语开发责任人，对术语及其说明的正确性负有责任。 |
编辑历史 | 在后续术语维护过程中，记录术语修改历史。 | |
参 考 信 息 | 术语来源 | 说明当前术语的获取途径，便于追溯。 说明：该内容仅用于术语表开发过程中参考使用，待术语表正式发布后，可删除。 |
参考资料 | 说明但钱术语及说明的内容来源，便于追溯。 说明：该内容仅用于术语表开发过程中参考使用，待术语表正式发布后，可删除。 |
系统改进
术语库是文档系统的基础设施。术语生命周期，经历了识别、定义、评审、使用、测试、维护等漫长的阶段，因此需要系统改进，以保证其运转正常。
定义关键角色
明确关键角色对术语管理的责任。
角色 | 责任 |
质量工程师 | 术语质量管控的总负责人，可以由产品总监兼任，定期检查术语管理在流程改进的落地情况、外部客户评价结果。 |
产品系统设计师/研发工程师 | 产品术语表的责任人，在设计阶段定义新增或修改的术语，对术语内容的准确性负责。 |
文档/翻译工程师 | 术语表的评审这和使用者。参与评审和翻译新增/修改的术语，确保术语的定义和翻译符合行业规范，参与术语库的改进和优化方案，确保术语在技术文档中的一致性，对技术文档可用性负责。 |
定义术语管理流程
将术语管理纳入产品研发的全流程质量管控中，从源头上控制由于输入不一致导致的术语不规范的风险。主要涉及3个主要阶段。
阶段 | 说明 |
概念设计阶段 | 产品系统设计师/研发工程师识别产品概念、功能和规格中涉及到的专有名词，整理本产品新增、修改或删除的术语表，并组织评审。 |
开发和测试阶段 | 依据术语表，制作产品中英文界面。 以术语表作为写作和翻译的依据。 同一术语在全文保持统一，包括英文字母大小写。 在测试报告中增加术语表测试相关内容。 |
维护阶段 | 随产品的需求变更、规格变化及时更新技术文档和配套的术语表。 |
工具关联
术语表与文档质量检查工具对接，作为检查技术文档术语规范度的数据库。
术语表与企业内部产品信息网站、售后技术支持网站对接，支持在网站界面，按关键字查询术语信息。
总结
最后，术语库建设的预期收益是：
精简语言环境：让简洁、准确、高效的沟通成为可能。
对齐关键信息：解决“鸡同鸭讲”的问题。
规范术语使用：让文档开发有理可依，有据可循。
提供翻译语料：也许，走出国门也是有可能的，谁知道呢。当然，归根结底，
降低沟通成本：永远是技术传播的价值所在。
你说是吗？
参考资料
本文部分内容参考自《术语管理指南》，特此声明。
相关文章：
其他推荐：
实施：GitHub + MarkDown 文档系统的工作环境部署及工作流程说明 | 技术传播
这次他们说好要“讲真的” | 传播
在座都别吵了，你们还有我 | 技术传播
睿齐
技术传播从业者
品牌内容策划
自由摄影师
自由撰稿人
汪力迪
公众号：techcomm / htstory
微信号：bgrichi
邮箱：hash_0813@163.com
1397
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
