Yes, I saw that one. In fact there seems to be only a limited range of Date constants that work with Zend and jQuery and can be persuaded to validate.
In this case, I opted to silently fail if the file is not available, and fall back to english.
Might just be a documentation issue on DateField.php?
I don't think so: Zends' isDate() function will then check the jQuery en version against its own current locale locale values, so only numeric dates will ever validate.
That's true for stuff like month names, which I've suggested a solution for below.
For UI labels, jQuery UI will fall back to english. And for date format, we're
passing our own one into the jQuery UI config anyway, regardless of
whether the <lang>.js file exists.
The easiest way I see to achieve this is to globally use Zend's "short" format,
which should be all numeric in most cases. We can then add a tutorial
describing how to correctly configure longer date formats in the CMS.
Users can set their own date formats (incl. month name abbreviations)
in their preferences - in the light of those changes, we might need
to put a warning label on the field (or remove it altogether).
Wow! Don't remove it - I still want it, and seeing the amount of questions on the forums, others do too :)
By Zend shortdate, do you mean DATE_SHORT = 'FF'? Because that format isn't recognised by the DatePicker, nor are (most of?) the other full or ISO-xxx dates. Using a format like 'MM dd yyyy' works fine and people can change it at will.
In nl.xml the short date format is defined as:
I don't think there's a unified definition of what a "short date" is across locales,
but from my western perspective I'd assume that it doesn't involve spelled out month names?
Either way, its not a great solution as it shortens the year to two digits, which is confusing.
Maybe we just need to add our own $.datepicker.regional overrides in DateField.js,
and make sure they match the Zend ones exactly? (and ensure they're loaded after the jQUI defaults).
That still leaves manual entry susceptible to case-sensitive validation, but its a start.
That's what I was thinking of. It isn't very hard to set up some localization files, at least for some of the most common languages for the DatePicker and have them match Zend. Then we could add some locale dependent settings to tackle the ucword issue and maybe set the locale to en_US if a localization file cannot be found. Next a small tutorial could explain how people can create/contribute their own?
I'd be in favour of removing the ucwords() invocation once we have the localization overrides in place,
its just too much complexity. In short, if you're expecting dates to be typed in manually
rather than selected from a calendar, don't use month abbreviations.
Good idea about tutorial to contrib your own localization overrides,
should just be a section in the DateField docs, linked from the i18n docs.
Martine, I'm unlikely to have much time for this in the next weeks.
Given that you're already so deep in the matter,
do you want to make a start on that tutorial (or improving the existing i18n.md docs),