1 - I've adapted a couple of datepicker language files (en, nl, de, fr, es, nb, da and sw) so that they now match with Zend. 2 - I've disabled the ucwords statement 3 - Ive added a method HasLocaleFile() to DateField_View_JQuery, that checks if the corresponding file exists. 4 - If no such file exists, and the dateformat has long/short monthnames, I replace the dateformat with 'yyyy-MM-dd': this makes datepicker add the date in numeric format, but after saving the set format using Zend is displayed. 5. I think I might add a 'preferred numeric fallback' to config that you can but need not set...
We then can at least safely use the following constants (and all kinds of litterals like - _ ; : , . and more ):
M, MM, d, dd y, yy, yyyy MMM and MMMM (monthnames) EEE, EEEE (daynames, as they need no validation it doesn't matter that the datepicker doesn't use them...) SS (seemingly untranslatable day prefix, as EEE, EEEE)
For me, that's what I initially wanted. Maybe there's more to be gained by tweaking convert_iso_to_jquery_format(), like linking other jQuery formats, but that will have to be tested.
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.
Yes - and for shortdates, I did test... :) They are different for different locales, so jQuery should know that, and it wont because it has no locale file, there goes the default (snake biting)
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.
True, labels don't matter.
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.
Yes, and jQuery doesn't understand FF or FFF or FFFF so it treats it as a litteral. Another job for convert_iso_to_jquery_format() ???
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.
That's a good tip for the docs, Ill keep that in mind. Still people are allowed to type in the Datefield, even if the calendar is enabled...
Good idea about tutorial to contrib your own localization overrides,
should just be a section in the DateField docs, linked from the i18n docs.
Where in the docs should the datefield live? in Reference I suppose?