HTML全局translate属性怎么应对各种浏览器自带翻译的兼容干扰-html教程-PHP中文网

chrome仅识别字面值“no”（大小写敏感、无空格）来禁用翻译，其他如“false”“off”或动态设置均无效；input/textarea的value不继承translate，需单独标注；lang属性缺失或错误会导致translate="no"失效。

html全局translate属性怎么应对各种浏览器自带翻译的兼容干扰

Chrome 为什么只认 `translate="no"`，其他值全失效

Chrome 的翻译引擎在 HTML 解析阶段只识别字面值 "no"，大小写敏感、不能带空格、不能简写。写成 translate="false"、translate="off"、translate="" 或 translate（布尔属性形式）都完全无效。它不是“宽松匹配”，而是硬性枚举：合法值只有 "yes" 和 "no"，其中 "yes" 是默认行为，不写等价于写了。

Edge 基本同步 Chrome 行为；Firefox 不支持该属性，但其内置翻译功能本身较弱，多数用户依赖插件——而主流插件（如 Google 翻译）也遵循 W3C 规范，只响应 translate="no"。

translate="NO"、translate="No"、translate="no "（尾部空格）均被忽略
<meta name="google" content="notranslate"> 对 Chrome 内置翻译无效，仅影响 Google 搜索页和部分插件
JS 动态设置 document.documentElement.translate = "no" 不触发重解析，纯属无效操作

`<input>` 和 `<textarea></textarea>` 的 `value` 为什么总被误译

这两个元素的 value 属性是明确的继承例外：哪怕父容器设了 translate="no"，<input value="v5.2.0"> 里的 v5.2.0 仍可能被 Chrome 翻成“五点二零”。因为浏览器把 value 视为独立文本源，不参与 DOM 继承链。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

必须显式在标签上加：<input value="XZ-3000" translate="no">
若 value 是 JS 动态赋值（如 el.value = "fetch()"），需同步调用 el.setAttribute("translate", "no")
<button>Deploy v5.2.0</button> 中的文本属于元素内容，可继承父级 translate，但 <input type="button" value="Deploy v5.2.0"> 的 value 不继承，必须单独标

lang 属性配错，`translate="no"` 就形同虚设

Chrome 在语言上下文模糊时会降级处理：如果页面是中文，但标签没写 lang，或写成 lang="zh"（缺区域码）、lang="en"（与实际内容矛盾），它可能判定“语言不可信”，直接跳过 translate="no" 指令。

整页禁译最稳组合：，且必须出现在初始 HTML 中
局部保护时，<code lang="en" translate="no">useState 比单写 translate="no" 更可靠——lang 提供可信上下文，translate 执行动作
不要以为 lang="en" 就等于“不用翻”：一个中文页里嵌 <div lang="en">React</div>，Chrome 仍可能把它译成“反应”，因为没下禁译指令

动态内容和第三方组件最容易漏掉 `translate="no"`

用 innerHTML、appendChild()、Vue 的 v-html、React 的 dangerouslySetInnerHTML 插入的节点，不会自动继承父级 translate 设置。浏览器只在首次解析 HTML 时读取该属性，后续插入的 DOM 必须手动补全。

v-html 渲染的富文本中，translate="no" 依然生效，但前提是原始 HTML 字符串里已包含——服务端或 CMS 输出时就得带上，前端 runtime 补不了
Ant Design、MUI 等组件库输出的 DOM 可能自带 translate 属性，覆盖前务必 inspect 实际渲染结构，不能只看模板源码
验证是否生效，别靠肉眼：打开 Chrome DevTools → Elements 面板，查目标元素上是否真实存在 translate="no" 属性，且没有被 JS 动态移除

真正容易被忽略的，是那些看似“已经包住”的场景：比如给整个 <pre class="brush:php;toolbar:false;"></pre> 加了 translate="no"，但里面嵌了个 <input value="API_KEY">——这个 value 依然裸奔；又比如 CMS 输出的代码块 HTML 已含 translate="no"，但前端用 innerHTML 二次拼接时删掉了它。