chrome自动翻译功能需五步启用：一、开启“提供网页翻译”开关；二、添加并设中文(简体)为默认语言；三、开启“询问是否翻译非您所用语言的网页”；四、添加英语并勾选“提供翻译此语言的网页”；五、清除cookie及缓存重置语言识别。
Chrome 等浏览器的自动翻译功能会把 fetch()、v5.2.0、/api/v1/users/:id 这类内容错译成中文，破坏技术准确性。直接加 translate="no" 是最轻量、最可靠的拦截方式，但必须理解它的作用边界和继承逻辑，否则反而会让本该翻译的按钮文案也失效。
translate="no" 的实际生效范围与继承规则
这个属性是可继承的：父元素设了 translate="no"，所有子元素默认也不参与翻译。但有两个常见例外必须手动处理：
-
<textarea></textarea>和<input>的value值不受父级影响，需单独加translate="no" -
<script></script>和<style></style>内部文本天然不被翻译，加该属性无效 - 若用
v-html或dangerouslySetInnerHTML渲染富文本，其中的translate属性仍生效，但得确保原始 HTML 字符串里已写好
哪些内容必须加 translate="no"？别靠猜
不是所有英文都该禁译。真正需要锁定的，是那些语义固定、大小写敏感、含符号或结构不可变的内容：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 代码标识符：
useState、async/await、npm install -D vite - 版本号：
v5.2.0、React 18.3（数字和点不能变成“五点二零”） - 路径与 ID：
/api/v1、user_abc123、XZ-3000 - 时间字符串（仅指机器可读格式）：
datetime="2024-06-15"外层建议套translate="no"，避免被转成本地日期格式 - 用户生成内容中的 token、密钥、base64 片段
为什么不要全局加 translate="no" 到 html>？
看似一劳永逸，实则埋下 UX 隐患：
- 按钮文字如
Submit、提示文案如Invalid email也会被跳过，导致多语言用户看到英文残留 - 第三方组件库（如 Ant Design、MUI）输出的 DOM 可能自带
translate，你加在上会覆盖其内部策略，引发不可预期行为 - 某些旧版 Edge 或翻译插件对全局
translate="no"支持不稳，不如局部精准控制可靠 - 真要全局禁译，优先检查是否页面本身就不该被翻译（比如纯英文技术文档），而非依赖 HTML 属性兜底
translate 和 lang 属性混用时的典型错误
很多人以为 lang="en" 就等于“不用翻译”，这是误解。lang 只告诉浏览器“这段当前是什么语言”，不控制翻译行为：
- 一个中文页里嵌了
<div lang="en">React</div>，Chrome 仍可能把它译成“反应”——因为没声明translate="no" - 正确写法是：
<div lang="en" translate="no">React</div>，明确表达“这是英文词，且不准动” -
translate="yes"几乎不需要显式写，W3C 明确说明未声明即默认为 yes；唯一例外是父级translate="no"下某子元素需破例可译，才加translate="yes"
最容易被忽略的一点：DOM 渲染后实际生效的是最终计算出的 translate 值，不是模板里写的那行。用 DevTools 检查元素 computed 属性，比看源码更靠谱。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
