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.

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.

You clearly seem to know this area very well. Can you summarize how it worked before and how it works (or does not work) now, so it can be seen by people reading the issue what are the incompatibilities?

@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 via the browsers declared locale which stays the same on any Drupal translation.

With that said, the jquery_ui_datepicker 2.x branch 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 gives us instead:

So in addition to having no translation at all is that the default jquery_ui solution 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 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.

Hey! I'm sure it's frustrating to run into this kind of thing.

This issue is also making several bad faith assumptions, and throwing "inferior"
into the issue title is just rude.

The work done to make this suite of modules Drupal 10 ready was not done by me, but
I it is really clever work! The approach removes the need to coordinate updates across
16+ modules, accounts for assets that may still be present on core, and was designed to
be minimally disruptive.
The issue you're experiencing here is *one* thing that slipped through that enormous undertaking
because datepicker + core has an additional edge case that requires an additional bit of logic.
It was truly easy to overlook considering is was a need unique to one library among many, many liraries.
The comments on this seems to presume it was somehow malicious or an intentional inconvenience? Nah. Just
a tiny thing overlooked in a huge undertaking.

Again, I understand the frustration, but this coming on a little hot, yea?
I have a patch that fixes this just sitting on my hard drive ready to upload, but it can wait until the tone here is
a little more respectful of the people that worked hard (and 99.9 percent succeeded) to
provide a solution that is manageable in the long term.

I remembered that ultimatums are not my style, and also realized that I'd be denying this fix to other users if I made this conditional on seeing a bit of civility. The patch is attached, but I sure wish this was brought to our attention with a little less 🖕 and a little more 🤝. Understanding the issue required wading through an unfortunate amount of grouchin' here and elsewhere.

The attached patch fixes it for me. This is the one place (to the best of my knowledge) where jQuery UI assets were not specified in core.libraries.yml, and I imagine that's why it was unintentionally omitted from the earlier release.

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

It seems that you've managed to bring in the locale.js approach that looks similar to the jquery_ui_datepicker solution which uses the Drupal.t strings perhaps making the i18n folder optional.

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 .

Nice job adding the localization js files. I extended this by loading the correct js for the active language (a little bit based on how ckeditor5 does it). Here also an updated patch file.

There were some encoding issues in the translation files. Here also a new patch.

It seems the upload of the patch file changes the encoding. No idea how to fix this. But in the fork the encoding seems good.

Patch #26 worked well. Fantastic work, thank you!

Hi
Patch #26 woked well too, Now I can switch between English and other languages; the translation works well on the datepicker

Thanks

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.

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.

Before patching with MR 10:

After patching 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

@joseph.olstad Thanks for the fix! Went looking for this to fix WCAG issues and found that you have already resolved it. The web team thanks you! Great work!

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!