在HelloWorld中,翻译入口通常就在主界面底部导航栏的“翻译”标签里;此外,你也可以通过主页面中央的输入框、拍照/语音快捷按钮、系统分享扩展或键盘扩展直接进入对应的文本、语音和图片翻译功能。桌面和网页版则把翻译放在顶部菜单或侧边栏,并且提供API与浏览器插件供深度集成。
先把位置说清楚:哪里能进入翻译功能 好,...
阅读更多 →

先把它想象成厨房里的调味罐:通用词像盐和油,专业术语像各种香料。翻译软件如果没有稳定的术语表,不同文本、不同译者会出现口径不一的译法,特别是跨语种、跨行业时更容易翻车。术语库的价值在于把这些“香料”统一起来,让翻译风格和专业性保持一致,提高效率、降低误译风险。
每个术语要像身份证一样清晰,谁都能读懂它代表什么、什么时候用。下面是推荐的字段与含义:
| 字段 | 说明 |
| 原文(source term) | 源语言词或短语,精确写法 |
| 目标译文(target term) | 标准译法或若干候选译法 |
| 词性 / 术语类型 | 名词、动词、专有名词、品牌、缩写等 |
| 语域 / 适用场景 | 法律、医疗、IT、营销、用户界面等 |
| 上下文示例 | 至少一两个原句与对应译句 |
| 来源与证据 | 出处(手册、标准、客户要求)与审校记录 |
| 优先级 / 权重 | 高频/低频,是否强制应用 |
| 状态与版本 | 草稿/批准/废弃与版本号 |
| 责任人 / 审核人 | 谁提交、谁批准、最后更新时间 |
把复杂任务拆成几层,先打地基再搭框架,最后装修。
统一格式可以让术语在机器和人工之间无缝流转。建议采用可导出的通用格式(CSV/TSV、TBX、TMX),并明确每列含义。
像代码一样管理术语:每次变更都要有记录,能够回滚。发布可以分为“测试环境”和“生产环境”。
这里讲点“手艺”层面的东西,方便落地实施。
要有量化指标,就像体检一样定期检验术语库是否健康。
没有治理,术语库会变成杂物间。简单明确的角色与流程能节省很多争论时间。
下面是几个简短示例,模仿真实库存卡片。
| 原文 | 译文 | 词性 | 语域 | 示例句 |
| rollback | 回滚 | 动词/名词 | IT/数据库 | After the failed update, we had to perform a rollback. → 在更新失败后,我们执行了回滚。 |
| onboarding | 入职引导;项目接入 | 名词 | HR / SaaS | New hire onboarding takes two weeks. → 新员工入职引导为期两周。 |
| API | 应用程序接口(API) | 缩写/专有名词 | 通用 | Integrate with the public API. → 与公共应用程序接口集成。 |
不一定。质量比数量重要。一个包含大量未经验证的候选译法的“大库”,反而会降低一致性。先做小而精的核心术语表,随着项目需求再扩展。
目前还不能完全替代。机器在抽取、初步对齐、统计频次方面能节省大量人力,但语义歧义、行业约定与风格偏好需要人来把关。把机器当成“学徒”,人工是“师傅”。
术语库是个活的东西,需要定期“喂养”。制定周期性的审查计划(如季度回顾),建立反馈渠道(译者、客户、客服),并把新学到的用法纳入候选清单。
刚开始不要追求完美。把术语库当成“最小可用产品”,先解决最痛的问题。常见的小技巧:
搭建术语库其实不复杂,但需要持续的制度和习惯:明确格式、来源可靠、人工和自动结合、版本与权限清晰、指标常态化。你会发现,术语库越做越像公司的知识资产,慢慢就不会再因为一句翻译而大家争论半天了,工作也轻松多了。
了解更多相关内容
先把位置说清楚:哪里能进入翻译功能 好,...
阅读更多 →
费曼式解读:把问题说清楚 把“批量刊登怎...
阅读更多 →