在易歪歪上添加和维护自定义词库，关键是先搭好术语表架构（源语、目标译文、词性、上下文、优先级），用平台模板批量导入或逐条新增，结合翻译记忆与机器翻译设定优先级，启用审核、版本控制与权限管理，定期导出备份、检测冲突并在项目层级同步更新，就能保证术语一致性与翻译质量，并便于团队协作与快速上线。管理可追溯。
为什么要在易歪歪建立自定义词库？先用最简单的话说
把词库想成厨房里的调料罐：一个统一放香料、写好标签的厨房，比大家各自乱放要高效且少出错。翻译也是这样——统一术语表可以让整个团队、机器翻译和回归校对对“这个词应该怎么说”有一致认知，减少复工和品牌语言不统一的风险。
核心价值（一句话）
- 一致性：同一术语在不同页面/项目里保持同样翻译。
- 效率：批量导入、优先级生效，机器翻译与人工翻译都能复用。
- 可控性：权限、版本和审核链路让修改有据可查。
先把基本概念讲清楚（费曼法：把概念教给小白）
自定义词库（也叫术语表、glossary）由若干条目组成，每条通常至少包含：源词、目标译文、有无大小写区分、上下文示例和优先级。平台会在翻译过程中把匹配到的条目应用到翻译结果上（有时是强制替换，有时是建议）。
常见字段说明
- 源语（source）：原文词或短语。
- 目标译文（target）：首选译法，可含多种变体备注。
- 词性/用法（pos/usage）：名词、动词或专有名词，帮助减少歧义。
- 上下文示例（context）：一句话示例，帮助译者抓住语境。
- 优先级（priority）：决定与翻译记忆/MT冲突时谁生效。
- 状态（status）：草稿、已审核、废弃等。
一步步操作教程（从准备到上线）
第一步：规划与设计术语表结构
不要着急去导入词条，先问几个问题：哪些是必须统一的品牌词？哪些可以随上下文变化？谁来做最终决定？明确这些后，定义字段（上面提到的那些）和优先级策略（例如：词库优先级高于机器翻译但低于人工记忆）。
第二步：准备数据（CSV模板）
一般用CSV或Excel。建议字段顺序清晰，第一行写明字段名（便于导入映射）。示例模板大致如下：
| 字段名 | 说明 |
| source | 原文词或短语 |
| target | 首选译文 |
| pos | 词性（可选） |
| context | 一句话示例（可选） |
| priority | 优先级（high/normal/low） |
| status | draft/approved/deprecated |
第三步：批量导入或手动新增
- 批量导入（推荐）——用平台提供的模板把CSV上传，注意编码（UTF-8）和字段映射。
- 手动新增——适合少量修改或打补丁，记得填上下文和优先级。
- API导入——如果你要把外部术语库与易歪歪同步，建议使用平台API（按需验证速率限制）。
第四步：设置优先级与应用规则
优先级决定当TM（翻译记忆）、MT（机器翻译）和词库冲突时的处理方式。常见策略：
- 词库优先：词库强制替换，适合品牌专有名词。
- 建议模式：词库作为翻译建议，需要译者确认。
- 条件触发：仅在特定项目或语言对生效。
第五步：审核、版本控制与权限管理
不要让任何人都能直接改“品牌名”的译法。设定角色（词库管理员、审核者、编辑者），开启版本控制（每次修改记录谁在什么时候改了什么），这样出现问题可以回滚并追踪责任。
实战示例（举例说明更容易理解）
假设营销团队决定“SmartFit”为产品名称，不能翻译为“智能合身”或其他变体，词库配置如下：
| source | target | pos | context | priority | status |
| SmartFit | SmartFit | PROPN | 产品名，保持原文 | high | approved |
| login | 登录 | VERB/NOUN | 网站/应用操作 | normal | approved |
这样一来，机器翻译和人工译者在遇到SmartFit时会直接使用词库里的“SmartFit”。
维护与更新策略（长期有效的步骤）
定期审查
- 每月或每季度统计命中率（hit rate），查看哪些词条从未被使用、哪些词条频繁冲突。
- 对过时条目做废弃处理而不是删除，保持可追溯性。
冲突检测
当TM和词库给出不同译法时，平台应该能列出冲突并标注来源，管理员决定规则优先级或逐条审核。
备份与导出
至少每周导出一次CSV备份；做大规模修改前一定要备份当前版本（这点让我曾痛失过一次好不容易整理的表格，学到的教训）。
团队协作与工作流建议
- 指定词库负责人（Owner），负责最终审核。
- 新增词条先由编辑提交草稿，审核者批准后才推到“生产”词库。
- 把词库变更纳入发布日志（changelog），每次上线时同步到相关项目。
常见问题与排查小技巧
导入后没有生效？
- 检查字段映射是否正确，尤其是编码（UTF-8 BOM可能会出问题）。
- 确认优先级设置没有被项目层覆盖。
术语出现多种译法，如何收敛？
把出现频率高但非标的译法列出来，与业务方讨论是否纳入词库为次选或变体。用数据说话会更容易达成一致。
衡量效果的指标（怎么知道词库发挥作用）
- 命中率（Hit Rate）：词库条目在翻译中被匹配的比例。
- 一致性得分：同一术语在不同页面上的译法一致程度。
- 复工率：术语问题导致的返工次数（应下降）。
一些实用小技巧（那些用起来很顺手的细节）
- 在context中写一句真实用例，不要只写“产品名”。
- 为常见缩写保留原文和译文两项（例如：API → 接口（API））。
- 使用正则或形态变换规则来覆盖大小写或复数形式，减少重复条目。
- 对外部供应商或自由译者导出只读视图，避免误改。
遇到特殊情况怎么办？
比如一个词在不同语境下应有不同译法，这时把词条做成条件触发（根据项目/域/页面类型生效），或者在词库里写清楚“在X场景使用A，在Y场景使用B”。如果平台不支持条件规则，建议用后缀标注（如 login_Web / login_App）并在导入或使用时做好映射说明。
最后——一个实用的维护检查表（复制就能用）
- 是否有明确的词库Owner？
- 字段是否齐全（source/target/context/priority/status）？
- 是否定期备份并开启版本控制？
- 导入前是否验证编码与字段映射？
- 是否把变更记录写入发布日志并通知相关项目？
写到这里，感觉把流程都摊开了，慢慢来最重要：先从最常用的那些十几二十个词开始建，一次把流程跑通，再逐步扩大，别一口气想把所有历史词条都塞进来，那样容易把旧问题也一起迁移过来。就这样，先试试再调整吧。