Currently my System Locale is en-UK, it used to be en-US (I've restarted my computer for this change to be in effect)
When I print Locale.getDefault().getCountry().toString() I still get US though.
In the API it states:
getDefault()
Gets the current value of the default locale for this
instance of the Java Virtual Machine.
Maybe the JVM locale is not related to the system locale? If so, how do I get the system locale on Windows?
Edits:
after researching the other questions about this, I found it useful to say that I'm dealing with Java 6.
I've just found that on my OS (Windows 7) the System locale change is not reflected in Java, but the Control Panel > Region and Language > Formats change is reflected.
I've overlooked something, in production code the osgi.nl config attribute is set, changing what Locale.getDefault would return otherwise
Your JVM locale and System locale can indeed possibly be different.
When the JVM is first loaded it assigns its locale to be the same as the system's locale unless you specified otherwise on the command line (not all implementations let you do this).
You can see what the value of this JVM locale is from Locale.getDefault().
In case you want to change that you can: Locale.setDefault("<preferred_locale>") read more about it here.
The system locale setting depends on the OS that you are using. I don't know much about Windows but, you can see what the values are from System.getEnv(). It returns a Map<String, String> of all environment properties and you can look for something like LANG or GDM_LANG, etc.
The country variant is taken from the "Non-Unicode" settings in the extended dialog of Windows locale.
There was is bug in Sun JDK 6u27+ and JDK 7, BugId 7073906:
The Locale returned from Locale.getDefault() is en_US when it shoud be en_GB.
I think this is what is biting you here :)
I realized in production an argument WAS being set that altered the Locale.getDefault() return value. This was difficult to check/prove.
My solution was that the user.country and user.language were not changed and reflected the actual Locale.
Locale locale = new Locale(System.getProperty("user.language"),System.getProperty("user.country"));
Locale.setDefault(locale);
//this will do the trick for me
Big thanks to everyone who answered and commented.
Related
When debugging my application, if found that DecimalFormat and DateFormat are set to use nl_NL by default, but the system locale seems to be en_US.
I found the first by evaluating:
new DecimalFormat().symbols.locale
new SimpleDateFormat().locale
And the second:
Locale.getDefault()
System.getProperty("user.country")
System.getProperty("user.language")
What is happening there?
How can I set those formatters to use a certain locale by default? (I'm writing unit tests and would like to set a specific locale without touching the application code)
As of Java 7, the default locale comes in two categories: "DISPLAY" and "FORMAT".
Both are initially set according to the environment. They can be found by calling Locale.getDefault(Category).
Besides the system properties mentioned in the question:
"user.country"
"user.language"
The following can also be present when running the JVM:
"user.country.format"
"user.language.format"
"user.country.display"
"user.language.display"
The reason for that seems to be that some OS's allow independent localization settings for displaying text and for formatting dates, numbers and currency.
Answering my last question, by calling Locale.setDefault(Locale) the default locale will be set for all categories.
I am coding a simple java chat app. Is there any possibility of knowing the language user types in order to choose appropriate font?
Something like
Locale locale = InputContext.getLocale();
String language = locale.getLanguage();
But you must rely on the locale setting. I'm here on a German locale, but I'm happily typing English.
I've created an app in two languages. The second one (english), is used when user's default system language is english. If it's not, then the first one is used.
I want to set the second language (that's english) as a DEFAULT language,
which means that when user opens my app and his system language is not the first one, nor English, the English language will appear as a default one.
I tried:
Locale locale = new Locale("en_US");
Locale.setDefault(locale);
Configuration config = new Configuration();
config.locale = locale;
context.getApplicationContext.getResources().updateConfiguration(config, null);
But got "context cannot be resolved" error everytime.. Is this piece of code right or..?
Okay,
to make everything clear,
I realized res/values is a DEFAULT directory and the others are just "in case of language". So everything I had to do was to switch the english to /res/values and the other language goes to res/values-es
You should define all languages you support using res folders, i.e res/values, res/values-en, res/values-fr. The system will take care of everything else, you don't need any code.
If you are in an activity you can do:
this.getApplicationContext().getResources().updateConfiguration(config, null);
...to fix your error.
Otherwise you need to pass in the context.
Make sure you add the parenthesis at the end of getApplicationContext(). You didn't do so in your code.
I've been in the same situation, my app was first created in portuguese (BR) so we went global and I had as second language En-Us, so my solution was creating a new language ( clicking in translation Editor + Brazil )... so I have my default language (Portuguese) second (English) third (Portuguese)
then I replaced the resource/ values to the english strings setting as default...
I got one application that can switch language between English and Germany. When in Germany language i want the currency display will auto convert into German format. Therefore in my program i have to do checking for the locale then convert the currency based on the language selected. I choose to use locale.setDefault() but i not sure whether this will has any risk or not based on below statement which i found. Can somebody advise for this?
Statement:
"Since changing the default locale may affect many different areas of functionality, this method should only be used if the caller is prepared to reinitialize locale-sensitive code running within the same Java Virtual Machine."
Thanks.
That warning means that if you've already had code that initialized based on a different locale, then it won't magically hear about the locale change and update. For example, if you already set up your title bar and menus and button labels in English and then call setDefault(Locale.GERMANY), all of the text will still be in English. Your example sounds like you won't be changing the locale after startup, so just make sure that you call setDefault early, before you do anything that depends on the locale.
In my application, I'm using java resource bundle for the translation of its labels.
I currently have two files:
resources.properties with labels in English (default language)
resources_fr.properties with labels in French
Then, I load the bundle properties with the following command:
ResourceBundle.getBundle(RESOURCE_BUNDLE_NAME, locale);
... where locale is the user's locale.
When I'm working with a French web browser, that's ok, I'm getting all my messages in French, as my locale is correctly set to fr.
But when I switch my browser to English US, they're still in French!
The locale variable is correctly set with the en_US locale, but the getBundle method returns me a bundle with the fr locale instead of just returning the default bundle...
Is it a normal behaviour? I'm very surprised, as I was expecting the English values of resources.properties to be used when the locale has no specific resource bundle attached to it (like French)...
It is the normal result, which is nevertheless quite surprising if you haven't read the (rather lengthy) description of getBundle carefully. The important part is:
If no matching resource bundle is found, the default control's getFallbackLocale method is called, which returns the current default locale. A new sequence of candidate locale names is generated using this locale and and searched again, as above.
This is a bit unexpected. Only after having tried with the default locale in addition to the specified locale, the method does what you would expect:
If still no result bundle is found, the base name alone is looked up.
This is a reasonable behavior for a desktop application. After all, if you have succeeded in starting a Java application given the machine's default locale, you should know how to handle the application if it comes up using the default locale instead of the one that you have specified. But if your application is a web server and the server's locale is used instead of the preferences that you have specified in your browser, the resulting page can be quite a puzzle.
The proper way to handle this is to suppress the usage of the fallback locale. You could do this in your code by specifying the additional argument ResourceBundle.Control.getNoFallbackControl(ResourceBundle.Control.FORMAT_DEFAULT), resulting in
ResourceBundle.getBundle(RESOURCE_BUNDLE_NAME, locale,
ResourceBundle.Control.getNoFallbackControl(
ResourceBundle.Control.FORMAT_DEFAULT));
(I usually define a constant for the additional argument somewhere when I need this more than once.) This results in the behavior that you were expecting.
This might help to clarify your question:
http://docs.oracle.com/javase/tutorial/i18n/resbundle/propfile.html
These Locale objects should match the properties files created in the
previous two steps. For example, the Locale.FRENCH object corresponds
to the LabelsBundle_fr.properties file. The Locale.ENGLISH has no
matching LabelsBundle_en.properties file, so the default file will be
used.