jQuery UI integration

[psuter <petsuter@…>]

Ship ​jQuery UI with Trac. (I assume this is the plan, but I couldn't find a specific ticket. It was discussed before in light of these use cases: Search suggestions #9643, Tooltips #9648, Datepicker #2288, Column reordering #7026 and in general on the ​mailing list.)

Some points that may need to be addressed:

• What to include? (jQuery UI comes as a bag of interactions, widgets & effects one can pick and choose to create a custom package.)
• What theme to use? (jQuery UI offers a collection of standard themes and a ​custom theme roller.)
• What Advanced Theme Settings to use?
  • CSS Scope:

    This field allows you to specify a CSS scope to limit your theme to a particular portion of a page. This is helpful when using multiple themes on a page. If you don't provide a CSS scope, your theme will apply to all UI elements on a page. In most situations, you won't need to specify a CSS scope. Please Note: If you provide a CSS scope, you will not get an example page included in your download.

  • Theme Folder Name:

    This field allows you to specify a name for the theme folder in your download. This is helpful if you plan to use multiple themes on a page. It defaults to "theme".

• Where to place the files?
• Should we call add_script / add_stylesheet in trac.we.chrome.Chrome.prepare_request as for jQuery?

[psuter <petsuter@…>]

My best guesses:

• What to include?

Since one goal here is to offer the library as a service to Trac plugins, just include everything.

• What theme to use?

For Trac a custom theme would be needed that integrates nicely with the rest of the site. As a start, I put some ​semi-random values from trac.css in the themeroller, but it surely needs more work by someone more skilled in this.

• CSS Scope:

None(?)

• Theme Folder Name:

To get the directory layout described below: jquery-ui

• Where to place the files?

trac/htdocs/js/jquery-ui.js (The latest, full, minified jQuery) trac/htdocs/css/jquery-ui/jquery-ui.css (The custom theme CSS) trac/htdocs/css/jquery-ui/images/ui-*.png (The custom theme images. It seems like these must be located in an images folder next to the CSS file.)

Should we call add_script / add_stylesheet in trac.we.chrome.Chrome.prepare_request as for jQuery?

Yes(?) and add a CDN option jquery_ui_location similar to #10244.

[psuter <petsuter@…>]

Custom Trac jQuery UI theme in action (revealing room for improvement)

[psuter <petsuter@…>]

Replying to psuter <petsuter@…>:

Datepicker #2288

or #1942 actually.

The screenshot​​ shows the result of the above approach, available in ​this bitbucket fork (experimentally adding a milestone duedate datepicker to confirm it works). Besides jquery_ui_location, there's also jquery_ui_theme_location.

[osimons]

When we've looked at date pickers and various other UI widgets in the past, one recurring problem was that they lacked proper i18n support. Like the picker abbreviated day names, months and so on needs to be localized for each user. What's the status of jQuery UI and i18n?

[psuter <petsuter@…>]

Replying to osimons:

What's the status of jQuery UI and i18n?

According to ​jQuery datepicker documentation this should not be a problem:

Localization

Datepicker provides support for localizing its content to cater for different languages and date formats.

(But I have no prior experience with it.)

[lkraav <leho@…>]

i have used jquery datepicker, i18n works fine.

[psuter <petsuter@…>]

​This slightly tweaked theme fixes the more egregious problems. The following screenshots compare the experimental datepicker and the search suggestions from #9643 using:

• the initial theme from comment:1
• this tweaked version
• the UI Lightness theme

The prefab UI Lightness theme (which was for example initially used in #9643) is shown for reference. In my opinion it shows two things at the same time: How nice a good theme could look, and how out of place such a non-custom theme would look in Trac.

[psuter <petsuter@…>]

Datepicker and the search suggestions compared with custom and prefab themes

[Remy Blank]

Here's my take on your questions:

• What to include? (jQuery UI comes as a bag of interactions, widgets & effects one can pick and choose to create a custom package.)

Probably some kind of "full" package.

• What theme to use? (jQuery UI offers a collection of standard themes and a ​custom theme roller.)

Your theme already looks quite nice. I'm missing the border around the date picker and drop-down, and I think the "month switch" buttons should always be visible, not only on hover.

• CSS Scope:

Not necessary.

• Theme Folder Name:

• Where to place the files?

Your suggestion makes sense.

• Should we call add_script / add_stylesheet in trac.we.chrome.Chrome.prepare_request as for jQuery?

I'm not sure about that. On the one hand, jQuery-ui is huge, and takes a while to load (e.g. on refresh). But once cached, it only takes a few tens of milliseconds to parse. I would tend to prefer having it added conditionally when needed. You could add a method Chrome.add_jquery_ui() that would add both the script and stylesheet.

A few additional points:

• While the datepicker does support l10n, it requires loading an additional, language-specific .js file. These files would have to be included with the translation resources. The right language file could be added in Chrome.add_jquery_ui().
• The date in the datepicker currently doesn't correspond to the date / time format selected for Trac. Unfortunately, the date specifications aren't compatible, so we would have to generate the datepicker format from the Python format.

[psuter <petsuter@…>]

Replying to rblank:

Your theme already looks quite nice. I'm missing the border around the date picker and drop-down, and I think the "month switch" buttons should always be visible, not only on hover.

If I understand you correctly, that's exactly what the tweaked theme above (second row​) fixed.

I updated the branch on bitbucket to this tweaked theme now.

I would tend to prefer having it added conditionally when needed. You could add a method Chrome.add_jquery_ui() that would add both the script and stylesheet.

Done as well.

• While the datepicker does support l10n, it requires loading an additional, language-specific .js file. These files would have to be included with the translation resources. The right language file could be added in Chrome.add_jquery_ui().

Should we move the datepicker specific discussion to e.g. #1942? (I didn't really intend to include this datepicker here; it was just a convenient little hack for testing. Although I guess it would be good to have a use case in Trac itself.)

Concerning the l10n, I'm a bit lost. Will this need to be integrated with the Babel / .po files and javascript messages extraction? Or can we use the jQuery UI provided language-specific .js files as is? Again, should this be discussed on some other ticket where e.g. the translators would want to give their input?

• The date in the datepicker currently doesn't correspond to the date / time format selected for Trac. Unfortunately, the date specifications aren't compatible, so we would have to generate the datepicker format from the Python format.

I started a naive version of this (see bitbucket) but am not really sure what to do with the Babel patterns. Also note that jQuery UI only comes with a date picker, whereas this field currently wants a datetime. So far for testing I simply set the time to a fixed value.

[psuter <petsuter@…>]

Sorry, I noticed now that the ​linked bitbucket page above didn't really make it clear that there are two branches there:

• ​jquery-ui
  Contains what is really relevant here: the jQuery UI integration itself.
• ​jquery-ui-datepicker
  Contains the naively enabled (based on the jquery-ui branch) datepicker for testing / illustration purposes.

My apologies for the confusion.

[Remy Blank]

Replying to psuter <petsuter@…>:

If I understand you correctly, that's exactly what the tweaked theme above (second row​) fixed.

Ah, right, I got confused there. Yes, the tweaked version looks nice, and works fine with an ISO-8601 date format.

Should we move the datepicker specific discussion to e.g. #1942? (I didn't really intend to include this datepicker here; it was just a convenient little hack for testing. Although I guess it would be good to have a use case in Trac itself.)

We can keep it here. The datepicker is actually the most useful control in Trac at the moment, so I would like to include it by default.

Concerning the l10n, I'm a bit lost. Will this need to be integrated with the Babel / .po files and javascript messages extraction? Or can we use the jQuery UI provided language-specific .js files as is?

The ​translation files for the datepicker mix translations and formats, which isn't ideal. I would rather integrate with Babel, by having a jquery-ui-i18n.js that sets up strings using _("...") markers, and sets the date format according to the selected format in Trac. The same file could set up strings for other controls as well (if any).

I started a naive version of this (see bitbucket) but am not really sure what to do with the Babel patterns. Also note that jQuery UI only comes with a date picker, whereas this field currently wants a datetime. So far for testing I simply set the time to a fixed value.

The time should probably be left at the same value as before the edit. Translating the Babel patterns "automatically" is probably quite hard, but IIRC ISO-8601 is always supported, so we could just always use that format. Of course, the text in the edit box initially won't necessarily be in ISO-8601, so we may have to extract the value from somewhere else.

Replying to psuter <petsuter@…>:

My apologies for the confusion.

There was no confusion at all, actually :)

[psuter <petsuter@…>]

Replying to rblank:

I would rather integrate with Babel, by having a jquery-ui-i18n.js that sets up strings using _("...") markers, and sets the date format according to the selected format in Trac.

Something like this?

jQuery(function($){
        $.datepicker.regional['babel'] = {
                closeText: _("Done"),
                prevText: _("Prev"),
...             
                weekHeader: _("Wk"),
                dateFormat: 'ISO_8601',    // or `date_format` from script_data
                firstDay: first_week_day,  // from Babel `(locale.first_week_day + 1) % 7`
                isRTL: false,              // Babel has no right-to-left support yet, right?
                showMonthAfterYear: false, // ?
                yearSuffix: _("")};
        $.datepicker.setDefaults($.datepicker.regional['babel']);
});

(Is there a Trac / Babel setting for right-to-left languages?)

The time should probably be left at the same value as before the edit. Translating the Babel patterns "automatically" is probably quite hard, but IIRC ISO-8601 is always supported, so we could just always use that format. Of course, the text in the edit box initially won't necessarily be in ISO-8601, so we may have to extract the value from somewhere else.

Sounds tricky.

There was no confusion at all, actually :)

All the better. :)

[Remy Blank]

Replying to psuter <petsuter@…>:

Something like this?

Yes, exactly. You should probably also add a few TRANSLATOR: markers with comments for the less obvious strings (or even all). I don't know where we could get the showMonthAfterYear setting from, either.

(Is there a Trac / Babel setting for right-to-left languages?)

Not that I know of, but I'm no l10n expert.

Sounds tricky.

Yes, maybe it's not a good idea. Another option could be to use a trick like in get_date_format_hint()​ to generate the format string for the datepicker. To leave the time unchanged, you could implement the beforeShow() and onSelect() events to filter out the time before and add it back after the selection. You would still have to find a way to split the date from the time.

[Christian Boos]

Replying to rblank:

Replying to psuter <petsuter@…>:

If I understand you correctly, that's exactly what the tweaked theme above (second row​) fixed.

Ah, right, I got confused there. Yes, the tweaked version looks nice, and works fine with an ISO-8601 date format.

That version looks also quite perfect from my POV. Maybe the font could be made a bit smaller (1em instead of 1.1em)?

[psuter <petsuter@…>]

Replying to rblank:

Yes, exactly. You should probably also add a few TRANSLATOR: markers with comments

I tried this ​here, but as I don't even have Babel installed and know nothing about how to extract messages and so on, it would be good if someone who knows and cares about i18n could test this.

Yes, maybe it's not a good idea. Another option […] You would still have to find a way to split the date from the time.

But that's the problem, isn't it? Maybe it would be best to simply split the date and time into separate fields.

​Another approach that also avoids this problem would be to add the ​timepicker addon.

[psuter <petsuter@…>]

Replying to cboos:

Maybe the font could be made a bit smaller (1em instead of 1.1em)?

The custom theme roller above specifies the font size as 13px (copied from the body, th, tr { font: normal 13px ... rule from trac.css).

[Remy Blank]

Replying to psuter <petsuter@…>:

I tried this ​here, but as I don't even have Babel installed and know nothing about how to extract messages and so on, it would be good if someone who knows and cares about i18n could test this.

Thanks, I will test it.

​Another approach that also avoids this problem would be to add the ​timepicker addon.

Ooh, nice! I like it very much. The .js should probably be minified and placed at the end of jquery-ui.js. Same for the .css.

[psuter <petsuter@…>]

Replying to rblank:

I will test it.

Thanks!

Ooh, nice! I like it very much. The .js should probably be minified

Good idea. (Apparently jQuery uses the ​Google Closure Compiler for that. I guess I just paste it in there and press compile? Or does Trac already have another minification workflow in place?)

and placed at the end of jquery-ui.js. Same for the .css.

That could be a problem for externally located scripts and themes, as e.g. the Google and Microsoft CDN servers do not include the timepicker addon.

[Remy Blank]

Replying to psuter <petsuter@…>:

Good idea. (Apparently jQuery uses the ​Google Closure Compiler for that. I guess I just paste it in there and press compile?

I guess so. We don't have anything in place for that.

That could be a problem for externally located scripts and themes, as e.g. the Google and Microsoft CDN servers do not include the timepicker addon.

Ah, right, good point. So we keep it separate, then. I hope adding one more .js file won't make the page load much slower. But if it does, we'll start thinking about automatically combining and minifying .js and .css files.

[Christian Boos]

Replying to psuter <petsuter@…>:

Replying to cboos:

Maybe the font could be made a bit smaller (1em instead of 1.1em)?

The custom theme roller above specifies the font size as 13px (copied from the body, th, tr { font: normal 13px ... rule from trac.css).

Ah yes, the link from comment:8 then. In this case I'd suggest 10px for not getting a too big datepicker. Maybe that size could be set only for the datepicker and not for the other widgets.

[psuter <petsuter@…>]

Replying to cboos:

Ah yes, the link from comment:8 then. In this case I'd suggest 10px for not getting a too big datepicker.

Sorry, I'm still not really following you. :)

​The link from comment:8 contains a parameter &fsDefault=13px&. In the theme roller this sets the Size under Font settings to 13px. All the theme font sizes are derived from that. We could set it to 1em or 1.1em or 10px or whatever you prefer instead. (Personally, I'm not that fond of the tiny fonts used throughout Trac, but I guess to keep it consistent this makes sense.)

Maybe that size could be set only for the datepicker and not for the other widgets.

As far as I can tell the theme roller doesn't support that. Of course one could edit the .css directly, but I think there are advantages to avoid that. Both upgrading to a new jQuery UI version and tweaking the theme might be much easier that way.

[psuter <petsuter@…>]

I guess we could call jquery_ui_datepicker_addon.css something like jquery_ui_addons.css instead and that way:

• At least limit the additional files needed to one if there are other additions in the future.
• Have a way to add additional styling rules (like .ui-datepicker { font-size: 10px; }) without touching the generated file.

[Christian Boos]

Replying to psuter <petsuter@…>:

Replying to cboos:

Ah yes, the link from comment:8 then. In this case I'd suggest 10px for not getting a too big datepicker.

Sorry, I'm still not really following you. :) (…) In the theme roller this sets the Size under Font settings to 13px. All the theme font sizes are derived from that. We could set it to 1em or 1.1em or 10px or whatever you prefer instead.

Understood. My "problem" was that I initially followed the link from the description, and that one happens to have "1.1em" for the font size.

Let's look at the results:

• 13px:
• 10px:

(Personally, I'm not that fond of the tiny fonts used throughout Trac, but I guess to keep it consistent this makes sense.)

I think the justification for the tiny fonts is that they help you distinguish what is the text used for the "user interface" from the text corresponding to actual content or metadata. It's not a fixed rule and of course you'll find normal size text for user interface elements, and sometimes even a larger font (collapsible sections of the interface), but mainly the "tiny" fonts are for interface details you can ignore when focusing on reading the content.

In the present case, it's just that I find the datepicker size to be too large and with the 10px size, its dimension feels just right (to me).

OTOH, that font size when applied to the other widgets ("Accordion" or "Tabs" if we ever use them) looks indeed too small… that's why I hope we can find a way to make a specialization for the datepicker (sorry, I have yet to test your suggestions - or even the whole branch).

[Christian Boos]

custom theme with a font size of 13px

[Christian Boos]

custom theme with a font size of 10px

[Mikael Relbe]

Will it be possible to:

• Define first weekday of the week (Sunday or Monday)?
• View week numbers to the left of a week in the datepicker?
• Define when week 1 occurs?

These features would be very appreciated.

[Genie]

datepicker-i18n with babel date format

[Genie]

I released a plugin for Trac 0.11-0.13.

It is korean customized version of Decoratorplugin (from Shibuya.trac).

simple i18n implementation approach: req.locale (Trac ≥ 0.12), req.tc_time (Trac ≥ 0.13dev-r10571)

​http://trac.assembla.com/decorator-ko/changeset/23#file4

Repository: ​http://subversion.assembla.com/svn/decorator-ko/trunk

[psuter <petsuter@…>]

Replying to cboos:

Understood. My "problem" was that I initially followed the link from the description, and that one happens to have "1.1em" for the font size.

Oh, right.

mainly the "tiny" fonts are for interface details you can ignore when focusing on reading the content.

I see, that makes sense.

In the present case, it's just that I find the datepicker size to be too large and with the 10px size, its dimension feels just right (to me).

10px seems too small to me, but I guess I have a large monitor. :)

(sorry, I have yet to test your suggestions - or even the whole branch).

No worries. There's not that much more there that's not also available in the theme roller.

[psuter <petsuter@…>]

Replying to mrelbe:

Will it be possible to:

• Define first weekday of the week (Sunday or Monday)?
• View week numbers to the left of a week in the datepicker?
• Define when week 1 occurs?

All of these options are supported by the datepicker library itself. If and how we expose / use these options is up for discussion. I assume first weekday should be set as specified in the locale. Week numbers can be enabled using the ​showWeeks option:

The datepicker can show the week of the year. The default calculation follows the ISO 8601 definition.

(But you could provide alternative week number calculation code.)

[psuter <petsuter@…>]

Replying to Genie:

I released a plugin for Trac 0.11-0.13. It is korean customized version of Decoratorplugin (from Shibuya.trac).

Interesting, thanks for the links.

Some related excerpts:

            # with babel: i18n, without babel: korean only
            locale = getattr(req, 'locale', None) # req.locale : Trac >= 0.12
            add_script(req, 'decorator/js/jqueryui/i18n/ui.datepicker-%s.js' % str(locale or 'ko').replace('_', '-'));
...
            lc_time = getattr(req, 'lc_time', None) # req.lc_time : Trac >= 0.13dev-r10571
...
            format_hint = get_date_format_hint(lc_time)
            dateFormat = format_hint.lower().replace('yy', 'y', 2).replace('mmm', 'M', 1)

So this also attempts a limited pattern conversion.

[Remy Blank]

I have updated my branch with some work on the translations for the date/time picker. The reason I put all month names into the same string is that otherwise, the short and long names for the month of May get the same translation, which isn't what we want. I have tested the translation functionality by updating the French translation, and it's working fine.

The only thing that remains to be done is the date / time format string. Currently, it doesn't work at all on my machine. The datetime that is in the milestone due date isn't parsed correctly by the picker, so it always shows today's date at midnight. After closing the picker, however, the datetime is set in ISO-8601 format.

[psuter <petsuter@…>]

Replying to rblank:

The datetime that is in the milestone due date isn't parsed correctly by the picker, so it always shows today's date at midnight.

I think besides any dat / time format issue on our side we also hit ​jQuery-Timepicker-Addon issue 197.

[Jun Omae]

I have some works on my ​branch.

• Added the hint for date/time picker.
• Uses the month names and the day names in Babel. Babel has the names for i18n/l10n.
• Removed _(" "), the term is impossible to translate and so bad. Instead, added _("$month$year") to extract yearSuffix and showMonthAfterYear.

And, I found some problems.

• When date/time picker is active, cannot type directly to the text field.
• Babel.Locale.first_week_day is incorrect when the locale doesn't have the territory. In Japan, the first week day normally is Sunday, however req.locale.first_week_day returns 0 (Monday).

  jun66j5@gotanda:66$ python
  Python 2.6.5 (r265:79063, Feb 28 2011, 21:55:56)
  [GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from babel import Locale
  >>> Locale('en_US').first_week_day
  6
  >>> Locale('en').first_week_day
  0
  >>> Locale('ja_JP').first_week_day
  6
  >>> Locale('ja').first_week_day
  0
  

BTW, the font size of 11px looks nice for me ;-)

[psuter <petsuter@…>]

Replying to jomae:

I have some works on my ​branch.

​Fixed AM/PM symbol in hint of time format doesn't seem to work here (without Babel). (I get Format: a2a9a.a1a0a.a1a9a9a9a a2a3a:a5a9a:a5a8a as the hint now, instead of Format: DD.MM.YYYY hh:mm:ss.)

[Jun Omae]

Replying to psuter <petsuter@…>:

​Fixed AM/PM symbol in hint of time format doesn't seem to work here (without Babel). (I get Format: a2a9a.a1a0a.a1a9a9a9a a2a3a:a5a9a:a5a8a as the hint now, instead of Format: DD.MM.YYYY hh:mm:ss.)

Oh, that's so bad. I just fix it, ​https://bitbucket.org/jun66j5/trac/changeset/e733aa991901. Please refresh your cloned repository.

[psuter <petsuter@…>]

Replying to jomae:

Oh, that's so bad. I just fix it, ​https://bitbucket.org/jun66j5/trac/changeset/e733aa991901. Please refresh your cloned repository.

It works, thanks!

[psuter <petsuter@…>]

Replying to jomae:

And, I found some problems.

• When date/time picker is active, cannot type directly to the text field.

Replying to psuter <petsuter@…>:

Replying to rblank:

The datetime that is in the milestone due date isn't parsed correctly by the picker, so it always shows today's date at midnight.

I think besides any date / time format issue on our side we also hit ​jQuery-Timepicker-Addon issue 197.

Both are fixed for me when using the ​development version of the timepicker.

[Remy Blank]

Replying to psuter <petsuter@…>:

Both are fixed for me when using the ​development version of the timepicker.

I see you guys are getting along a treat :) We can use the development version if it works better, no problem. I haven't done it up to now, but you could also minify the timepicker file. Just make sure you keep the leading comment with the copyright and license.

Just let me know when you're done, and I'll commit the whole stuff.

[psuter <petsuter@…>]

Replying to rblank:

We can use the development version if it works better, no problem.

I just noticed 0.9.6, released three days ago, seems to work as well. I updated to that (minified) ​here.

[psuter <petsuter@…>]

And (by popular request :)) override the picker's font-size to 11px ​here. (Though I'm not sure if there's a cleaner way, nor if this works out in all languages.)

[Jun Omae]

I have updated ​jquery-ui-datetimepicker branch at my repository.

• Babel.Locale.first_week_day is incorrect when the locale doesn't have the territory. In Japan, the first week day normally is Sunday, however req.locale.first_week_day returns 0 (Monday).

Fixed it. If the locale has the territory, first_week_day is used. Otherwise Sunday is used.

I tried in all langauges, and some problems still exist;

1. When a locale is "vi" [Vietnamese], the datetime format is HH:mm:ss dd-MM-yyyy. Datetime picker cannot parse it (e.g. 19:22:00 15-06-2011).
2. Datetime picker cannot parse localized AM/PM marker in "el" [Greek], "ko" [Korean], "zh_CN" [Chinese (China)] and "zh_TW" [Chinese (Taiwan)].
   • el: 24 Ιουλ 2011 11:58:59 μ.μ.
   • ko: 2011. 7. 24. 오후 11:58:59
   • zh_CN: 2011-7-24 下午11:58:59
   • zh_TW: 2011-7-24 下午11:58:59
3. It cannot parse iso8601 datetime string (e.g. 2011-07-24T23:58:59+09:00). Time picker addon expects +0900 in the timezone field.

[psuter <petsuter@…>]

Replying to jomae:

Fixed it. If the locale has the territory, first_week_day is used. Otherwise Sunday is used.

If I remember correctly the fallback was Monday for iso8601, which can be used without Babel.

I tried in all langauges, and some problems still exist;

1. When a locale is "vi" [Vietnamese], the datetime format is HH:mm:ss dd-MM-yyyy. Datetime picker cannot parse it (e.g. 19:22:00 15-06-2011).

There's an ​open issue filed with TimePicker about this, but it doesn't look like it's getting fixed soon.

2. Datetime picker cannot parse localized AM/PM marker

Hm, looks like it doesn't support localized AM/PM markers at all?

3. It cannot parse iso8601 datetime string (e.g. 2011-07-24T23:58:59+09:00). Time picker addon expects +0900 in the timezone field.

There are a few ​additional timezone settings (that don't seem to be documented elsewhere) that could partially help here:

    timeFormat: "hh:mm:ss z",
    separator: "T",
    timezone: "+09:00",

Unfortunately, it seems to insist on a space before the timezone field.

[Jun Omae]

Replying to psuter <petsuter@…>:

3. It cannot parse iso8601 datetime string (e.g. 2011-07-24T23:58:59+09:00). Time picker addon expects +0900 in the timezone field.

There are a few ​additional timezone settings (that don't seem to be documented elsewhere) that could partially help here:

    timeFormat: "hh:mm:ss z",
    separator: "T",
    timezone: "+09:00",

Unfortunately, it seems to insist on a space before the timezone field.

That's so helpful. I worked on ​jquery-ui-datetimepicker-tz branch.

It works fine, however timepicker cannot parse +09:00 and Z and needs a work around.

trac/htdocs/js/jquery-ui-addons.js

@@ -198 +198 @@
                                 .replace(/m{1,2}/ig, '(\\d?\\d)')
                                 .replace(/s{1,2}/ig, '(\\d?\\d)')
                                 .replace(/t{1,2}/ig, '(am|pm|a|p)?')
-                                .replace(/z{1}/ig, '((\\+|-)\\d\\d\\d\\d)?')
+                                .replace(/z{1}/ig, '(z|(\\+|-)\\d\\d:?\\d\\d)?')
                                 .replace(/\s/g, '\\s?') + this._defaults.timeSuffix + '$',
                         order = this._getFormatPositions(),
                         treg;

[Peter Suter]

Replying to jomae:

It works fine, however timepicker cannot parse +09:00 and Z and needs a work around.

Should I minify the patched jquery-ui-addons.js? Or do you plan to get this fixed upstream first?

And what about the other issues you found? Can we ignore / work around the Vietnamese time-before-date problem and the unlocalized AM/PM markers? Or should we try to get these fixed upstream as well?

[Jun Omae]

Replying to psuter:

Replying to jomae:

It works fine, however timepicker cannot parse +09:00 and Z and needs a work around.

Should I minify the patched jquery-ui-addons.js? Or do you plan to get this fixed upstream first?

And what about the other issues you found? Can we ignore / work around the Vietnamese time-before-date problem and the unlocalized AM/PM markers? Or should we try to get these fixed upstream as well?

Sorry for my late response. I think we should try to get fixed upstream first.

I worked iso8601 timezone issue, ​https://github.com/jun66j5/jQuery-Timepicker-Addon/tree/iso8601-tz. I will send "pull request" to ​trentrichardson later.

And I'm now working localized AM/PM markers issue.

[Genie]

Replying to jomae:

Sorry for my late response. I think we should try to get fixed upstream first.

I worked iso8601 timezone issue, ​https://github.com/jun66j5/jQuery-Timepicker-Addon/tree/iso8601-tz. I will send "pull request" to ​trentrichardson later.

And I'm now working localized AM/PM markers issue.

'localized AM/PM markers' is not works on the babel date format of Korean and Chinese locale.

​https://github.com/trentrichardson/jQuery-Timepicker-Addon/issues/303

[Genie]

datetimepicker with ISO 8601 format

[anonymous]

Replying to jomae:

Replying to psuter:

Replying to jomae:

It works fine, however timepicker cannot parse +09:00 and Z and needs a work around.

Should I minify the patched jquery-ui-addons.js? Or do you plan to get this fixed upstream first?

And what about the other issues you found? Can we ignore / work around the Vietnamese time-before-date problem and the unlocalized AM/PM markers? Or should we try to get these fixed upstream as well?

Sorry for my late response. I think we should try to get fixed upstream first.

I worked iso8601 timezone issue, ​https://github.com/jun66j5/jQuery-Timepicker-Addon/tree/iso8601-tz. I will send "pull request" to ​trentrichardson later.

And I'm now working localized AM/PM markers issue.

Thank you for your help. The 'Localized AM/PM markers' is works fine.

The 'ISO 8601 Timezone' is seems to works fine …

    dateFormat      : $.datepicker.ISO_8601,
    separator       : 'T',
    timeFormat      : 'hh:mm:ssz',
    showTimezone    : true,
    timezoneIso8609 : true

[Peter Suter]

Replying to jomae:

I think we should try to get fixed upstream first.

I worked iso8601 timezone issue, ​https://github.com/jun66j5/jQuery-Timepicker-Addon/tree/iso8601-tz. I will send "pull request" to ​trentrichardson later.

And I'm now working localized AM/PM markers issue.

I noticed your pull requests landed in version 0.9.9 recently. Does this mean this ticket can move forward again?

I tried to ​update to that and it all seemed to work fine in my (unlocalized) environment. But you probably now better what still needs to be done than me.

(Btw. Is ISO8609 just a typo for ISO8601?)

[Jun Omae]

Replying to psuter:

I noticed your pull requests landed in version 0.9.9 recently. Does this mean this ticket can move forward again?

Yes, it can move forward.

I tried to ​update to that and it all seemed to work fine in my (unlocalized) environment. But you probably now better what still needs to be done than me.

I've done all.

(Btw. Is ISO8609 just a typo for ISO8601?)

Ouch…, I sent a ​pull request and it has been applied. Thanks.

[Peter Suter]

Great, as everything seems ready I'm preparing ​the final diff to be committed to trunk with minified and upgraded jQuery UI and Timepicker Addon.

[Peter Suter]

Commited in [10992].

Thanks everyone!

Edit: Sorry, I messed that up somehow. Fixed in [10993].

[Genie]

Replying to psuter:

Great, as everything seems ready I'm preparing ​the final diff to be committed to trunk with minified and upgraded jQuery UI and Timepicker Addon.

Greate !!! but, css and image files is missing in setup scripts.

trac0.13dev-r10996/setup.py

@@ -84 +84 @@
         '': ['templates/*'],
         'trac': ['htdocs/*.*', 'htdocs/README', 'htdocs/js/*.*',
                  'htdocs/js/messages/*.*', 'htdocs/css/*.*',
+                 'htdocs/css/jquery-ui/*.*', 'htdocs/css/jquery-ui/images/*.*',
                  'htdocs/guide/*', 'locale/*/LC_MESSAGES/messages.mo',
                  'locale/*/LC_MESSAGES/tracini.mo'],
         'trac.wiki': ['default-pages/*'],

[Peter Suter]

Fixed in [10997], thanks.

[Ryan J Ollos <ryano@…>]

I was wondering if it would be appropriate to add the version of the jQuery UI to wiki:TracDev/ApiChanges/1.0#ModifiedDependencies as a new bundled dependency.

[Christian Boos]

Replying to Ryan J Ollos <ryano@…>:

I was wondering if it would be appropriate to add the version of the jQuery UI to wiki:TracDev/ApiChanges/1.0#ModifiedDependencies as a new bundled dependency.

Sure! Please do so.

[Ryan J Ollos <ryano@…>]

Edited to version 16. I didn't specifically mention the timepicker add-on, but if anyone thinks that should be added as well, the bundled version is 1.0.0.

[Ryan J Ollos <ryano@…>]

Should the Today and Done buttons be shown on the DatePicker, since they are shown on the DateTimePicker?

I think all that is required is a tweak to jquery-ui-addon.js. The terms for translation are already present in jquery-ui-i18n.js.

[Ryan J Ollos <ryano@…>]

Replying to Ryan J Ollos <ryano@…>:

I think all that is required is a tweak to jquery-ui-addon.js.

I should have said jquery-ui.js.

[Ryan J Ollos <ryano@…>]

Patch against r11109 of the trunk.

[Ryan J Ollos <ryano@…>]

Replying to Ryan J Ollos <ryano@…>:

I should have said jquery-ui.js.

I read-up on this, and the proper way to change defaults is to use the ​setDefaults utility, which I see is what you are already doing in jquery-ui-i18n.js. The patch t10245-r11109-1.patch​ causes the button panel to show.

The behaviors of Today in datepicker and Now in datetimepicker are slightly different though (at least in Firefox 13 on Debian 6). Clicking Today causes the datepicker to disappear and it won't appear again unless another element is given focus first. Clicking Now on the datetimepicker, and the dialog stays visible - the datetimepicker doesn't go away until another element is given focus or Done is pressed.

[Genie]

​#5477 Does anyone help to update Korean translation for jquery-ui ?

[Ryan J Ollos]

I'm going to go ahead and commit the change described in comment:61 if no one objects.

[Ryan J Ollos]

Replying to rjollos:

I'm going to go ahead and commit the change described in comment:61 if no one objects.

⇒ #11435.