This patch injects javascript that defines Date.month, Date.monthAbbreviations,
Date.dayNames and Date.dayAbbreviations with values from DateFormatSymbols.
With these definition the date string generated by the javascript calendar is
always a valid date that can be parsed by java's dateparser. So the list of
supported languages are then no longer needed.
Regarding the remaining translations, I would *strongly* prefer that they were
read from the DateField property file and injected into the javascript the same
way as month names. So that all string are translated in the same way.
+1 for this Java approach (for all languages of course).
It's the same way it's done for the CountrySelect control, where it's
the responsibility of the JDK to generate the country names and country
ISO codes (it does that for much more languages we could possibly
translate to).
Even, more, IMHO if there are other i18n messages in the JDK that we
could re-use in other components, it might be a good idea to collect
that info in a WIKI page, so that future components don't have to
"reinvent the wheel" :).
Adrian.
