你有没有遇到过这种诡异的情况你在用某个软件的英文版界面上一行提示写着QUEUED全大写一看就很“强调”。然后你切换到中文版那行字变成了排队中——依然是全大写风格吗不是因为中文没有大小写。再切到某个欧洲小语种那行字变成了QUEUED的翻译但字母上带着奇怪的变音符号全大写之后那些符号被拉伸得歪歪扭扭看起来像乱码。你以为是翻译团队出了问题。其实不是。是代码在背后偷偷“改写”了翻译。VS Code 最近也发现了这个问题于是 把 AI 聊天面板里那些状态分割标题从全大写改成句子式大小写。问题出在哪VS Code 的内置 Chat 面板在 Agent 执行长任务、用户连续发消息的时候界面上会出现分割标题用来切分不同阶段的会话块QUEUED排队中、STEERING引导中、SYSTEM NOTIFICATION系统通知。这些标题在旧版里全是大写。实现方式非常粗暴渲染层拿到翻译文本之后直接调用toUpperCase()把整个字符串转成大写再显示。在英文环境下这看起来没问题。全大写确实显眼一眼就能和普通对话文本区分开。但一旦放到多语言环境里这个toUpperCase()就变成了破坏性逻辑英文翻译团队按句子式大小写规范写好了文案代码强行转大写直接推翻了规范。中文、日文、韩文这些语言根本没有大小写概念toUpperCase()是个空操作纯属冗余代码。带变音符号的小语种强制大写可能破坏特殊字符产生乱码。这个 vscode 的核心改动是删掉渲染层的大写转换逻辑让界面直接读取翻译文件里的原始文本。分割标题从QUEUED变成Queued从STEERING变成Steering从SYSTEM NOTIFICATION变成System notification。全大写英文可读性差所以原来加了一套letter-spacing字母间距来拉开大写字符。既然不再强制大写这套只服务于全大写的样式必须同步删掉。否则新文本会带着过大的字间距排版变得松散怪异。这背后是一个被大多数项目忽视的国际化原则翻译资源拥有最终文本表达权渲染层代码不能擅自改写文案格式。很多项目做国际化理解停留在“把中文换成英文”。但真正的本地化包含语种特有的字符规则、大小写习惯、排版间距、断句规范。前端为了适配英文界面随手加的大小写转换、字符裁剪、正则替换短期看英文效果很好长期看是在破坏其他语种的表达。英文世界里“用全大写强调状态”的设计习惯不能不加思考就平移到几十种语言上。你看到的是一行字的改动背后是 VS Code 对全球用户阅读体验的尊重。