implement datepicker localisation in jquery_ui 2.x, compare with jquery_ui_datepicker 1.x that has localisation

see patch, there's likely a composer way to do this that would be better.

this is for a quick win.

new patch, french only, patch 3 is not working

new patch

new patch

Ok so this hook has a limitation in that it only runs once even if you switch languages.

I haven't found an alternative, just throwing this patch up there for those that prefer any language other than English to show up in the date picker.

patch 9 wasn't good, this one will force another language other than English, same limitation, this hook only runs once regardless of the language being loaded.

ok patch 10 didn't work, but patch 12 should force another language other than English, same limitation, this hook only runs once regardless of the language being loaded.

This approach will only help those who are supporting one language other than english.

jquery_ui ui/i18n folder is missing, no translations available

patch 12 is a hack that forces a different language makes it consistently that language.

@Gábor Hojtsy ,

In the jquery_ui_datepicker 1.x branch the months, weeks and days were translated using Drupals t() function. This allows the date calendar weeks/days/months labels to match the language of the Drupal interface language rather than using the jquery_ui approach of loading the calendar language based on the browsers declared locale which stays the same on any Drupal translation. So if your locale is english you'll see an English calendar on a french or german translation. We prefer the calendar matches the Drupal interface language. However jquery_ui currently doesn't even have ANY locales, there's no i18n folder , no locales at all so we get zero locales except English.

The jquery_ui_datepicker 1.x approach is superior because it uses Drupals t() function for weeks, months, labels and respects the interface language for the current page. However the jquery_ui_datepicker 2.x branch is an empty shell, does nothing and relies 100% on the jquery_ui module to do the datepicker and the jquery_ui module does neither offer the i18n versions of the jquery datepicker nor does it use the t string approach that the 1.x jquery_ui_datepicker module used.

So basically if you use jquery_ui simultaneously with the 2.x branch of the jquery_ui_datepicker module then you have no localisation for the datepicker. The 2.x branch of the jquery_ui_datepicker is basically an empty shell offloading everything to jquery_ui and whoever published this branch gutted everything from 1.x.

This is the shortenned summary of the situation.

Here is what we expect:

Here is what jquery_ui module gives us instead:

So in addition to having no translation at all is that the default jquery_ui solution (even if it was implemented) normally relies on the browser language rather than the Drupal interface language. jquery_ui_datepicker 1.x solves all of this. See the source code for jquery_ui_datepicker 1.x branch for how it uses Drupals t functions for the labels.

So I've downgraded to jquery_ui_datepicker 1.x latest and jquery_ui_effects 1.x latest and am using patches to upgrade the library to 1.13.2
This resolves the issue for D9, but it will likely become a problem in D10 if we're forced to use the new approach.

@bnjmnm, thanks for the patch and for your extensive Drupal works, it looks good.

It appears that you've managed to bring in the locale.js approach that looks similar to the jquery_ui_datepicker solution (we prefer this approach). Perhaps making the i18n folder is optional at this point? Maybe a configuration option for the approach, so that those that want to use the Drupal.t string approach can use it exclusively.

I haven't had a chance to test it yet but will make an effort to do so as soon as possible and provide useful feedback.

For now we've got the 1.13.2 update with jquery_ui_datepicker with the 1.x branch.

Thanks again for the quick reply, I was expecting to have to do this by myself in 6 months from now when we start getting more serious about D10. So it is encouraging to have such a quick solution. I look forward to testing it.

Definately some great work on patch #26, I will attempt to draw attention to this from somewhat related issues that are open.

Patch 26 works well, testing it some more again today, it works well thank you

although I did upgrade simultaneously to the webform 6.2.x module and the webform 6.2.x module comes with the webform_jquery_ui_datepicker module so maybe there's some help from that module, my webform date pickers had the expected language calendar when using patch 26.

I'll have to re-test without patch 26 again .

Other than patch 26, you could also try the merge request patch:

https://git.drupalcode.org/project/jquery_ui/-/merge_requests/10.patch

MR 10 works well in french and english mode. The calendar follows the language of the page being loaded. So when I load the translated page (English) it shows up in English, when I load the original source language (French) the calendar days and months show up in French.

patch is still needed now that to use D10 we can no longer use the previous releases of the modules involved that had this working in D9.

So I'll mark this as RTBC for merge request 10.

Before patching:

After patching with MR 10 and rebuilding cache, no special settings were used, the js/locale.js is doing the work here, not the assets/vendor/jquery.ui/ui/i18n/datepicker*.js as that setting was not activated (nor needed).

MR 10 patch used:
https://git.drupalcode.org/project/jquery_ui/-/merge_requests/10.patch

Notice how in the before screenshot the weekdays are showing up in English (Mo, Tu, We, Th, Fr, Sa, Su) and the month shows up Feb.

After patching the expected French language days of week is loaded. (Lu, Ma, Me, Je, Ve, Sa, Di) and month abbreviation is correct as "Fév"

We do have an english version of this particular instance, the calendar still functions in English as expected after applying the patch.

Actually, all the props go to @bnjmnm , he wrote the new patch that fixes this, I may have re-rolled it.

but ya, important fix!

I've forked jquery_ui into a new project called jq_ui

This project jq_ui is a drop in replacement for jquery_ui.

For those that do not wish to use a patch, simply replace jquery_ui as follows (drop in replacement).

composer require drupal/jq_ui

With that said, I'll do the community type thing to do, provide a simpler, functional solution to any of those previously proposed above. This patch attached is for jquery_ui.

Diff from MR 22:

https://git.drupalcode.org/project/jquery_ui/-/merge_requests/22.diff

For those of us who are no longer going to wait another eternity for a release with a fix, a release of jq_ui is available now, this is an easy drop-in replacement for jquery_ui that I am now promoting.

https://www.drupal.org/project/jq_ui

Steps to replace jquery_ui:

Step 1) composer require drupal/jq_ui

Step 2) drush en jq_ui -y;

Step 3) drush cr;

Step 4) Sip from a marguerita

How is this possible you might ask? composer replace!

And here it is: On a silver platter for everyone!
https://www.drupal.org/project/jq_ui/releases/8.x-1.7

MR 10 has a lot of unneeded code.

MR 22 provides a solution and only has minimal changes to three files.

phpcs is passing with MR 22

@rajeshreeputra , appreciate your attention to this!

@rajeshreeputra, michel.g pointed out something we missed here. I'll push it up now.

diff --git a/jquery_ui.libraries.yml b/jquery_ui.libraries.yml
index 46bb48d..78b2c49 100644
--- a/jquery_ui.libraries.yml
+++ b/jquery_ui.libraries.yml
@@ -19,3 +19,4 @@ locale:
   dependencies:
     - core/drupal
     - core/drupalSettings
+    - core/jquery

@rajeshreeputra,

Please review the merge request.

Relates to work done for the jq_ui "replace" jquery_ui project by @michel.g that we should bring into jquery_ui.
#3545944: locale.js should depend on core/jquery

@rajeshreeputra, please add credit to michelg. It was michelg that pointed this out in the related issue but he hasn't been credited here for the solution.

https://drupal.org/u/michelg

@rajeshreeputra, please tag a new release for jquery_ui , it has been approximately 18 months since a tagged release!

@rajeshreeputra, I see you tagged 8.x-1.8 (Thank you), however you may have forgotten to create the release build , I still see 1.7 on the project page.

@rajeshreeputra, thank you very much!