(needs documentation) Provide Locale support for jQuery UI

Deal! Where would we get the dateFormat attribute?

#510334: Cache the sets of JavaScript/CSS in drupal_get_library() would be nice because then it wouldn't run the alter every page load.

Pushing to critical as we need some localization for the date picker.

drifter requested that failed test be re-tested.

This solution is too simple to not count as not critical. But we need to demote in case we don't get this in by March 1st. So let's get this in!

Just a pointer because it seems all the right people are in this issue and it seems very related: #488496: Implement missing msgctx context in JS translation for feature parity with t()

Just to clarify, we are not going to use the jQuery UI translation files but instead use our own? I do understand the lack of overlap between the translation files offered for jQuery UI and for Drupal.

There is absolutely no reason to use the translation files provided by jQuery, because we already have our own Javascript translation system. Using those files would make those translation not use the proper workflow (they will not be exportable as .po files, would not be imported when loading new languages, will not be modifiable by the translation UI).

RTBC-ing #11 (careful, not #13!).

Not sure, bu tit seem like Translating strings in JavaScript is the relevant documentation page.

The problem is that page is for 6.x, and I'm really not sure if we have to mention it there or create another page, any suggestion?

Here's a patch encompassing the changes from the last comment. Not sure if this should be its own issue or not, so leaving here.

JavaScript is added to the page in groups and inside of those groups by a weighting system.
jQuery UI has a weight of -11, so if you want the settings to go before that, you need to choose a weight of e.g. -12, and you also need to choose the same group. For example:
drupal_add_js($settings, array('type' => 'setting', 'group' => JS_LIBRARY, 'weight' => -12));
That should work.

Settings are always output at the end (see implementation of drupal_get_js), so this didn't do the trick.

If that's true, that's a bug.
If for some reason now a bug with drupal_add_js(), then at least with the documentation.

Setting to CNW just because the testbot is testing over and over and we need to figure out why. OK to retest later.

#21: 507502.patch queued for re-testing.

This patch is against 7.2. The js part has now been patched, probably as the result of another issue. What remains is the wrong indexing of the $libraries array and the order problem.

If it patches against 8.x-dev it can be rolled against both versions, if not some work has to be done to get a D8 patch.

The last submitted patch, 507502-31.patch, failed testing.

The changes of this patch look like we clearly forgot to add tests for the functionality. Of course, we can't test JS, but we can test expected loading of JS files.

#33: 507502-33.patch queued for re-testing.

datepickeri18n.patch queued for re-testing.

#33 should work when rerolled for the move to /core but that has not been done yet.

I was told to remove date translations from Date because core is handling this and am getting lots of bug reports because it isn't working. Webform dates are also being bitten by this #1326230: In webform with popup datepicker not appears the right translation. If we can't get this into core soon D7 contrib modules are going to have to go back to providing something themselves because it is totally non-functional the way it is on multilingual sites.

This is not a high priority for core, per se, but it is creating big problems down the line.

and now the patch :(

I tried the patch in #33 on D7 and it seems to work fine. The patch at #45 won't work in D7 because of structural changes. But I think they are essentially the same.

• The next thing we need here is an automated test to confirm the file is loaded properly. The test should fail without the patch, and pass with it.
• If someone could post a list of steps to manually test the issue--which demonstrate the bug before the patch--that would also be helpful.
• Finally, since this issue has gone through at least three different phases I can see, an issue summary would probably help as well.

Tagging as novice for any of the above.

And a patch with the solution as posted in #45 and its test from #49. Thus this is the patch as should get committed.

@fietserwin -- That's where my comment in #48 comes in, to crowd source the review. A clear summary/steps to test can bring in more eyes and get a patch in faster.

Also, an aside, I think KarenS probably has a good handle on Drupal issue queues. ;)
http://drupal.org/user/45874
http://certifiedtorock.com/u/45874

Looks great! Minor: We might want to stick a documentation code block in here to keep our PHP docs clean ;-) . Other than that, looks pretty good to me.

-4 days to next Drupal core point release.

- scope is per #17, #19 and #21. In short, if placed in head it will be placed before Drupal.settings which it accesses. I will add a comment.
- group has not been changed, that is already in the current version. I'm fine if we want to "solve" that in this issue as well. Note that not specifying it, will result in JS_LIBRARY.

If we can keep both a D7 and a D8 patch going, we can test the D7 patch using the Date Popup module in Date API. I tried doing that back in #46, but the patch has changed and won't work in D7.

This needs to be backported to D7 anyway, so it's not really extra work to do both.

#61 1) On load of the file, not the html document. This may indeed be confusing.

#61 2) Drupal.settings may be declared in core/misc/drupal.js, but is it is only filled (extend'ed) when the settings are rendered, which is indeed in JS_SETTING. So #63 will work, while #61 won't.

To be sure that the code in this file is executed after Drupal.settings has been extend'ed we could:

• Use the code as in #60 :).
• Use the code as in #63.
• Change #63 to something like group => JS_SETTING + 1 and leave out the weight, so we are absolutely sure it will be after the settings. IMHO this even better expresses that we want to be rendered after the settings.
• Wrap the javascript code in locale.drupal.js in a Drupal behavior, but I am not sure about the consequences (too late instead of too early?).

Pick your preference.

Hi,
Sorry, my english is too bad...
Is there any way to translate directly to other language? My web is only on spanish and the popup(dropdown) of the calendar is in english.
Thanks!

The last submitted patch, drupal-507502-67.patch, failed testing.

Some changes to the previous patch:
- locale.datepicker.js: placed the js code in in an attach behavior thereby preventing all the difficulties we had in assuring correct order.
- locale.module: as a consequence the changes to the code in locale_library_info_alter() could be simplified.
- locale.test: a test comment still referred to adding it to the footer.
- nodes.pages.inc: the addition to the node edit form (for test purposes only) no longer has to include group and weight.

Notes:
- Placing the js code in an attach behavior seems the right thing to do. It executes not too early but also not too late, i.e. before a user can popup a date picker. Even if another attach behavior would initialize a date picker right away, this behavior will execute earlier as it is registered earlier because it is in the JS_LIBRARY group.

- This issue is tagged as needs manual testing. Even in a clean D8 environment this is not too difficult because of sun's nice addition to the node edit form in this patch. enable language and locale, add a language, define a translation for the current month, add a basic page, and go to the authoring tab.

- The first day of the week setting is a setting that is not defined by the locale module. Yet, with the locale module disabled, this setting will not be passed to the date picker, but this should be filed as a separate error.

Tryed to translate calendar with patch for D7, but no luck. Has anyone succeeded?

Which patch did you use?

Actually I got it work, kind of, BUT I have customized calendar so it shows calendar straight at page (no popup). So problem is that translation works after user clicks/changes month and ofcourse it is not good.

Switch to 7.x to test patch #33. I will be resetting to 8.x afterwards.

#74: Apparently you are showing the calendar too early. At what moment are you executing the js to display the calendar? I guess it should be in a Drupal attach behavior. And even that may be too early as patch #33 places the code in the footer of the page. Patch from #70 should solve that as well, but is for D8. I will see if I can post a D7 patch based on #70 later this evening.

Rework of patch #70 for D7.

#78: 507502-78.patch queued for re-testing.

No idea what is wrong with my patch. It applies locally. It looks OK, but it fails....

Next try.

Aside: I think my my git diff does something wrong when the changes are at the end of a file. Does this ring a bell to anyone? I use git on windows and am using the git-gui and git bash that come with standard git.

#85: The D7 patch contains an error (a regression of an old patch: it still added the js file to the JS_THEME group instead of to the default JS_LIBRARY).

Comparing the 2 patches, I fond and removed a superfluous space in a comment in the D8 patch.

@ace11: can you confirm that the D7 patch works with inline datepickers, it did for me. That would be a great step forward to RTBC'ing this issue.

#87: For D7 use Localization update. For D8 just enter translation of 1 or 2 months/days via thelocal translation admin interface and/or change first day of the week.

Hmm... am I doing something wrong?

I tried to apply the patch as it is described at http://drupal.org/node/60818 and got this:

MyServer:drupalroot me$ patch -p0 < drupal-507502-86-D8.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/core/modules/locale/locale.datepicker.js b/core/modules/locale/locale.datepicker.js
|index 81f1e17..f819282 100644
|--- a/core/modules/locale/locale.datepicker.js
|+++ b/core/modules/locale/locale.datepicker.js
--------------------------
File to patch: q
q: No such file or directory
Skip this patch? [y] y
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 153
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/core/modules/locale/locale.module b/core/modules/locale/locale.module
|index 6d3ded0..928c98a 100644
|--- a/core/modules/locale/locale.module
|+++ b/core/modules/locale/locale.module
--------------------------
File to patch: ^C

Then I thought I should patch exactly the locale module and got this:

MyServer:drupalroot me$ cd modules/locale/
MyServer:locale me$ patch < drupal-507502-86-D8.patch
patching file locale.datepicker.js
patching file locale.module
Hunk #1 FAILED at 873.
1 out of 1 hunk FAILED -- saving rejects to file locale.module.rej
patching file locale.test
Hunk #1 succeeded at 2772 (offset -348 lines).
can't find file to patch at input line 232
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/core/modules/node/node.pages.inc b/core/modules/node/node.pages.inc
|index 4e94b26..897dd3a 100644
|--- a/core/modules/node/node.pages.inc
|+++ b/core/modules/node/node.pages.inc
--------------------------
File to patch:

What am I doing wrong? D
Do I have to roll back to last backup before trying to patch again?

My Drupal version is 7.12

Yep, the patch and the scheme ace11 described worked for me too. Now Datepicker is in Russian.

Changed texts as indicated, except this one:
Currently only the jQuery datepicker is localized, using Drupal translations.
to
Currently, only the jQuery datepicker is localized using Drupal translations.

There are no regressions in English, except for first day of the week which is now taken from the Drupal setting instead of the (jquery ui datepicker) default of Sunday.

If I'm correct, this is needed for the parser that creates the js files with the actual translations. Like you "may not" use $var = 'text'; $output = t($var); in your PHP.

Applied D7 patch from #86, works great. Thanks!

So, how do we get this in, if people only test in D7? Anyone who dares to set this to RTBC?

See file locale.module, function _locale_parse_js_file(). The regexp is explicitly looking for Drupal.t and Drupal.formatPlural.

What are your objections against the repeated use of Drupal.t? If it is file size, or actually response size, I would say that a minifier should do that replacement, even though there's not a (real) minifier in place right now.

Another option might be to allow Drupal.t to accept (multi-level) arrays/objects of strings to translate at once, returning the same structure, property names, etc.

Anyway, IMO that would be a separate issue and should not block this issue. After all we are talking a major bug here that is also present in the current D7 release.

Same here, patch on #86 works great on a D7 installation
Will this be added to D7 Core?

sorry, someone need to test for D8.

The last submitted patch, drupal-507502-94-D8.patch, failed testing.

The last submitted patch, 507502_106_local_jquery.patch, failed testing.

The last submitted patch, 507502_108_local_jquery.patch, failed testing.

screwed up the upload

Just change

There is no locale_test module and setUp seems to take any number of module names as strings to enable.

Looks good for D8

Re #119 being able to test this manually (which is required for JavaScript) is enough justification to include this with the patch.
It is also a big usability improvement on its own, but that is not the point.

(edit) The date format of the datepicker is totally wrong for the input, that code in node.pages.inc was for testing purpose.

Patch looks good and I agree about not adding the datepicker here at all.

Committed/pushed to 8.x, moving to 7.x for backport.

There is one extra space on the last } in the JS file but beside that it's good to go.

Works for me :) 507502-129-D7.patch is the one to commit.

Thanks, that worked for me.