`translate="no"` 是现代浏览器中用于禁用自动翻译的HTML属性，虽已在Chrome 104+、Firefox 115+和Safari 16.4+中稳定支持，但存在显著兼容性断层——Safari 16.3及更早版本完全无视它，所有浏览器均不支持在表单控件（如input placeholder）、SVG文本、JavaScript动态生成内容及contenteditable区域生效；它仅对纯文本容器（如div、p、span、title）的可见文本起作用，且具有强制单向继承性（父设为no则子无法恢复翻译）；尽管能有效屏蔽右键翻译菜单和页面级翻译工具栏，却无法阻止第三方翻译API调用；当兼容性不可控时，需结合语义化标签（如``）、服务端注释+脚本补全、或极端场景下转为图片等兜底策略，兼顾可访问性与实际防护效果。

translate="no" 在现代主流浏览器中基本可用，但存在关键兼容性断层：Chrome 104+、Firefox 115+、Safari 16.4+ 原生支持；Edge 基于 Chromium 版本同步跟进；而 Safari 16.3 及更早版本完全忽略该属性，且所有浏览器在表单控件（如 <input>、<textarea>）上均不生效。

哪些元素上 translate="no" 真正起作用

它只对**文本内容可被浏览器自动识别并触发翻译建议的 HTML 元素**有效，典型场景包括：

• 、

  、、

  ~

  等包裹纯文本或内联文本的容器

• 的可见文本（非 value 属性值）
• 中的文本内容
• 不生效的典型情况：<input placeholder="Search"> 中的 placeholder 文本、 的文本、SVG 内的 、以及任何通过 JavaScript 动态插入的文本（除非 JS 显式设置该属性）

translate="no" 和 translate="yes" 的行为差异

浏览器默认对大多数元素启用翻译（等价于 translate="yes"），但显式设为 "no" 后：

• Google Chrome / Edge：不再在右键菜单显示“翻译成中文”选项，且页面级翻译工具栏（如 Google Translate 插件）会跳过该节点及其子树
• Firefox：同样抑制右键翻译入口，但部分旧版对嵌套子元素处理不一致（建议避免在 translate="no" 容器内混用 translate="yes"）
• Safari：仅从 16.4 开始遵守；此前版本即使写了也完全当不存在，且无降级提示
• 注意：translate="no" 不阻止机器翻译 API 调用，也不影响开发者手动调用翻译服务

替代方案与兜底策略（当兼容性不可控时）

若需覆盖 Safari 16.3–16.3.1 或旧 Firefox，不能只依赖 translate 属性：

• 对关键文本（如品牌名、代码片段），改用 或 语义化标签——多数翻译工具默认跳过这类元素
• 用 CSS text-rendering: optimizeLegibility + 字体微调虽不能禁翻译，但可降低自动识别置信度（非常规手段，慎用）
• 服务端渲染时，对必须禁译的字段加注释 ，配合前端脚本扫描并动态补 translate="no"（适用于已知 DOM 结构）
• 最稳妥的做法：将敏感文本转为图片或 SVG 文本（牺牲可访问性与 SEO，仅限极少数 logo 类文案）

真正容易被忽略的是：该属性对 contenteditable 区域无效，且一旦父元素设为 translate="no"，子元素无法再用 translate="yes" 激活翻译——这个继承规则是单向强制的。

文中关于常见HTML属性兼容性问题有哪些的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《禁止翻译属性兼容性及使用方法》文章吧，也可关注golang学习网公众号了解相关技术文章。