在LookWorldPro里添加自定义术语，通常走四步：准备好词条表（CSV/Excel/TMX），在“术语库/术语管理”中新建或导入，核对字段并补充上下文/优先级，最后将词库绑定到项目并开启术语生效规则。完成后别忘了版本管理与权限设置，保证翻译人与机器翻译都能按照你的偏好用词。
先说为什么要做这件事（用最少的行话）
你可能会想：术语库不是可有可无吗？其实不是。*术语*就是品牌语言的“DNA”——一个产品名、一个专有名词、一个常用短语，如果被翻译得五花八门，用户会混淆，法律文本可能出问题，电商页面的信任度也会下降。把常用词固定下来，可以提高一致性、降低审校成本，并能驱动机器翻译和质检规则更准确地工作。
总体流程（像做菜一样分步骤）
- 准备阶段：整理现有词表，决定哪些项必须固定，哪些是建议。
- 导入阶段：把词表以平台支持的格式上传到LookWorldPro的术语管理模块。
- 绑定与生效：将该术语库分配给项目/语言对，设置是否“强制匹配”或“建议匹配”。
- 维护阶段：定期更新、版本控制、审核历史与权限管理。
准备一个合格的术语表（细到可以直接用）
简单来说，你需要这些信息：源语词条、目标语翻译、词性（可选）、上下文示例、优先级/标签、是否禁止翻译、备注/相关链接、来源与审核人。下面给出一个常用的CSV字段模板：
| 字段名（CSV列） | 说明 |
| source_text | 源语言词条（必填） |
| target_text | 目标语言推荐译法（必填） |
| part_of_speech | 词性（名词/动词/专有名词等，可选） |
| context_example | 一句话示例，说明如何使用该词条 |
| priority | 优先级（preferred/recommended/forbidden） |
| note | 备注或说明（品牌背景、商标信息等） |
| created_by | 创建人（便于追踪） |
在LookWorldPro中实际操作的通用步骤（逐条讲）
1）定位术语管理入口
打开LookWorldPro，通常在主导航栏下会有“术语库”、“词汇表”或“Terminology”模块。没有看到就查看项目设置或资源管理区。有些版本把它放在“资源/资源库”里——总之，找和“Glossary/Terminology/Dictionary”有关的名称。
2）新建词库或选择已有词库
建议先新建一个与品牌或项目对应的词库（比如“品牌A-电商-EN→ZH”），便于管理与权限划分。新建时填写简短描述、默认语言对和可见范围（团队/组织/公开）。
3）准备并导入文件
把前面表格里的CSV/Excel准备好，文件编码用UTF-8，列名尽量与平台默认字段对齐。导入时注意映射（mapping）步骤，把CSV列对准LookWorldPro的字段。如果平台支持TMX，也可以直接导入TMX以保留上下文对。
- 小提示：先导入少量（如50条）做测试，确认映射无误再批量导入。
- 出错排查：字符编码错误会导致乱码；重复条目会根据“覆盖/跳过/合并”策略被处理，注意选择你想要的行为。
4）设置规则：强制或建议
导入后你需要指定这些术语在翻译过程中如何生效。常见选项：
- 强制匹配（Enforce）：翻译器和译员必须使用该译法，通常用于商标、禁译词。
- 建议匹配（Suggest）：给出推荐译法，但保留人工修改权限，适用于风格词汇。
- 禁止项（Forbidden）：某些译法被明确禁止使用。
5）把词库绑定到项目/语言对
在项目设置里选择要使用的术语库。绑定后，在线编辑器、机器翻译和术语检查器都会读取该词库。若平台支持优先级，你可以设置多个词库的生效顺序。
术语如何同时驱动人工翻译和机器翻译（MT）
借助术语库，LookWorldPro可以把词条传递给MT引擎（作为自定义词典）并在编辑器里高亮显示。注意两点：一是平台需要有MT整合与“自定义词典”功能；二是MT自定义词典通常对词形变化有限，需要提供不同形式或规则（例如复数、大小写）。
权限与版本控制（别忽视这步）
术语改变会影响大量内容，所以要建立审核流程：创建→审核→发布。给不同角色不同权限，例如产品经理可创建与编辑，语言负责人可审核并发布，译员只读或建议修改。并保留变更历史，以便回滚与溯源。
常见问题与排查技巧（像和同事聊）
- 导入后没有生效：确认词库已绑定到项目并且翻译器使用了最新版本的词库。
- MT没有采纳术语：检查MT自定义词典是否启用，是否需要把词条以特殊格式提交（有些引擎对标注有要求）。
- 重复或冲突词条：优先级规则决定哪个词条生效，或合并并写清备注。
- 权限问题：确认用户在术语库及项目两处都有相应权限。
进阶用法：API、自动化与质量监控
如果你的账户有API权限，可以用API自动化导入/更新术语，实现持续同步（比如把新产品名从产品系统推到术语库）。另一个常见做法是把术语检查纳入QA流程：在交付前自动跑一遍术语一致性检测，生成报告，减少人工返工。
通用API示例（概念级，不同平台有差异）
下面是一个概念性的JSON示例，用来说明“上传一个术语”的结构：
{
"glossary_name": "品牌A-EN-ZH",
"entries": [
{
"source": "ProX",
"target": "普罗X",
"part_of_speech": "proper_noun",
"priority": "preferred",
"context": "产品名称，首字母大写",
"note": "为商标，禁止意译"
}
]
}
实践小贴士（别只是理论）
- 把“真实例句”写在context字段里，译员能立刻理解用法。
- 把常见错误列为forbidden项，减少重复审校。
- 设一位语言负责人负责季度检查与统计，观察术语命中率和问题词。
- 导入前先导出平台样例模板，严格按模板字段填充，能省去很多映射错误的时间。
举个小案例（就像边写边想）
假设你负责一个移动电商App，要把“闪购”这个概念统一为“Flash Sale（EN）”和“Venta Flash（ES）”。你会：
- 在CSV里加入条目：source=闪购，target_en=Flash Sale，target_es=Venta Flash，priority=preferred，note=促销活动名称。
- 导入并映射字段，选择覆盖策略为“新条目添加、已存在不覆盖”。
- 绑定到App项目并把规则设为“建议”或“强制”，看想要多严格。
- 上线一周后看命中率，若译员经常改动就把建议改为强制，并在style guide里补充说明。
说白了，术语管理不是一次性工程，而是持续运营——把准备做到位，和团队约定好流程，然后用工具把规则自动化，这样品牌表达会越来越统一，翻译速度也会慢慢变快。嗯，写到这里，我还想到一个小细节：别忘了把术语作为交付标准的一部分写进SLA里，必要时做抽检，这样大家都有动力维护一致性。