lang属性是浏览器翻译的“语言身份证”，决定模型选择与提示弹出，而非开关；必须严格符合bcp 47标准且与主内容一致，否则触发降级识别或跳过翻译。
lang属性不触发翻译，但决定用哪个模型处理文本
浏览器翻译功能是否弹出提示、用什么语言模型翻译，lang属性是第一判断依据——它不是开关，而是“语言身份证”。Chrome、Safari、Edge 都在 HTML 解析初期就读取 ，之后所有翻译决策（包括跳过、误判、嵌套错翻）都基于这个值做上下文锚定。
常见错误现象： 但页面主体是英文，用户点“翻译成中文”，结果英文被先用中文模型“译一遍”，再被强行“译回英文”，出现 "login" → "登录" → "log in" 这类语义坍塌；又或者整页日文却写 lang="ja-JP"（非法格式），导致 Safari 直接跳过翻译流程。
实操建议：
-
的lang必须与当前渲染内容的主语言严格一致，且必须符合 BCP 47 标准：用zh-Hans或zh-CN，不用zh_CN、chinese、zh - 服务端渲染（SSR）阶段就必须输出正确值；JS 动态修改
document.documentElement.lang对 Chrome 翻译完全无效——它只读一次 - 多语言混排时，局部内容必须显式覆盖：
<blockquote lang="de"></blockquote>、<code lang="en">、<figcaption lang="fr"></figcaption>
为什么写了 lang="en" 页面还是被当成中文翻译？
这不是浏览器“没读懂”，而是你给的信号和内容冲突，触发了降级策略。Chrome 在检测到 lang 声明与实际文本语言特征（如词频、标点、空格分布）明显不符时，会弱化 lang 优先级，转而依赖启发式识别——但这种识别对短文本、代码块、无空格语言（如泰语、高棉语）极不可靠。
典型场景：
- 英文文档中夹一段中文术语表，但没给
<section lang="zh-Hans"></section>，整段被按英文模型处理，中文被切词错乱 -
<pre class="brush:php;toolbar:false;" lang="bash"></pre>——bash不是合法 BCP 47 语言标签，浏览器 fallback 到父级lang，注释里的英文被当成目标语言翻译，变量名全崩 - 用户浏览器语言设为中文，页面
lang="en"但全是中文，Chrome 可能静默跳过翻译提示，或把中文当“英文乱码”二次误翻
translate="no" 怎么用才真正禁掉翻译
translate="no" 是唯一被 Chrome 真正识别的禁译指令，但它不是万能胶布——生效有强前提：必须搭配准确的 lang，且必须出现在初始 HTML 中。
常见失效原因：
- 只写
<div translate="no">，但父级 <code>没设lang或设错，Chrome 认为“语言不可信”，直接忽略translate - 用 JS 动态插入节点，比如
el.innerHTML = "<p>API_KEY</p>"，新<p></p>不会继承translate="no"，必须手动加translate="no" - 写成
translate="false"或translate=""—— 合法值只有字符串"yes"和"no"，其他全无效 -
有效，但必须写在原始 HTML 里；JS 改document.documentElement.translate无意义 - 长按任意文字 → “检查元素”，确认
有且仅有一个合法lang（如en、de、ja），不能是zh或空 - 在空白处长按，看能否唤出“复制”菜单；若点不动，说明文字是
<canvas></canvas>、图片或 SVG 渲染，Safari 根本无法提取文本 - 进“设置 → Safari 浏览器 → 翻译”，关闭“在设备上翻译”——iOS 16.4+ 的本地模型
en2zh.mlmodel若校验失败，会静默禁用整个翻译入口，连云端都不显示
Safari 翻译不起作用的三个硬性条件
Safari 的翻译链路比 Chrome 更脆弱，它要求三个条件同时满足：页面含合法 lang、文字是真实 DOM 文本、本地翻译模型未损坏。缺一不可。
排查步骤：
真正容易被忽略的是：Safari 不像 Chrome 那样容忍宽松声明，lang="en-US" 可以，lang="en" 也可以，但 lang="english" 或 lang="en_US" 就直接失效——它不报错，只是彻底不走翻译流程。
