There is no way to get the user’s locale through Juce. Such functionality would allow one to load a correct LocalizedStrings translation file without user intervention.
There have been similar rumblings to get this done over the years but nothing seems to have come out of those attempts.
Getting language and country
Getting a user’s location and language…
std::locale
The C++ standard library has a locale class. It does not give the user’s current locale properly on all platforms. The locale string given is platform dependent and on Windows it is in an undesirable form.
std::locale userLocale("");
cout << "User Locale: " << userLocale.name() << endl;
On my en-US Windows machine this returns:
Microsoft has decided to give full names rather than 2-3 letter codes.
On my en-US OS X and iOS machines this returns:
I have been unable to figure out how to access the user’s locale on OS X via std::locale.
Design
static String LocalizedStrings::getUserLocale();
The string this function returns would be in the form of:
-
would be a lowercase 2 or 3 letter language code (ISO 639-1 or ISO 639-2 respectively)
would be an uppercase 2 letter country code (ISO 3166-1 alpha-2)
Implementation
I will begin by implementing this in OS X, iOS. Then move on to Vista and later which uses a newer recommended API. Then move on to XP which will require using an older API.
I don’t have access to a linux or Android machine so I’m hoping someone can help out for those platforms. This should be simple enough on Android with the Locale class. Not sure about Linux.
I finished the OS X, iOS, Vista and XP implementations.
I have psuedo-code for the Android implementation:
String LocalisedStrings::getUserLocale()
{
java.util.Locale userLocale = java.util.Locale.getDefault();
// We want locale names localized to US English
String language (userLocale.getDisplayLanguage (java.util.Locale.US));
String country (userLocale.getDisplayCountry (java.util.Locale.US));
return (language + "-" + country);
}
However, I’m not sure how the whole Juce JNI thing works.
Still not sure how to do this on Linux.
I’ve sent in my changes to Jules.
These changes have landed in Juce as:
SystemStats::getUserLanguage(), SystemStats::getUserRegion()
Thanks Jules for getting this in there!
Has anyone managed to get SystemStats::getUserLanguage() to display the correct system language? So far it will only display ‘en’. Or am I probably just not setting the system language properly? I’m working on OS X.
Seems right to me. Were you expecting it to say “English”?
The Juce docs (404 - Missing Page - JUCE) should be correct:
No I was expecting en, I’ve just been attempting to get my app to recognise different languages when setting my system to language to something other than English. If you can confirm that that is working for you, that’s fine. Probably just means I’m not setting the system language properly.
On Mac OS X, Windows Vista and Windows 7, the locale (language + region) and the display language are two separate things.
The SystemStats APIs are getting the locale as expected. I tested this on both OS X 10.7 and Windows 7.
There is no Juce API to get the OS display language.
This is probably why you are not getting the results you are expecting.
I can see the usefulness of getting the current display language so I’ll look into how to do this on the different OSes.
Reference Material
http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFLocales/Articles/CFLocaleConcepts.html
[quote=“sonic59”]I can see the usefulness of getting the current display language so I’ll look into how to do this on the different OSes.
[/quote]
That would be great thanks. On OS X, In terms of official Apple applications such as Safari and Logic Pro simply changing the display language changes the applications language, and this is also true of apps from the App Store which support multiple languages. On Windows 7 this also seems true for the default OS applications, as well as a few others such as Safari for Windows.
To me this seems like the best way to handle language support, and is much more user-friendly than having to change language within my application or supplying different builds for each language.
Got it working on OS X and Windows 7. According to MSDN, the APIs are good for 200/xp/vista.
Should be working on iOS as well. It builds fine but I wasn’t able to test due to some Introjucer/iOS Simulator bug.
As far as I can tell, both Linux and Android seem to just have Locales rather than Locale + Display Languages, so for those OSes I guess the method will just return whatever getUserLanguage returns.
I have sent off the changes to Jules.
Thanks, much appreciated! I’ll try it out as soon as the changes have been added.
The changes have landed into the Juce tip.
Works like a treat. Thanks again.
