DatePicker defaults to wrong Locale

[GoogleCodeExporter]

Here's a patch to solve the DatePicker default Locale problem described in this 
thread:
http://groups.google.com/group/wiquery/browse_thread/thread/2c738bfe2b60532e

Basically, the datepicker defaults to en_GB instead of en_US. And there is no 
way to change it back to en_US.  All this patch does is prevent the en_GB 
resource file from being included if the locale is en_US. It does not provide a 
way to change locales on the fly.

Index: src/main/java/org/odlabs/wiquery/ui/datepicker/DatePicker.java
===================================================================
--- src/main/java/org/odlabs/wiquery/ui/datepicker/DatePicker.java  (revision 
715)
+++ src/main/java/org/odlabs/wiquery/ui/datepicker/DatePicker.java  (working 
copy)
@@ -21,6 +21,8 @@
  */
 package org.odlabs.wiquery.ui.datepicker;

+import java.util.Locale;
+
 import org.apache.wicket.ajax.AjaxRequestTarget;
 import org.apache.wicket.markup.html.form.TextField;
 import org.apache.wicket.model.IModel;
@@ -142,9 +144,11 @@
        wiQueryResourceManager.addJavaScriptResource(WidgetJavascriptResourceReference.get());
        wiQueryResourceManager.addJavaScriptResource(DatePickerJavaScriptResourceReference.get());

-       wiQueryResourceManager
+       if (!getLocale().equals(Locale.US)) {
+           wiQueryResourceManager
            .addJavaScriptResource(new DatePickerLanguageResourceReference(
                getLocale())); // If locale is null or there is no translation, we will have the english version
+       }
    }

    /* (non-Javadoc)

Original issue reported on code.google.com by yowza...@gmail.com on 14 Feb 2011 at 4:56

[GoogleCodeExporter]

This didn't work in my production environment. It seems that getLocale() was 
returning null. Again, a null Locale should use the default DatePicker 
configuration, not the en_GB locale. So I improved the code to also detect null:

Index: src/main/java/org/odlabs/wiquery/ui/datepicker/DatePicker.java
===================================================================
--- src/main/java/org/odlabs/wiquery/ui/datepicker/DatePicker.java  (revision 
715)
+++ src/main/java/org/odlabs/wiquery/ui/datepicker/DatePicker.java  (working 
copy)
@@ -21,6 +21,8 @@
  */
 package org.odlabs.wiquery.ui.datepicker;

+import java.util.Locale;
+
 import org.apache.wicket.ajax.AjaxRequestTarget;
 import org.apache.wicket.markup.html.form.TextField;
 import org.apache.wicket.model.IModel;
@@ -142,9 +144,12 @@
        wiQueryResourceManager.addJavaScriptResource(WidgetJavascriptResourceReference.get());
        wiQueryResourceManager.addJavaScriptResource(DatePickerJavaScriptResourceReference.get());

-       wiQueryResourceManager
+       Locale locale = getLocale();
+       if (locale == null || !getLocale().equals(Locale.US)) {
+           wiQueryResourceManager
            .addJavaScriptResource(new DatePickerLanguageResourceReference(
-               getLocale())); // If locale is null or there is no translation, we will 
have the english version
+               locale)); // If locale is null or there is no translation, we will have 
the english version
+       }
    }

    /* (non-Javadoc)

Original comment by yowza...@gmail.com on 14 Feb 2011 at 6:58

[GoogleCodeExporter]

Many thanks

We will apply it for the next release

Regards

Julien Roche

Original comment by roche....@gmail.com on 14 Feb 2011 at 7:51

• Changed state: Accepted
• Added labels: Milestone-Release1.2.3

[GoogleCodeExporter]

Thanks for figuring out all the situations where the locale inclusion goes 
wrong. The problem also lies somewhere else though. 

The problem also lies in the DatePickerLanguageResourceReference class, line 
161. This checks for the Locale to be null or anything English (gb, us, au, nz 
etc) and translates it into EN_GB. This is obviously wrong. 

The DatePicker should not include any alternative locale resource as the 
default locale of DatePicker is encorporated in the jquery.ui.datepicker.js.

I have comitted a fix for this, which checks for locale being not null and not 
EN_US. And altered the DatePickerLanguageResourceReference not to change any 
locale. This will also fix the situations where people with, for example,  
EN_AU or EN_NZ having their locale changed to EN_GB as well.

Original comment by hielke.hoeve on 14 Feb 2011 at 10:27

• Changed state: Fixed

[GoogleCodeExporter]

Committed in revision 716.

Original comment by hielke.hoeve on 14 Feb 2011 at 10:28

[GoogleCodeExporter]

hielke, thanks for looking into this problem. I agree that en_GB should not be 
hardcoded.

However, the issue with just returning null in getDatePickerLanguages is that 
this will cause a WicketRuntimeException to be thrown in getJsFilename lines 
263 - 266. Since getJsFilename is called when attempting to instantiate a 
DatePickerLanguageResourceReference, an exception will be thrown when a null or 
en_US locale is used.

http://code.google.com/p/wiquery/source/diff?spec=svn716&r=716&format=side&path=
/trunk/src/main/java/org/odlabs/wiquery/ui/datepicker/DatePickerLanguageResource
Reference.java

Putting the locale test logic into DatePicker works fine as long as that's the 
only place DatePickerLanguageResourceReference is ever instantiated. If it is 
ever created somewhere else with a null or en_US locale, you'll run into 
problems. Then again, maybe this should be the expected behavior.

Regardless, it looks like your fix will solve my immediate problem. Thanks!

Original comment by yowza...@gmail.com on 14 Feb 2011 at 3:11

[GoogleCodeExporter]

Actually it will never throw a WicketRuntimeException as DatePicker line 149 
says 

if (locale != null && !getLocale().equals(Locale.US))

so if locale is null it will not attempt to add a resource. If there is a 
locale and it is not US it will, and so never reach 
DatePickerLanguageResourceReference line 265 where the WicketRuntimeException 
will be thrown. I have left this on purpose; if anyone is using the 
DatePickerLanguageResourceReference manually and incorrectly they will get get 
an exception instead of faulty behaviour.

Original comment by hielke.hoeve on 15 Feb 2011 at 9:27

• Changed state: Verified

[GoogleCodeExporter]

OK, I'm glad this was your intent. I alluded to this being the expected 
behavior in my previous comment. I just wanted to make sure it was intentional 
and not something you overlooked Thanks again. 

Original comment by yowza...@gmail.com on 15 Feb 2011 at 10:14

[GoogleCodeExporter]

I'm not sure this is fixed just yet.
What if the locale is just plain 'en' not en_US or en_GB
Then  DatePickerLanguages.getDatePickerLanguages(locale); will return null and 
getJsFilename(Locale locale) will throw a runtime exception

Original comment by vonk.th...@gmail.com on 22 Mar 2011 at 11:25

[GoogleCodeExporter]

I'm having exactly the same issue you mention on your last comment with 
Locale.ENGLISH ("en","","").

Following patch seems to fix it.

Original comment by reier...@gmail.com on 7 Apr 2011 at 10:33

Attachments:

• datepicker.patch

[GoogleCodeExporter]

Agreed! I changed the approach completely. Instead of doing an odd if check and 
throwing an Exception when no locale file is found we return either the 
resource or null when there is no js file for the given locale. This way we 
won't have if checks on 3 places but only at 1.

http://code.google.com/p/wiquery/source/detail?r=767

Original comment by hielke.hoeve on 13 Apr 2011 at 1:59

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by hielke.hoeve on 13 Apr 2011 at 1:59

• Changed state: Fixed