Wrong detection of locale de_CH


I am using Xojo.Core.Locale.Current in a WebApp to detect the users locale and get the currency sign from it.

Somehow Xojo detects the locale de_DE if a user from Switzerland (locale de_CH) comes in. Does somebody know why?

Best regards


Why do you think it is wrong? It is not unusual for Swiss users to select de_, fr_ or it_ over the Swiss option when setting up their machine. And indeed if it is business machine you may find that you get an en_ returned as many Swiss companies have English as their working language and some even go as far as defining which version of English they accept. Thus all the machines in the company may be installed US English, but they want to use certain apps in German, more in French etc…

As someone who has sent 30 years developing software in Switzerland, I have found it is best to allow the user to select their own settings. There are far too many user combinations out there to try and guess it.

Hi James,

thanks for your reply.

The detection is technically wrong.
I setup a testmachine and configured chrome to have de_CH as locale. I verified that my configuration is correct using http://www.localeplanet.com/support/browser.html.

But Xojo still shows locale de_DE instead of de_CH

Sorry, I assumed you were taking about desktops.

Ah. no, sorry. Its a WebApp

Xojo.Core.Locale.Current gives the local of the server the app is running on and not the connecting client.

… but you can get the client’s locale by addressing the session object.

Thanks Jason. This could explain my problem.

Ulrich, are you sure? I think I can only get the language code from the session

A user could write code to extract the locale from received headers that are stored on the session object and then they could create a correct locale object using that data. But, that isn’t Xojo.Core.Locale.Current as the original poster tried.

ah I see, I could use session.Header(“Accept-Language”)

thank you very much

You’re welcome Fabian. I’m not sure that will include the locale but it’s worth a try. The feature request would be to parse the locale out of the headers as they are received and have a new Session property (not to set a locale).

What I did is something like

dim locale as new Xojo.core.locale (session.languagecode.totext)

I maybe wrong, but browsers address only the language. The notion of locale, with particularities such as thousands separators like apostrophe instead of space (1’000,00 or 1 000,00) , does not seem supported by default.



This is probably addressable with user preferences.

You are right. It works fine for me because I need the “de” locale only, but this would not help the OP getting a Swiss locale.

The Accept-Language Header has the full locale code (de-CH in this case)