Hi guys
Lately I've been wrestling with the DateField and the jQuery-UI DatePicker in an attempt tu use month shortnames in a different locale (dutch in my case). Numeric dates are not really a problem as long as we stick to the formats in Zend/Date.php (although I haven't tried them all), but character type dates like month shortnames do pose a problem:
First there are 3 separate units that have to work together:
- SilverStripe DateField
- Zend Date (and Locale)
- jQuery UI
Issue 1:
The jQuery-UI datepicker doesn't translate out of the box: DateField wants there to be a framework/thirdparty/jquery-UI/minified/i18n/jquery.ui.datepicker-nl.min.js file (path and filename hardcoded). At the moment they do not exist in SilverStripe but are easily downloaded here: http://jquery-ui.googlecode.com/svn/trunk/ui/i18n/ (or whereelse??).
Issue 2:
The Zend localization files can be found in thirdparty/Zend/Locale/Data/nl.XML Unfortunately, for Dutch at least, the shortnames are different from the ones in jquire-ui, so they'll never validate
Issue 3:
Zend Format uses iconv_strpos($number, $name, 0, 'UTF-8')) !== false) to check if the monthname is part of the Zend list of valid monthnames. Unfortunately this comparison seems to be case sensitive. And unfortunately again, DateField.php wants the first char of every word to be always uppercase (#203): if(is_string($val)) $val = ucwords(strtolower($val)); probably to make sure en_US dates always validate, but this again breaks Dutch validation
Last but not least: if you set the admin profile to dutch, Datefield will send the Dutch locale to Zend. Bottom line: now you cannot use shortdates or longdates, unless you make sure there is a jquery localization file, it is equal to the Zend version, and you disable the DatField ucword setting.
Maybe a small issue for most en_US people, still it took me quite a couple of hours, and I'd like to streamline this for SilverStripe. So how can we best do this, any advice?
Hi Ingo,
Zend_Date deals with ISO date formats, but the underlyingdata is in CLDR date format. They're 99% the same, but not fully. Yay.
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?
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 tutorialdescribing 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 needto put a warning label on the field (or remove it altogether).
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.
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),and/or the datepicker overrides?
Hi Ingo,Zend_Date deals with ISO date formats, but the underlyingdata is in CLDR date format. They're 99% the same, but not fully. Yay.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.
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 tutorialdescribing 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 needto 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.
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?
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),and/or the datepicker overrides?I've a couple of hours available and I'd like to try and come up with a working solution like the one above first. For the time being I've written up an overview on my blog (http://www.balbuss.com/jquery-ui-datepicker-in-silverstripe-3/). If I get this working, I'll do the tutorial afterwards.
That's true for stuff like month names, which I've suggested a solution for below.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.
For UI labels, jQuery UI will fall back to english. And for date format, we'repassing our own one into the jQuery UI config anyway, regardless ofwhether 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 tutorialdescribing 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 needto 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:<dateFormatLength type="short"><dateFormat><pattern>dd-MM-yy</pattern></dateFormat></dateFormatLength>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.
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 manuallyrather 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.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/-25vcnEFv5MJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.