Bug? Getting the preferred language of a user & SystemStats::getUserLanguage()

General JUCE discussion
1

Hi

In the latest version of JUCE SystemStats::getDisplayLanguage() and SystemStats::getUserLanguage() are not getting the preferred language of the user in Windows 10 or 11.

getUserLanguage() is getting the locale and getDisplayLanguage() is displaying the installed languages of the operating system (Windows display language).

More info at: https://stackoverflow.com/a/73551640

In Windows the language settings for Apps look like this:

image
image950×684 10.7 KB

So in my opinion this is the value that SystemStats::getUserLanguage() should return. This value can be retrieved with the following code:

#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.System.UserProfile.h>
#pragma comment(lib, "windowsapp")

using namespace winrt;
using namespace Windows::Foundation;
using namespace Windows::System::UserProfile;

for (const auto& lang : GlobalizationPreferences::Languages())
{
  language_code = String(lang.c_str());
  break;
}
1 Like
2

I have just tested it. It seems that:

  • On Windows, getDisplayLanguage() returns the “Windows Display Language”
  • On macOS, getDisplayLanguage() returns the first “Preferred Language”
3

Hi,

Thanks zsliu98. I’m getting the same results. I had more time to test today. I confirm for Windows that JUCE in its latest code (develop) doesn’t provide a method to return the user preferred language in Windows.

Proposal for the JUCE team: what do you think about making SystemStats::getUserLanguage() return the preferred language for the user and renaming the current SystemStats::getUserLanguage() as “SystemStats::getUserLocale()” to avoid any confusions?

4

Hi JUCE team,

Have you considered this change to make SystemStats::getDisplayLanguage()more consistent among OS’s and to able to use it to get the preferred language in Windows?

BTW GlobalizationPreferences::Languages() was making the Maschine plugin scanner crash, so the valid code would be (checks if the winrt class is available):

#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.System.UserProfile.h>
#pragma comment(lib, "windowsapp")

using namespace winrt;
using namespace Windows::Foundation;
using namespace Windows::System::UserProfile;

auto statics = winrt::try_get_activation_factory< winrt::Windows::System::UserProfile::GlobalizationPreferences, winrt::Windows::System::UserProfile::IGlobalizationPreferencesStatics> ();

if (statics == nullptr)
{
    // Language detection failed
}
else
{
    for (auto const& lang : statics.Languages())
    {
      language_code = String(lang.c_str());
      break;
    }
}
5

I’m not sure what we should do here. I think the current behaviour of getUserLanguage and getUserRegion will probably remain unchanged, since it matches the documented behaviour (returning locale info). I’m also leaning towards keeping the current behaviour of getDisplayLanguage(), since it seems reasonable to return the global “Windows display language” here. If we were to make changes in this area, I think we’d probably add some new API to return the complete fallback list of languages, but given that this has potential to introduce new crashes (as you discovered) it might have to wait until we have a bit more bandwidth.

6

Thanks for the quick reply!

Yes but it is confusing because getUserLanguage is getting what Windows calls the “Regional format”. getUserLocale would have been less confusing as the name of this method IMHO… Still, I do agree that a separate method to get the list of preferred languages might be a better option.

image
image1031×740 10.5 KB

1 Like