HTML国际化本身不提供反馈能力，所谓“反馈”必须靠额外机制实现——比如表单提交、埋点上报、A/B测试分流，或结合用户行为日志做语言偏好归因；需在切换函数中手动埋点（如trackEvent）、同步更新localStorage、区分前端校验文案与后端错误码、确保toast提示延后至语言包加载完成，并避免混淆浏览器自动翻译等非可控行为。
HTML国际化本身不提供反馈能力，所谓“反馈”必须靠额外机制实现——比如表单提交、埋点上报、A/B测试分流，或结合用户行为日志做语言偏好归因。没有这些，你只能知道“页面切到了zh-CN”，但不知道用户是否看懂、是否愿意切换、是否因翻译质量差而流失。
怎么让语言切换动作可追踪
用户点击「中文」按钮后，你得确认这个操作被记录下来，而不是只改了DOM。否则无法判断是UI问题还是翻译质量问题。
-
data-i18n标记本身不带事件，必须手动在切换函数里加console.log或调用埋点函数，例如：trackEvent('lang_change', { from: 'en-US', to: 'zh-CN' }) - 别只监听按钮点击——用户也可能通过 URL 参数（
?lang=ja）或 localStorage 自动切换，这些路径也要覆盖 - 如果用了
document.documentElement.lang = 'zh-CN'，记得同步写入localStorage.setItem('preferred-lang', 'zh-CN')，否则下次刷新就丢失上下文
表单类反馈怎么和多语言共存
用户提交的反馈内容是中文，但表单字段名、错误提示、成功文案仍需按当前语言渲染——这两者不能混为一谈，否则后端收不到结构化数据。
- 表单
name属性永远用英文（如name="feedback_content"），这是后端解析依据；label和placeholder才走data-i18n翻译 - 前端校验错误信息（如“邮箱格式不正确”）必须从语言包读取，不能硬编码；但后端返回的业务错误（如“该邮箱已被注册”）需单独设计 i18n 错误码映射表
- 提交成功后的 toast 提示，要等语言包加载完成后再显示，否则可能闪出英文再变中文——可在
fetch(langJson).then(() => showSuccess())里控制
哪些“反馈”容易被当成国际化功能，其实不是
很多团队误把浏览器自动翻译、插件弹窗、甚至 Google Translate 的 iframe 当作国际化落地成果，结果发现用户根本不用、或者用了反而更困惑。
立即学习“前端免费学习笔记（深入）”；
-
navigator.language返回zh-CN不代表用户想要简体中文——可能是系统语言没改，也可能是海外华人习惯用英文界面；必须允许显式覆盖 - 纯靠
[lang="zh"] .btn::before { content: "提交"; }这类 CSS 方案，无法支持 placeholder/title/alt 等属性，也不能处理含 HTML 的文案（如“请阅读服务条款”） - 没设
document.documentElement.lang就直接切文本，屏幕阅读器仍按旧语言朗读，对视障用户等于没切
真正难的不是替换文字，而是让每处语言变更都留下可观测痕迹：哪个用户在什么页面、什么时间、因什么触发了切换、切换后做了什么操作、有没有再切回去。这些数据链断了，后续迭代就只能靠猜。
