Datepicker using Globalize 1.x #1341

rxaviers · 2014-09-04T20:02:23Z

💥 WIP...

The goal is to have Datepicker working with Globalize 1.x.

Depends on

Calendar rebase (4) #1371 fnagel:calendar-value-pr3;

Todo

Rebase on datepicker branch
Destroy translation data (weekHeader, prevText, nextText , datePickerRole, currentText). Create user options instead;
Move external/date.js into ui/ (see Datepicker and Calendar: WIP #1260 (comment));
Fix RTL LTR direction (available at cldr.main("layout/orientation/characterOrder"), values are left-to-right or right-to-left);
Get currentText: "Today" from locale.
Fix Use narrow day names (e.g., "ﺥ" EEEEE) if short (e.g., "ﺎﻠﺨﻤﻴﺳ" EEE) is too lengthy;
Update all demos accordingly. (currently, demos/datepicker/localization.html has been updated)

rxaviers · 2014-09-04T20:05:29Z

demos/datepicker/localization.html

 		<option value="en">English</option>
+		<option value="es">Spanish (Espa&ntilde;ol)</option>
+		<option value="zh">Chinese Simplified (简体中国)</option>


I've reverted back some locales. It's important to have Chinese, Spanish and Arabic. Because, they are the three most spoken languages in the world after English.

Two questions:

How to write Chinese Simplified in Chinese? I have translated that in Google Translate and got the above.

Does anyone know how to convert UTF-8 into that numeric entities? Anyway, why using entities and not utf-8 as is?

I never liked that we attempted to translate the language names. Anyone browsing our site has to have some level of English comprehension and I'm sure they can recognize their language written in English if they can read our docs and demo descriptions.

rxaviers · 2014-09-04T20:54:45Z

Need to fix:

LTR vs. RTL. (available at cldr.main("layout/orientation/characterOrder"), values are left-to-right or right-to-left)
Use narrow day names (e.g., "ﺥ" EEEEE) instead of short (e.g., "ﺎﻠﺨﻤﻴﺳ" EEE).

master
this branch

OBS: the month name above is different, but the new one seems more popular. So, it seems fine to me. See https://translate.google.com/#en/ar/September

rxaviers · 2014-09-05T10:41:34Z

Fixed "Use narrow day names (e.g., "ﺥ" EEEEE) if short (e.g., "ﺎﻠﺨﻤﻴﺳ" EEE) if too lengthy".

master
this branch

rxaviers · 2014-09-05T10:46:42Z

external/date.js

+					cldr.main([ "dates/calendars/gregorian/days/format/short", weekdays[ day ] ]).length > 3 ?
+					cldr.main([ "dates/calendars/gregorian/days/format/narrow", weekdays[ day ] ]) :
+					cldr.main([ "dates/calendars/gregorian/days/format/short", weekdays[ day ] ]),
+				fullname: cldr.main([ "dates/calendars/gregorian/days/format/wide", weekdays[ day ] ])


We may favor using Globalize functions instead of accessing the data directly.

Depends on if we plan to make Globalize optional for Calendar.

It seems harder for Datepicker, because we use cldrjs anyway. But, yeap. It would be nice if we were able to make something here similar to Spinner.

rxaviers · 2014-09-05T11:16:08Z

About LTR vs. RTL, I'm looking at the master's implementation. It either inserts elements before or after depending on this value.

It would be a much more elegant solution if we could use CSS instead to control this flow, adding a proper .rtl modifier class.

rxaviers · 2014-09-05T11:27:41Z

How is RTL handled in other widgets?

tjvantoll · 2014-09-05T12:56:48Z

@rxaviers Datepicker is the only widget with an RTL implementation, and you'll want to talk to @scottgonzalez about the how this should work. I don't remember the specifics, but I remember a conversation with him about problems with RTL in master.

fnagel · 2014-09-05T13:00:10Z

@tjvantoll @rxaviers There are some notes within the Datepicker wiki page (search for isRTL).

scottgonzalez · 2014-09-05T13:14:57Z

RTL in master is just flat out wrong with changing DOM positions. Just let the browser do the right thing.

tjvantoll · 2014-09-05T13:44:01Z

This diff is going to be really hard to see until we merge @fnagel's branch in. I think we need the calendar-value-pr branch moved from @fnagel's fork to the canonical jquery/jquery-ui repo. That way you could base this PR off that branch.

rxaviers · 2014-09-05T13:46:14Z

This diff is going to be really hard to see until we merge @fnagel's branch in

Absolutely. That's the idea. For now, I'm only raising issues and fixing other things.

- Fix "I never liked that we attempted to translate the language #1341 (comment)

rxaviers · 2014-09-17T15:12:11Z

ui/calendar/date.js

-};
+});
+
+return $.ui.calendarDate = _Date;


What name we should use to export _Date? Should we place this object inside ui/calendar.js, so we don't have to expose this class publicly? Note it's not used anywhere else besides calendar.

I like the idea of using this without including calendar, so I would prefer to have this as a standalone object.

Add calendar widget by copying and renaming datepicker widget files. Remove datepicker functionality, options and methods from Calendar. Remove calendar functionality, options and methods from Datepicker. Adjust tests due to split and changed specification. Remove duplicated demo files and fix some demos. Simplify calendar generation, use CSS instead of inline styles. Fix destroy method. Make use of uniqueId method. Fix focus highlighting when month is changed. Add version property. Add common unit tests. Fix input keyboard handling.

fnagel · 2014-09-29T20:42:16Z

@rxaviers Please note there is a new PR for Calendar: #1352

- Fix "I never liked that we attempted to translate the language #1341 (comment)

rxaviers · 2014-10-01T11:28:08Z

Rebased on fnagel:calendar-value-pr2

fnagel · 2015-01-19T17:22:10Z

@rxaviers #1371 has been merged!

rxaviers · 2015-01-19T17:24:05Z

🎉 🎉

jzaefferer · 2015-01-20T10:52:56Z

This still has many commits from the other PR, does this need a rebase to get rid of them?

jzaefferer · 2015-01-20T10:54:25Z

As for RTL: Scott is putting together a meeting to discuss a UI-wide solution. @rxaviers should be there as well and provide some input from the CLDR perspective (what RTL data is provided by CLDR?). Since that might still take a while, I suggest ignoring RTL here and addressing that later.

fnagel · 2015-01-20T14:21:56Z

@jzaefferer Yes, this will need another rebase as we chaged a bunch of older commits in the merged branch.

- Make unit tests work

fnagel · 2015-04-30T10:37:19Z

@rxaviers Some questions regarding this branch / the implementation of Globalize:

I noticed that the first two days are the same (Sunday or Monday depending on locale). Can you give me a hint where to search for the issue?
What needs to be done to update to Globalize 1.0.0 (its alpha 7 now)? I've tried (using bower, adding globalize number) but run into a cldr data error.

- Fix merge conflict in value method - Fix common unit tests - Fix calendar localization tests - Fix rebase regression: labels update on refresh - Add new pass through options - lint fixes

- Make all demos work - Fix calendar localization demo - Fix merge errors

fnagel · 2015-04-30T11:30:28Z

My current working branch: https://github.com/fnagel/jquery-ui/tree/datepicker-globalize

Not sure if I should force push this PR or open a new one with reference and copied description. Opinions? @rxaviers @scottgonzalez @jzaefferer

scottgonzalez · 2015-04-30T11:49:01Z

A force push seems fine for this one.

rxaviers · 2015-04-30T12:04:39Z

I noticed that the first two days are the same (Sunday or Monday depending on locale). Can you give me a hint where to search for the issue?

What do you mean?

rxaviers · 2015-04-30T12:05:04Z

What needs to be done to update to Globalize 1.0.0 (its alpha 7 now)? I've tried (using bower, adding globalize number) but run into a cldr data error.

I need a little more details. Anyway a good getting started is Globalize examples. https://github.com/jquery/globalize/tree/master/examples

rxaviers · 2015-04-30T12:38:17Z

About passing i18n options to datepicker (e.g., locale, pattern, etc), I suggest the below (we had a discussion about it in the past, but I don't find a summary about it; anyway...)

Datepicker shouldn't be tight coupled with Globalize. Instead, it should expect formatters and parsers (functions needed for formatting and parsering the calendar and input values) to be passed from user land. Datepicker could use Globalize to fill in the default ones (i.e., for en). Datepicker could even have a helper that uses Globalize to automatically fill them in for other locales as well. An initial work has been started at a8d5e80 (note _calendarDateOptions). But, I would consider removing _setLocale and any var globalize = new Globalize( locale ) reference from within datepicker and expect all formatters and parsers to come from options.

Having Datepicker loosely coupled with Globalize the way I described may sound more work now. But, it will dramatically improve its maintenance over time + it will help developers to integrate datepicker into their own i18n workflow easily.

rxaviers · 2015-04-30T12:41:20Z

Not sure if I should force push this PR

Feel free to force push to it assuming no work here is lost. :)

scottgonzalez · 2015-04-30T13:20:16Z

I don't recall coming to that conclusion. That's the approach we agreed on for spinner, but I have always expected datepicker to have a hard dependency on Globalize.

fnagel · 2015-04-30T13:51:14Z

I noticed that the first two days are the same (Sunday or Monday depending on locale). Can you give me a hint where to search for the issue?

What do you mean?

rxaviers · 2015-04-30T13:57:53Z

Well remembered @scottgonzalez. Obviously, having datepicker to have a hard dependency on Globalize is up to you. I also remember that you wanted datepicker to be distributed working for en as a default, which needs to be taken into account in this implementation.

rxaviers · 2015-04-30T14:10:59Z

@fnagel related code:

Did I answer your question? Please, just let me know on any problem. Also, follow a code that may help you to play with Globalize: https://gist.github.com/rxaviers/1da4a40b13d2a6b03316

- Fix wrong calculation of weekdays

dwachss · 2015-04-30T15:47:29Z

Thank you for rewriting Datepicker with the widget factory and based on CLDR.
Two questions about where this is going:

Will there be support for calendar systems other than gregorian? CLDR includes the data for localization but not the algorithms. Will Datepicker be extensible that way?
The initial comment 'Get currentText: "Today" from locale'. That's not in CLDR as far as I can tell (can you get that from Relative Date Names?). What about the "Done" button--or will you leave that out?

fnagel · 2015-04-30T15:51:15Z

Will there be support for calendar systems other than gregorian? CLDR includes the data for localization but not the algorithms. Will Datepicker be extensible that way?

Afaik yes.

What about the "Done" button--or will you leave that out?

There is a new option buttons like in dialog -- you will need to set the text strings yourself. See https://github.com/jquery/jquery-ui/blob/datepicker/demos/calendar/buttonbar.html

Make sure to take a look at the wiki page: http://wiki.jqueryui.com/w/page/12137778/Datepicker

rxaviers · 2015-04-30T15:53:38Z

Will there be support for calendar systems other than gregorian? CLDR includes the data for localization but not the algorithms. Will Datepicker be extensible that way?

I can't answer for the widget. But, it will depend on Globalize, whose support for other calendars need globalizejs/globalize#320 to be implemented. Help appreciated.

The initial comment 'Get currentText: "Today" from locale'. That's not in CLDR as far as I can tell (can you get that from Relative Date Names?)

It's is in CLDR (in dateFields.json).

dwachss · 2015-04-30T16:21:56Z

Thanks. I've been working on an alternative-calendar-system datepicker widget for the past few years ( https://github.com/dwachss/flexcal ) and I have a good handle on manipulating them. I'll see if I have time to work on Globalize.
Thanks also for the link to the CLDR data (it's very hard to find from the Unicode site).
Danny

rxaviers · 2015-04-30T18:29:39Z

Thanks @dwachss. Looking forward to it.

- Fix "I never liked that we attempted to translate the language #1341 (comment)

rxaviers · 2015-07-29T11:00:50Z

Can this branch datepicker-globalize-1.x be deleted?

In the description, there are two remaining items. Are they been tracked somewhere else?

fnagel · 2015-07-29T11:06:00Z

I closed this by accident. It's not merged to datepicker branch yet.

datepicker-globalize-1.x is still up to date with my latest changes!

rxaviers · 2015-07-29T11:07:26Z

Gotcha. Thanks

fnagel · 2015-07-29T11:09:25Z

More info in the UI dev meeting later today.

fnagel · 2015-08-02T12:04:56Z

This PR has been merged to datepicker branch. Remaining issue is RTL LTR support.

@scottgonzalez Datepicker branch is now up to date and waiting for your merging magic :-D

scottgonzalez · 2015-08-20T16:05:24Z

I finished merging master into datepicker this morning.

fnagel · 2015-08-25T20:58:50Z

Looks good! Added a new PR based on this: #1590

rxaviers reviewed Sep 4, 2014
View reviewed changes

rxaviers reviewed Sep 5, 2014
View reviewed changes

rxaviers added a commit that referenced this pull request Sep 13, 2014

Datepicker: Use Globalize 1.0.0

72fb65a

- Fix "I never liked that we attempted to translate the language #1341 (comment)

rxaviers mentioned this pull request Sep 16, 2014

Calendar rebase #1316

Closed

rxaviers reviewed Sep 17, 2014
View reviewed changes

rxaviers force-pushed the datepicker-globalize-1.x branch from fa52580 to 4e65e51 Compare October 1, 2014 11:26

rxaviers added a commit that referenced this pull request Oct 1, 2014

Datepicker: Use Globalize 1.0.0

8a17a39

- Fix "I never liked that we attempted to translate the language #1341 (comment)

scottgonzalez force-pushed the datepicker branch from e21a56d to 2ea46ae Compare January 29, 2015 23:05

jquerybot added the CLA: Valid label Feb 26, 2015

fnagel mentioned this pull request Apr 10, 2015

Calendar: fix month jumping WIP #1519

Merged

Datepicker: Use Globalize 1.0.0

981b136

- Make unit tests work

fnagel added 2 commits April 30, 2015 13:06

Datepicker: Use Globalize 1.0.0

6fe64f5

- Fix merge conflict in value method - Fix common unit tests - Fix calendar localization tests - Fix rebase regression: labels update on refresh - Add new pass through options - lint fixes

Datepicker: Use Globalize 1.0.0

02843a7

- Make all demos work - Fix calendar localization demo - Fix merge errors

Datepicker: Use Globalize 1.0.0

28bc45c

- Fix wrong calculation of weekdays

fnagel force-pushed the datepicker-globalize-1.x branch from a8d5e80 to 28bc45c Compare May 13, 2015 21:36

fnagel merged commit 28bc45c into datepicker Jul 28, 2015

rxaviers added a commit that referenced this pull request Jul 28, 2015

Datepicker: Use Globalize 1.0.0

9d552b7

- Fix "I never liked that we attempted to translate the language #1341 (comment)

Datepicker using Globalize 1.x #1341

Datepicker using Globalize 1.x #1341

Uh oh!

Conversation

rxaviers commented Sep 4, 2014

Uh oh!

rxaviers Sep 4, 2014

Choose a reason for hiding this comment

Uh oh!

scottgonzalez Sep 5, 2014

Choose a reason for hiding this comment

Uh oh!

rxaviers commented Sep 4, 2014

Uh oh!

rxaviers commented Sep 5, 2014

Uh oh!

rxaviers Sep 5, 2014

Choose a reason for hiding this comment

Uh oh!

fnagel Sep 5, 2014

Choose a reason for hiding this comment

Uh oh!

rxaviers Sep 5, 2014

Choose a reason for hiding this comment

Uh oh!

rxaviers commented Sep 5, 2014

Uh oh!

rxaviers commented Sep 5, 2014

Uh oh!

tjvantoll commented Sep 5, 2014

Uh oh!

fnagel commented Sep 5, 2014

Uh oh!

scottgonzalez commented Sep 5, 2014

Uh oh!

tjvantoll commented Sep 5, 2014

Uh oh!

rxaviers commented Sep 5, 2014

Uh oh!

rxaviers Sep 17, 2014

Choose a reason for hiding this comment

Uh oh!

fnagel Sep 19, 2014

Choose a reason for hiding this comment

Uh oh!

fnagel commented Sep 29, 2014

Uh oh!

rxaviers commented Oct 1, 2014

Uh oh!

fnagel commented Jan 19, 2015

Uh oh!

rxaviers commented Jan 19, 2015

Uh oh!

jzaefferer commented Jan 20, 2015

Uh oh!

jzaefferer commented Jan 20, 2015

Uh oh!

fnagel commented Jan 20, 2015

Uh oh!

fnagel commented Apr 30, 2015

Uh oh!

fnagel commented Apr 30, 2015

Uh oh!

scottgonzalez commented Apr 30, 2015

Uh oh!

rxaviers commented Apr 30, 2015

Uh oh!

rxaviers commented Apr 30, 2015

Uh oh!

rxaviers commented Apr 30, 2015

Uh oh!

rxaviers commented Apr 30, 2015

Uh oh!

scottgonzalez commented Apr 30, 2015

Uh oh!

fnagel commented Apr 30, 2015

Uh oh!

rxaviers commented Apr 30, 2015

Uh oh!

rxaviers commented Apr 30, 2015