jQuery datepicker should be using the locale

[zodiac1978]

If a plugin (or a theme) is using/enqueuing the datepicker from WP core, all the strings (name of month, etc.) are English and not localized.

It would be great to also have these files integrated with it:
​https://github.com/jquery/jquery-ui/tree/master/ui/i18n

Maybe this is plugin territory, but as 4.0 has a strong focus on l18n I just want add that idea.

[ocean90]

Related: #7665

[zodiac1978]

Here are two different solutions to the problem:
​http://wordpress.org/support/topic/adding-translation-to-ui-datepicker
​http://www.renegadetechconsulting.com/tutorials/jquery-datepicker-and-wordpress-i18n

The first one is using the "official" jQuery l18n with a fallback to English if the l18n is not available. Of course the files could be served through WP instead of the jQuery CDN in our case.

The other one is using WP internal l18n for most of the stuff.

[markjaquith]

I like the second solution. I e-mailed the author of that post to see if they would be willing to release the code samples to us under the GPL.

[clubduece]

I am the author of the post referenced by Mr. Jaquith, and would be happy to contribute the code.

[zodiac1978]

I will try to provide a patch this week.

[wycks]

+1 I use this a lot. But a simpler solution by way of just using the default call in .datepicker . It would be nice to just have the i18n script available in WordPress.. I use it like this:

// code that checks page language
$( selector ).datepicker( $.datepicker.regional[ "fr" ] ); //french
//or
$.datepicker.setDefaults( $.datepicker.regional[ "" ] );  // restores default language

[iseulde]

@zodiac1978, did you make any progress here? Thanks!

[zodiac1978]

Replying to iseulde:

@zodiac1978, did you make any progress here? Thanks!

Sorry, but no. I need some starting help with the script loader.

The syntax is different there. In a theme/plugin I would use
​https://codex.wordpress.org/Function_Reference/wp_script_is

But I don't know if this is the right way here.

[swissspidy]

The proposed solution in #14853 would help here a bit, I think.

Using the potential wp_add_inline_script we could override the default settings of the date picker to use the WordPress locale. That way plugin developers don't have to do anything, it would just work.

Otherwise there wouldn't be a real benefit compared to just using the solution explained in ​http://www.renegadetechconsulting.com/tutorials/jquery-datepicker-and-wordpress-i18n in a plugin.

[barryceelen]

Inspiration for a PHP to jQueryUI date format conversion (via Stack Overflow of course): ​https://github.com/barryceelen/wp-events-toolkit/blob/develop/class-events-toolkit-meta-box-date.php#L348

[swissspidy]

29420.diff​ is a proof-of-concept patch using wp_add_inline_script() and wp_localize_script() to automatically set the defaults for jQuery UI date picker.

Note: #20558 would make the localizing part easier.

Also, this might seem like plugin territory, but we might need this in core eventually. See #7665.

[zodiac1978]

Replying to swissspidy:

Also, this might seem like plugin territory, but we might need this in core eventually. See #7665.

I don't think this is plugin territory.

Plugins can implement different solutions with leads to a different UX. If we provide a core solution we provide consistency.

There are plugins which provide a datepicker without using any localization, these plugins would benefit from this core solution.

[ocean90]

I'm fine with committing something like 29420.diff​ to trunk. But there needs to be a dev-note on make/core too. Maybe @zodiac1978 want's to prepare the post?

Can someone provide a demo plugin which uses the datepicker?
29420.diff​: Non-array entries are using esc_js(), the arrays not. Should this be array_map( 'esc_js', array_values( $wp_locale->month ) )? Is esc_js() even needed?

[barryceelen]

Created a demo plugin ​https://github.com/barryceelen/datepicker3000 which adds a date meta box to the post edit screen.

Adding get_option( 'date_format' ) to $datepicker_args won't cut it though as jQuery UI uses a different format ​http://api.jqueryui.com/datepicker/#option-dateFormat.

[ocean90]

@barryceelen Thanks for the plugin and nice catch with the date format!

29420.2.diff​ converts the PHP date format into jQuery UI's format. It also removes the $scripts->localize() call and passes the data directly into $scripts->add_inline_script().
We have to check whether $wp_locale is set otherwise it will cause a fatal error when SCRIPT_DEBUG is false.

@zodiac1978, @barryceelen: Can you give 29420.2.diff​ another test?

[ocean90]

29420.3.diff​ might be a better approach.

[swissspidy]

+1 to using a separate function for this.

29420.4.diff​ updates the DocBlock and renames the function to wp_localize_jquery_ui_datepicker().

[zodiac1978]

Replying to ocean90:

But there needs to be a dev-note on make/core too. Maybe @zodiac1978 want's to prepare the post?

I'm happy to help with a post. @ocean90 Could you scan the plugin repo for plugins using the jQuery l18n files, so we can ping the plugin authors that they can remove the code? (See: ​https://github.com/jquery/jquery-ui/tree/master/ui/i18n )

It looks like https://core.trac.wordpress.org/attachment/ticket/29420/29420.3.diff is still having some issues with the date format. I get "dateFormat":"d. MM yy" for German - but this should be dateFormat: "dd.mm.yy",

And we could add these three parameter:

weekHeader: "KW",
showMonthAfterYear: false,
yearSuffix: ""

The last two parameters are used from the Japanese, Korean and Chinese languages. Maybe someone from these communities can help here, if this information is stored in WP.

I've tried the patch from @ocean90 with Contact Form 7 and the HTML5 fallback (which just enqueues the jQuery datepicker) and besides the mentioned problems it works very fine so far.

[barryceelen]

@ocean90 Cool, seems to work as expected!

I guess it is somewhat unfortunate that it is not possible to use ordinals S (st, nd, rd) as that is not supported by the jQuery UI date format. Plugin developers can set their own format and/or callback on insert to provide that kind of stuff so I'm not sure if that is an issue in the context of this ticket.

Perhaps the function doc should point out the fact that a one-to-one mapping is not possible, or is it expected from devs to have this figured out already?

@zodiac1978 The d. MM yy (j. F Y) german date format comes from the german translation files (and appears to be an accepted date standard according to ​https://en.wikipedia.org/wiki/Date_format_by_country).

[barryceelen]

Remove monthStatus option

[barryceelen]

29420.5.diff​ removes the removed monthStatus option (​https://jqueryui.com/upgrade-guide/1.7/#datepicker).

[barryceelen]

Check if jquery-ui-datepicker is enqueued

[barryceelen]

Only doing the localization stuff if jquery-ui-datepicker is actually enqueued might save some trees.

29420.6.diff​ moves the function to late in the wp_enqueue_scripts and admin_enqueue_scripts in stead and checks if wp_script_is( 'jquery-ui-datepicker', 'enqueued' ).

[zodiac1978]

Replying to barryceelen:

@zodiac1978 The d. MM yy (j. F Y) german date format comes from the german translation files (and appears to be an accepted date standard according to ​https://en.wikipedia.org/wiki/Date_format_by_country).

Yes, "j. F Y" would be "13. Juni 2016", and this would be "d. MM yy" but "13.06.16" (dd.mm.y) or "13.06.2016" (dd.mm.yy) would be a better (short) format for a datepicker.
See ​http://api.jqueryui.com/datepicker/#utility-formatDate for other possible parameter.

But I don't see one of those formats in Firefox/Mac. I am always seeing "2016-06-13" ("yy-mm-dd").

[barryceelen]

Replying to zodiac1978:

But I don't see one of those formats in Firefox/Mac. I am always seeing "2016-06-13" ("yy-mm-dd").

Just checking: Are you using the ​test plugin? The plugin still requires a patch​ to be applied for the formatted date to show up.

[zodiac1978]

Replying to barryceelen:

Replying to zodiac1978:

But I don't see one of those formats in Firefox/Mac. I am always seeing "2016-06-13" ("yy-mm-dd").

Just checking: Are you using the ​test plugin? The plugin still requires a patch​ to be applied for the formatted date to show up.

This is my testing setup:

I've tried the patch from @ocean90 with Contact Form 7 and the HTML5 fallback (which just enqueues the jQuery datepicker) and besides the mentioned problems it works very fine so far.

CF7 with HTML5 fallback activated (so jQuery UI datepicker is enqueued/used for browser without native datepicker like Chrome) and using a form with a date input field.

So I am not using your plugin but I am using the patch of course.

[barryceelen]

Replying to zodiac1978:

I've tried the patch from @ocean90 with Contact Form 7 and the HTML5 fallback (which just enqueues the jQuery datepicker) and besides the mentioned problems it works very fine so far.

I installed Contact Form 7 to have a peek: Contact Form 7 sets the the dateformat option to yy-mm-dd in its scripts.js file:

if (_wpcf7.jqueryUi && ! _wpcf7.supportHtml5.date) {
        this.find('input.wpcf7-date[type="date"]').each(function() {
                $(this).datepicker({
                        dateFormat: 'yy-mm-dd',
                        minDate: new Date($(this).attr('min')),
                        maxDate: new Date($(this).attr('max'))
                });
        });
}

This overrides the default being set by the patch. The defaults will only apply if the plugin author does not set a value for any of the defaults. Thus, for existing plugins to make use of the defaults they would need to remove their presets.

[swissspidy]

Thanks for investigating! We really should use the test plugin to have the same base for discussion.

Also, we should only add sane defaults and leave things like weekHeader up to plugin developers.

[mantismamita]

Tested patch using plugin and a variety of languages and although I can only attest to correct language formats in English and French. The first day setting is also applied.

[zodiac1978]

Replying to swissspidy:

Thanks for investigating! We really should use the test plugin to have the same base for discussion.

Also, we should only add sane defaults and leave things like weekHeader up to plugin developers.

Great catch @barryceelen. Thank you very much and sorry for the trouble. I will now use your test plugin.

Like @swissspidy said, we can leave the weekheader for plugin devs. +1 for this. Just wanted to mention this option.

[ocean90]

In 37908:

I18N: Localize the jQuery UI datepicker.

This provides some default data for the jQuery UI datepicker. The localized data is already available via WP_Locale and is only passed to the datepicker if the script is enqueued.

Props clubduece, swissspidy, barryceelen, ocean90.
Fixes #29420.

[Ipstenu]

Since I was asked, the following gists are to plugins that use i18n files for datepicker.

• Full list of all datepicker translation files: ​https://gist.github.com/Ipstenu/46b2154e9592c10c6a4f36d27e34b60a
• List of just the plugins themselves: ​https://gist.github.com/Ipstenu/30e9ccf3bd656aa202eb4d037c62c979 (105 plugins)

Some of these plugins are closed but this is everything I was able to find. A handful of people have them in bower folders that aren't being used (which is part of why I hate bower/vendor folders...).

[gsexton]

Does this provide any relief for the CSS problems associated with the Date Picker:

​https://wordpress.org/support/topic/jquery-ui-datepicker?replies=1

[barryceelen]

@gsexton This patch adds automatic translation of the date picker. It does not add any styles.
I guess no styles are currently provided because the date picker is not used by WordPress core (yet? see #7665).

For an example of adding your own styling to the date picker, have a look at an ​example plugin which uses a ​WordPress specific date picker skin by XWP.