我有一个简单的 native Visual C++ 程序，它使用 .mui 文件来实现资源本地化。如果我在 SetThreadPreferredUILanguages 中请求 fr-fr，Windows 会在 fr-fr 子目录中找到我的 prog.exe.mui 文件，并正常使用它。但是，如果我只请求 fr(无区域设置)，尽管 Windows 看到了资源文件(由 GetFileMUIPath 验证)，但它拒绝使用它，并转到最终的后备语言。如果我请求 fr-ca，并且只有 fr 可用，它会拒绝使用它。
这种情况也发生在“es”上，我想象任何“中性语言”。它确实适用于“vi”，所以这不是两个字母的问题，但我认为这是因为 vi 是一个实际的语言环境，而不是一种中性语言。 Windows 7 和 Windows 8 下都会发生这种情况。
在准备 .mui 文件、资源或调用 SetThreadPreferredUILanguages 时，我应该做一些与其他 4 字母规范不同的事情吗？这太基本了……我错过了什么？？
最佳答案
经过多次痛苦的实验，我得出的结论是，尽管 Windows 很乐意接受并报告所谓的中性语言(例如“fr”)，但它实际上并不是以这种方式寻找它们。
如果系统正在运行“fr-ca”，但某个程序只有可用的“fr-fr”，Windows 会聪明地使用“fr-fr”。但如果它只有一个“fr”文件夹，Windows 将不会使用它。如果在 SetThreadPreferredUILanguages 中显式请求“fr”，它会愉快地接受它，并愉快地从 GetThreadPreferredUILanguages 报告它。它会愉快地列出可从 GetFileMUIPath 获取的“fr”。但它不会用它做任何富有成效的事情，甚至不会寻找“fr-fr”。
简单的答案:不要尝试使用“fr”或“es”或任何其他“语言中立”的术语。您必须始终完全指定区域设置，并且根据不言而喻的协议(protocol)，诸如“fr-fr”之类的内容被视为中性。
关于windows - 无法让 Windows 使用中性语言 MUI？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17905416/