translate="no"是唯一被广泛支持的禁用翻译标准写法，可精准控制不可译内容（如品牌名、代码片段），但Firefox不支持且部分插件会绕过，需配合lang属性和i18n工具链使用。
translate 属性设为 "no" 才能阻止翻译工具翻译
浏览器内置翻译（如 Chrome）和第三方翻译插件主要靠 translate 全局属性识别是否跳过翻译。设为 "no" 是唯一被广泛支持的明确禁用方式，"none" 或空值、false 都无效。
常见错误是写成 translate="false" 或 translate="off" —— 这些在 HTML 规范里不合法，浏览器会忽略，最终仍可能被翻译。
-
translate="no"：标准写法，生效 -
translate="yes"：显式启用（默认行为，一般不用写） -
translate（无值）：等价于"yes"，不是禁用 - 省略
translate属性：由父元素继承，根元素默认为"yes"
需要禁用翻译的典型场景
不是所有文本都适合翻译，比如品牌名、代码片段、带格式的占位符、多语言混合的 UI 文本（如 “Click to copy npm install”），硬翻译会导致语义错乱或语法错误。
这时应精准包裹不可译内容，而不是给整个页面加 translate="no" —— 后者会让所有子元素失效，包括本该翻译的说明文字。
立即学习“前端免费学习笔记（深入）”；
- 产品名、命令行指令：
<span translate="no">React Router v7</span> - 路径或 URL 片段：
<code translate="no">/api/v2/users/:id</code> - 带变量的模板字符串：
<span translate="no">${username}’s dashboard</span> - 图标旁的辅助文本（如 “⚠️ Required” 中的符号+英文组合）建议整体设
translate="no"，避免只翻单词
translate="no" 对嵌套子元素的影响
translate="no" 会强制关闭该元素及其所有后代的翻译，无论子元素是否显式写了 translate="yes"。这是设计行为，不是 bug。
所以别这么写：
<div translate="no"> <p>This will NOT be translated</p> <p translate="yes">This still won’t be translated</p> </div>
如果部分子内容需要翻译，得拆开结构，用独立元素分别控制：
<p>Error: <span translate="no">ECONNREFUSED</span></p> <p translate="no">See <a href="/docs/errors">error docs</a> for details.</p>
兼容性与实际效果差异
Chrome 和 Edge 的翻译栏基本尊重 translate="no"；Firefox 目前不支持该属性（截至 2024），Safari 仅部分支持。这意味着它不能替代服务端语言标记（如 lang 属性）或 i18n 工具链。
更隐蔽的坑是：某些翻译插件（如 Google Translate 页面插件）会绕过 translate 属性，直接按 DOM 文本提取 —— 这时只能靠 CSS content 伪元素、data- 属性 + JS 渲染等规避手段，但成本高且影响可访问性。
真正稳定的做法是：关键不可译内容优先走 translate="no"，再配合 lang 属性标明原文语言，并在构建流程中用 i18n 提取工具排除这些节点。
