如果只是想让“易翻译”里出现的公司名字保持原样，不被翻译，最稳妥的办法是把这个名字加入“保护词/术语表/自定义词典”，或者在发送给翻译引擎前用占位符替换并在结果里再还原。没有这些功能时，可以用 HTML 的 translate=”no”、class=”notranslate”、或在文本里加引号、全大写或零宽字符等技巧来阻止自动翻译；图片和语音则需要在 OCR/识别前后做替换或在对话模式里用拼读、占位提示等方式处理。下面一步步讲清楚怎么做、为什么这样做，以及各方案的优缺点和实操细节。
先理解问题：为什么公司名字会被翻译？
想象一下翻译器是个特别勤快的学生：它看到一个“词”，就按照自己学到的规则把词变成目标语言的意思。很多公司名含有普通词汇（比如“华兴银行”里“银行”就会被翻译为 bank），或者公司名看起来像一句话，翻译器就会自动处理。要阻止这一点，你要让翻译器“知道”这是一整块不该动的专有名词，或者在传给它之前把名字替换成它识别不出的占位符。
几种可靠方法与原理（按简洁到复杂排序）
1、加入“保护词/术语表/自定义词典”（最推荐）
原理：把公司名作为一个专有术语列入应用或翻译引擎的“词表”，并标记为“保持原样”或指定翻译结果为空，这样在机器翻译或本地翻译记忆中会被统一处理。
- 适用场景：应用内可配置词表、企业级翻译平台、CAT 工具（如 Trados、memoQ）或支持 glossary 的 MT API（如 Google Cloud Translation、DeepL Pro 的术语表）。
- 优点：稳定、规范、可批量管理多语言变体；培训翻译记忆后一致性高。
- 缺点：需要平台支持并有一定设置步骤；初次配置要花时间。
2、占位符替换法（最通用）
原理：把公司名在发送给翻译系统前替换成容易识别的占位符（例如 __BRAND_01__），翻译后再把占位符替换回原名。这在任何不支持术语表的场景下都有效。
- 适用场景：API 集成、网页翻译、批量文本处理、移动端简单流程。
- 优点：万金油方法，不依赖第三方功能；安全且可控。
- 缺点：需要前后处理代码或手动替换；若占位符被翻译器误处理，需谨慎选择格式（尽量用不常见的字符组合）。
3、HTML/标记技巧（网页或富文本场景）
原理：利用浏览器和某些翻译工具识别的标记告诉翻译器不翻译这段内容。例如：translate=”no” 或 class=”notranslate”。
- 示例：<span translate=”no”>易翻译有限公司</span> 或 <span class=”notranslate”>易翻译</span>。
- 适用场景：网站、富文本编辑器、嵌入式翻译插件。
- 优点：直观、无需额外替换步骤；对支持该属性的工具友好。
- 缺点：并非所有翻译器都尊重这些标记；在纯文本场景无效。
4、格式化与字符技巧（应急方法）
如果没有词表、无法改代码，可以用小技巧“扰乱”翻译器的识别，让它不把这段文本当作普通词来翻：
- 在名字中间插入零宽字符（U+200B）或连字符，如“易翻译”或“易-翻译”。
- 用全角字符或拼音：例如“YìFānyì”或“易翻译（YIFANYI）”。
- 用引号、反引号或代码块样式（`易翻译`），很多翻译工具会跳过代码样式。
说明：这些方式有时会影响可读性或搜索/统计行为，用作临时方案。
按场景详细操作（一步步来）
文本输入翻译（App 内文字翻译）
情形一：应用提供“自定义词典/术语表”。按以下步骤：
- 进入设置 → 术语/词典/保护词（不同 App 名称不同），新增条目。
- 添加“易翻译”及其可能的变体（如“易翻译有限公司”、“Yifanyi”）。
- 设置为“不翻译”或将目标语言翻译留空并保存。
- 测试：输入包含公司名的句子，确认输出中公司名未被替换。
情形二：没有词表功能：
- 在提交翻译前，手动将公司名替换为占位符（__BRAND__），翻译完成后把占位符换回公司名。
- 如果是批量文件，写脚本做替换会更高效。
语音实时互译
语音场景更麻烦，因为识别到文本后马上进入翻译流程。常见策略：
- 在文本处理环节加入命名实体保护：把识别结果中的公司名替换为占位符，再翻译，再还原。
- 如果是面对面双语对话，训练客服或主持人直接用拼读或英文字母形式（如“Y I F A N Y I”）来降低误译概率。
- 建议请求产品方在引擎层面加入“命名实体识别 + 术语表”支持，这是企业级方案。
拍照取词 / OCR 场景
图片文字要经过 OCR 再翻译，保护名词的关键时刻是在 OCR 解析结果之后、送给翻译引擎之前：
- 先对图像进行预处理：如果公司名以 Logo 或特定字体出现，考虑把它单独截取出来，或在 OCR 后对文本进行匹配替换。
- OCR 阶段可以用正则或名单去识别并标记该段文字为“品牌”再保护。
- 另一方法是把图像中的公司名手工标注为“不可翻译”，然后再执行翻译。
双语对话翻译（即时会话）
这种模式下，实时性要求高，推荐策略：
- 在会话设置里加入“保护词”列表（若支持）；
- 如果客户端不支持，后端在接收语音识别结果时进行命名实体识别（NER），对匹配到的公司名插入占位符；翻译后再替换回原名并播放/显示。
- 与对方沟通约定发音或直接使用拼读来减少误译。
开发者与集成方案（API 层面）
如果你是开发者，或者易翻译对外提供 API，可以采用更专业的策略：
- Glossary/Terminology API：多数商业 MT 服务（Google Cloud Translation、Microsoft Translator、DeepL Pro 等）都支持术语表或 glossary，向 API 传入术语表并指定“保持原样”。
- 占位符 + 后处理：请求发送前正则替换公司名为占位符，翻译后再替换，是最通用的做法。
- NER + 字段标注：在文本进入翻译管道前做 NER，把实体类型标注为 PROTECTED，这样翻译模块可以跳过这些标注。
- HTML 属性：如果内容以 HTML 形式传输，可保留 translate=”no” 标签，部分翻译库会自动尊重。
实战示例与小技巧（手把手）
举个实际操作的例子：
- 文本：“请联系易翻译客户支持获取更多信息。”
- 占位符流程：
- 前处理：将“易翻译”替换为 “__BRAND_YIFANYI__”。
- 翻译引擎输出（英文）：“Please contact __BRAND_YIFANYI__ customer support for more information.”
- 后处理：把“__BRAND_YIFANYI__”还原为 “易翻译”。
- 如果用 HTML 标签：把原句变为 “请联系<span translate=’no’>易翻译</span>客户支持。” 直接提交（前提是翻译器支持）。
对比表：常见方法优缺点一览
| 方法 | 稳定性 | 实现难度 | 适用场景 |
| 术语表/自定义词典 | 高 | 中 | 企业级、长期维护 |
| 占位符替换 | 高 | 低-中（需自动化） | 任何场景，通用 |
| HTML translate=”no” / class=”notranslate” | 中-高（取决于工具） | 低 | 网页/富文本 |
| 零宽字符 / 拼写干预 | 中-低 | 低 | 临时应急，演示或手工场景 |
| OCR 前后替换 | 中 | 中 | 拍照取词场景 |
细节与注意事项（说清楚免得翻车）
- 多语言形态：有些语言需要特定的词尾变化（例如俄语、芬兰语等）。如果你要“保留原文”，就直接标记为不可翻译；如果要“本地化”，则在术语表中给出目标语言的合法变体。
- 搜索与 SEO：占位符与零宽字符会影响搜索与索引。如果文本将用于网页与搜索引擎优化，要考虑替代方案，如使用 meta 标注或结构化数据。
- 可读性：插入零宽或特殊字符会影响复制/粘贴体验，支持者与客户要知情。
- 一致性：统一规则（例如术语表）能避免不同翻译人员/工具产生不一致翻译。
- 商标法律：有时公司在不同国家需要不同的本地化名称，决定“是否翻译”前建议与品牌/法务确认。
遇到问题怎么办？一两招诊断思路
- 测试：把一句包含公司名的简短文本分别用不同方法测试（原文、占位符、translate=”no”），看哪个生效。
- 日志：如果是开发集成，记录请求与返回，确认是否在发送给 MT 引擎之前已替换或已标注。
- Fallback：发现某种服务不尊重标注时，退回占位符法最可靠。
说到这里，可能你已经有了优先级：如果易翻译这个产品本身给你词表或保护词功能，优先用它；没有的话，占位符替换是靠谱的通用方案；网页场景用 translate=”no” 最方便；OCR/语音场景则需要在识别层面拦截并保护。反正做过几套流程后，你会发现把品牌当“数据”来处理比试图靠运气不被翻译要稳妥得多——我就是这样一步步调通的，边做边改，才找到最适合自己工作流的方式。
