Exception in DatePickerLanguageResourceReference.getJsFilename when used with "en" locale

[GoogleCodeExporter]

When the locale only contains "en" and no country, then 
DatePickerLanguageResourceReference.getJsFilename throws an exception because 
DatePickerLanguages.getDatePickerLanguages(locale) couldn't find a locale to 
use.

It all works fine though if I use any other locale without country .. "de" for 
example.

DatePickerLanguages.getDatePickerLanguages(locale) should probably return the 
default locale (english) and not null.

Original issue reported on code.google.com by patrick....@gmail.com on 9 May 2011 at 4:00

[GoogleCodeExporter]

Original comment by hielke.hoeve on 10 May 2011 at 12:10

• Added labels: Release-1.2.4

[GoogleCodeExporter]

Hi Patrick,

Which version of WiQuery are you using? WiQuery 1.2.3 no longer throws an 
exception. It checks to see if there is a resource for the current locale. If 
there is not then it will simple continue without adding a language resource.

I added extra unit tests to 1.2-SNAPSHOT to ensure that all language files can 
be loaded and that no exception may occur without letting the testcase fail.

I also stumbled into an ugly piece of Java core code. Hebrew and Indonesian 
Locales are manually translated to their old ISO code, which means the jquery 
resources files cannot be found as the iso code is translated. I copied the 
files and renamed them to reflect this translation.

Original comment by hielke.hoeve on 10 May 2011 at 1:17

• Changed state: Fixed

[GoogleCodeExporter]

Yeah, we are using WiQuery 1.2.3 .. the latest stable release.

Are you sure that it doesn't throw an exception anymore? 
DatePickerLanguageResourceReference looks like this on my machine:

private static String getJsFilename(Locale locale) {
    DatePickerLanguages dpl = DatePickerLanguages.getDatePickerLanguages(locale);
    if(dpl == null){
        throw new WicketRuntimeException("The locale cannot load the required javascript locale file");
    }

    return DatePickerLanguages.getJsFileName(dpl).toString();
}

The following locale throws an excpetion on the page where I'm using the 
DatePicker:

Session.get().setLocale(new Locale("en"));

The following two work just fine:

Session.get().setLocale(new Locale("de"));
Session.get().setLocale(new Locale("en", "US"));

Original comment by patrick....@gmail.com on 10 May 2011 at 2:13

[GoogleCodeExporter]

I checked out the sourcecode for WiQuery 1.2.3 and there is also the "throw 
WicketRuntimeException" statement:

http://wiquery.googlecode.com/svn/tags/1.2.3/src/main/java/org/odlabs/wiquery/ui
/datepicker/DatePickerLanguageResourceReference.java

But I guess it doesn't matter anymore since you just closed this issue without 
waiting for my response :-/
Guess I either wait for version 1.5 (which has this fixed) or use another 
framework...

Original comment by patrick....@gmail.com on 12 May 2011 at 8:19

[GoogleCodeExporter]

1) I didn't close the issue, I merely set it to status fixed so other 
committers won't waste time analysing the issue.
2) If you had waited a bit longer I would have responded to your issue saying:

WiQuery 1.2.3 does indeed throw an exception, I meant WiQuery 1.2.4. 1.2.4 no 
longer throws an exception, DatePickerLanguages and 
DatePickerLanguageResourceReference will return null when they cannot find a 
resource file corresponding to the locale. Users using 
DatePickerLanguageResourceReference for their own components should check for 
null. 

(Default language, embedded in jquery datepicker is en_us, there is no language 
en, only en_us, en_gb, en_au, en_nz and en_za.)

WiQuery 1.2.4 will be released soon.

Have a nice day.

Original comment by hielke.hoeve on 12 May 2011 at 9:45

[GoogleCodeExporter]

Thanks for the info. I didn't mean to sound harsh. I waited for 2 days and 
thought that the issue was silently dropped since it was set to "fixed" and 
nobody responded anymore.

Thanks and I'll be waiting for the 1.2.4 release.

Original comment by patrick....@gmail.com on 12 May 2011 at 2:48

[GoogleCodeExporter]

2 days isn't all that long, especially since we use our spare spare time to fix 
things.

Original comment by hielke.hoeve on 12 May 2011 at 3:26