昨晚升级系统又被一张“微软式中文”截图逗乐了。提示栏里每个字都认识，连起来却像刚学汉语的机器人写的作业——语法没毛病，意思就是不对味。

在编程语言堆里泡了这么多年，我越看越觉得这不只是个翻译事故。它暴露的是软件架构里一个长期被忽视的裂缝：我们把界面文本当成纯资源文件，却没把“说话时的上下文”也一并存进去。代码能跑、字符串能对上键名，可按钮是在问问题、下命令，还是在道歉？这层“语用信息”在编译和打包时常常被丢掉了。
抱抱
结果就是，翻译只能看到孤立的句子，看不到它站在哪个对话框里、前面发生了什么、用户接下来会被带去哪。于是诞生了大量“正确但离谱”的微软式中文。它和机器学习里的数据泄露有点像：模型不是不会生成，而是不知道自己在跟谁说话。

我倒觉得，我们可以把 UI 本地化当成一门小语言来设计。给每条字符串加上意图、听众和前后状态，就像给变量加上类型注解。也许短期内看起来是 overhead，但长远看，这是计算与人之间的一份契约。毕竟，代码可以优雅，它说出来的话也该体面。

你这波直接把本地化问题从“翻译翻车”拉升到“工程架构债务”的层面，说真的，绝了~我们平时在底层代码里摸爬滚打，其实早就被这破事按在地上摩擦过。GNU 那套 msgctxt 本来就是为了解决上下文丢失搞出来的，但你看开源项目里几个认真填的？大多留空或者瞎写，为啥？因为加 context 等于逼着开发改调用链、重跑提取脚本，这 overhead 对赶 release 的团队来说简直离谱。太！

哈哈哈你提的“意图+状态”注解，内核日志体系早就踩过类似的坑。早年 printk 全是裸字符串，后来干脆把设备路径、子系统标识全硬编码进去，翻译工具直接抓瞎。现在搞分层日志，把“机器调试信息”和“用户提示”彻底拆开，才算喘口气。UI 本地化其实也该这么干：静态文案走强类型契约，动态运行时状态直接绑定数据模型，别全扔进资源文件里当字符串汤炖。

不过架构再优雅，落地还是看工具链。现在前端搞 i18n 靠 ICU Message Format 能处理复数和占位符，但“语用信息”依然靠翻译靠猜。要是哪天构建工具能像 linter 一样，缺 context 直接 throw error，这事才算真正闭环。你们平时写业务，会专门给字符串写上下文标注吗？还是全指望本地化团队脑补？