2

I have a simple native Visual C++ program that uses .mui files to implement resource localization. If I request fr-fr in SetThreadPreferredUILanguages, Windows finds my prog.exe.mui file in the fr-fr subdirectory, and uses it fine. But if I request just fr (no locale), although Windows sees the resource file (as verified by GetFileMUIPath), it refuses to use it, and goes to the ultimate fallback language. If I request fr-ca, and only have fr available, it refuses to use it.

This happens for "es" as well, and I imagine any "neutral language". It does work for "vi", so it's not a two-letter issue, but I think that's because vi is an actual locale, not a neutral language. This happens under both Windows 7 and Windows 8.

Is there something different I'm supposed to do in preparing the .mui files, the resources, or calling SetThreadPreferredUILanguages than I do for every other 4-letter specification? This is so basic ... what am I missing??

Machavity
  • 30,841
  • 27
  • 92
  • 100
Dev93
  • 668
  • 1
  • 6
  • 18

1 Answers1

3

After much painful experimentation, I have come to the conclusion that although Windows will happily accept and report on so-called neutral languages (e.g., "fr"), it does not actually look for them in that way.

If the system is running "fr-ca" but one's program only has available "fr-fr", Windows will do the smart thing and use "fr-fr". But if all it has is a "fr" folder, Windows will not use it. If one explicitly requests "fr" in SetThreadPreferredUILanguages, it will happily accept it, and happily report it back from GetThreadPreferredUILanguages. It will happily list "fr" as available from GetFileMUIPath. But it will not do anything productive with it, not even look for "fr-fr".

Simple answer: do not attempt to use "fr" or "es" or any other "language neutral" nomenclature. You must always fully specify the locale, and by unspoken agreement, things like "fr-fr" are considered neutral.

Dev93
  • 668
  • 1
  • 6
  • 18