纯 CSS 无法实现真正的多语言切换，因 content 属性仅支持静态字符串，无运行时语言检测、无变量、不读取 lang 属性查表；只能通过 [lang="xx"] 手动为每种语言硬编码 content 值，维护成本高且不支持运行时切换。
纯 CSS 无法实现真正的“国际化文字替换”，content 属性只支持静态字符串或 url()，不能根据语言环境动态读取翻译资源。所谓“减少 HTML 体积”的目标，在纯 CSS 路径下只能靠条件性隐藏/显示，而非翻译。
为什么 content 不能做多语言切换
你写的 content: "Hello"; 就永远是 Hello；写成 content: "你好"; 就永远是你好。CSS 没有变量、没有运行时语言检测、不读取 lang 属性值来查表——它只是把字符串原样渲染出来。即使配合 @media 或 [lang="zh-CN"]，你也只能手动为每种语言写死一套 content 值，维护成本极高，且无法应对新增语言或运行时切换。
常见错误现象：
- 开发者误以为
[lang="zh-CN"] .btn::before { content: "提交"; }是“自动翻译”，其实只是硬编码匹配 - 在 SSR 输出了
lang="en"的页面里，却漏写了英文版content规则，导致按钮空白 - 用
content插入带空格或标点的短语（如"Save & Exit"），在 IE 或旧 Safari 中因解析失败而整个伪元素不渲染
真正可行的轻量级替代方案
如果目标确实是“减少 HTML 体积”+“免 JS 切换”，唯一可靠路径是：让服务端输出正确 lang，再用属性选择器控制 content 显隐。但必须接受这是编译期决策，不是运行时国际化。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
使用场景限制明确：
- 仅适用于语言极少（≤3 种）、文案极短（单个词或短语）、且部署前就确定所有语言版本的静态站点
- 必须确保 HTML 根节点有准确
lang，例如 - 不能用于含 HTML 结构、换行、变量占位符的文案（
content不解析标签）
示例（安全写法）：
[lang="en"] .cookie-banner::before { content: "Accept cookies"; }
[lang="fr"] .cookie-banner::before { content: "Accepter les cookies"; }
[lang="ja"] .cookie-banner::before { content: "クッキーを許可"; }
.cookie-banner { font-size: 0; } /* 隐藏原始文本 */
.cookie-banner::before { font-size: 1rem; display: inline-block; }容易被忽略的兼容性与可访问性陷阱
很多人以为加了 [lang] 就万事大吉，实际落地时三个点最常翻车：
-
content值含 Unicode 字符（如 emoji、繁体字、阿拉伯数字）时，IE11 和部分 Android 4.x WebView 会静默失效，伪元素完全不出现 - 屏幕阅读器对
::before插入的content支持不一致：NVDA 读、VoiceOver 有时跳过，且无法通过aria-label补救（伪元素不可聚焦、无 DOM 节点） - 搜索引擎基本不索引
content生成的文本，SEO 效果归零——如果你指望靠这个提升多语言页面收录，会落空
所以，真要兼顾 SEO、a11y、多语言扩展性，哪怕多几 KB HTML，也该用 data-i18n + JS 加载，或服务端模板直出真实文本。CSS content 只适合图标、状态标记、纯装饰性文案这类“丢了也不影响核心信息”的场景。
