多语言提示信息,最推荐用 `data-tip` 属性存 JSON 字符串。
怎么用?给元素加一个 `data-tip='{"en":"Enter email","zh":"请输入邮箱"}'`,JS 通过 `dataset.tip` 解析并按 `navigator.language` 匹配主语言码,缺失时 fallback 到 `en`。这样能避免多字段冗余、`title` 不可控、`href`/`src` 误用及 `dataset` 驼峰转换陷阱。

data-lang 属性配合 dataset API 动态读取提示文本
说到底,HTML 本身并不具备“根据浏览器语言自动加载不同提示”这个能力,这活儿得靠 JavaScript 来干。但我们可以用 `data-lang` 或类似的自定义属性,先把各语言版本存好,再用 JS 读取当前 `navigator.language` 去匹配。关键不是“自动加载”,而是“按需提取”。
很多开发者容易犯一个错误:把多语言字符串全写死在 HTML 里,比如:
这种写法字段爆炸、难维护,而且无法应对 `zh-CN` 和 `zh-TW` 的区分。
更推荐的做法是:
* **只用一个 `data-tip`,值为 JSON 字符串**:
* **用 `element.dataset.tip` 读取后 `JSON.parse()` 解析**,再用 `navigator.language.slice(0,2)` 取主语言码匹配
* **一定要有 fallback 机制**:当没找到对应语言时,回退到 `en` 或第一个可用键,否则会显示 `undefined`,用户体验很差
title 属性不适合做多语言提示的主载体
`title` 属性确实能触发原生 tooltip 提示,但它的问题也不少:延迟长、样式不能改、移动端基本不触发,而且搜索引擎和屏幕阅读器对它的解析很不稳定。更麻烦的是,`title` 是纯字符串,没法塞结构化语言数据。
如果你非得用 `title` 来实现多语言,唯一可行的方式是 JS 运行时动态设置:`el.title = tips[lang] || tips.en`。但这就等于绕过了 HTML 属性的初衷,还可能被 React/Vue 等框架的 DOM diff 覆盖。
需要注意的几个关键点:
* 别把翻译文本直接写进 `title` 里,比如 `title='请输入邮箱'`——这种做法会彻底锁死语言,用户切换浏览器语言后,提示还是中文
* 如果必须用 `title`,只留占位符,如 `title="{{email_tip}}"`,再由 JS 替换,但要注意 XSS 风险
* 从无障碍角度来说,`aria-label` 比 `title` 更可靠,而且同样支持动态更新
避免用 href 或 src 属性加载语言包
还有开发者试图用 `href` 或 `src` 属性来加载语言包,比如:
但这不是 HTML 属性的能力范围——`href`/`src` 触发的是资源请求,不是语言选择逻辑。是否加载、何时加载、加载失败怎么处理,全得靠 JS 控制。
这里有几个实用建议:
* HTML 属性只能提供静态元数据,不能触发异步行为;所谓“自动”,其实是 JS 根据 `document.documentElement.lang` 或 cookie 决定的
* 如果真要预加载,用 `rel="prefetch"` 或 `fetch()` 显式调用,而不是指望属性自己干活
* 注意缓存问题:同一页面多次切换语言时,别重复 `fetch` 同一 JSON,应缓存在内存或 `Map` 中
dataset 读取时要注意 key 名规范和大小写
`dataset` 的驼峰转换规则很容易踩坑。比如 `data-tip-zh` 会被转成 `tipZh`,`data-api-url` 变成 `apiUrl`。这个转换规则在遇到语言码含连字符时就容易出问题,比如 `data-tip-pt-br` 会被转成 `tipPtBr`,但代码里如果写 `el.dataset.tipPt-br` 就语法错误了。
几个实用技巧:
* **语言码尽量用下划线代替连字符**:`data-tip-pt_br` 会被转成 `tipPt_br`,这是合法的变量名
* **统一用小写语言主码**:`zh`、`en`、`ja`,避免 `ZH` 或 `zh-CN` 直接进 key 名
* **调试时打印 `console.log(Object.keys(el.dataset))`**,确认实际生成的 key 名,别凭感觉猜
说到底,多语言提示真正的复杂点不在 HTML 属性怎么写,而在于语言码映射策略——用户设了 `zh-HK`,该优先匹配 `zh` 还是 `zh-HK`?这个决策必须在 JS 层明确,HTML 只负责存数据,不参与逻辑。