HTML本身不支持插件化i18n，必须依赖JavaScript驱动；i18next通过可插拔模块（如backend、languageDetector）实现扩展，HTML仅用data-i18n等属性配合定位内容。
直接说结论：HTML 本身不支持插件扩展的国际化（i18n）框架——它只是静态标记语言，没有模块加载、运行时钩子或插件注册机制。真要做可扩展的 i18n，必须靠 JavaScript 驱动，HTML 只负责承载占位和数据绑定。
为什么不能只用 <html> 或 <meta> 实现插件化 i18n
HTML 没有执行能力，<script> 标签引入的 JS 才是实际干活的主体。常见误区是试图用 <link rel="i18n" href="zh.json"> 这类自定义标签“声明式加载”，但浏览器会忽略它，既不解析也不触发回调。插件机制依赖运行时注册（比如 addPlugin()）、翻译函数拦截（如 t('key') 前被中间件处理）、或模板编译阶段介入（如 Vue 的 v-t 指令），这些全在 JS 层。
i18next 是最接近“插件友好”需求的成熟方案
它把核心逻辑拆成可替换/可叠加的模块：backend（加载翻译资源）、languageDetector（自动识别语言）、formatter（格式化日期/数字）、postProcessor（对翻译结果二次处理）。每个都是独立 npm 包，比如：
-
i18next-http-backend：从/locales/{{lng}}/{{ns}}.json加载 JSON -
i18next-browser-languagedetector：读取navigator.language或 cookie -
i18next-sprintf-postprocessor：支持%s占位符
使用时只需 i18next.use(...).init(...)，顺序决定执行链。自己写插件也简单：导出一个含 type（"backend"/"postProcessor"）、init() 和具体方法的对象即可。
立即学习“前端免费学习笔记（深入）”；
HTML 中怎么配合插件化 i18n 工作
HTML 不是被动容器，而是要主动参与数据流——关键是用语义化属性让 JS 能精准定位和接管内容：
- 用
data-i18n标记需要翻译的节点：<p data-i18n="welcome.message"></p> - 用
data-i18n-options传参数：<span data-i18n="count" data-i18n-options='{"count": 5}'></span> - 避免内联文本：
<button>Submit</button>→ 改为<button data-i18n="form.submit"></button>，否则 JS 无法覆盖原始文字 - 动态插入内容必须调用
i18next.t()或触发domUtil.translate()，不能靠初始 HTML 渲染完就万事大吉
容易被忽略的复杂点：插件间的生命周期与竞态
比如你同时用了 i18next-http-backend（异步加载）和 i18next-browser-languagedetector（同步获取语言），但 init() 时没设 fallbackLng，用户首次访问可能因资源未加载完而渲染空字符串。更隐蔽的是：某个 postProcessor 插件修改了 key 格式（如加前缀），但 backend 插件仍按原 key 请求，导致 404。这类问题不会报错，只会静默失败——得靠 i18next.on('missingKey', ...) 监听才暴露出来。
