Resolve #461: Add calendar picker for date attribute fields

[seav]

Proposed changes in this pull request

• Resolve Add Calendar Widget for Date Fields #461:
  • Import JQuery UI Datepicker widget. This includes 3 minified CSS files, 1 minified JS file, and 6 CSS image files.
  • Update 3 template files to add the datepicker HTML class if the Django field to be rendered is DateField.
  • Update 3 template files to include the JQuery UI files and to initialize the Datepicker widgets with some sensible options.

When should this PR be merged

The following issue should be resolved first.

I need some suggestions on how best to incorporate l10n. JQuery UI has a comprehensive set of l10n files, but this would be a bit tricky to work with our language picker at the footer. It may end up that the user changed the UI language but the date picker retains the previous language though this scenario may be rare because the user would have changed the language way before going to a page with the datepicker.

An alternative option is to use the Datepicker's monthNamesShort and dayNamesMin options to override any selected locale. This can then use Django's normal template l10n features.

Risks

None foreseen.

Follow up actions

None.

[ian-ross]

Can you see if there's a way to fit into the way Django's Javascript localisation works? (https://docs.djangoproject.com/en/1.9/topics/i18n/translation/#internationalization-in-javascript-code). We now have this set up, with a seperate javascript Transifex resource for Javascript translations (used here, for instance: https://github.com/Cadasta/cadasta-platform/blob/master/cadasta/core/static/js/map_utils.js#L10-L11).

[seav]

@ian-ross, I've looked into the Javascript localization but I don't think it's needed because the JavaScript strings that need to be translated are not in static JS files but in templates, so regular Django template translation strings could suffice.

However, I decided to resolve this by loading the proper JQuery UI i18n JS file from the RawGit CDN (which we already use for the markerCluster Leaflet plugin), and using the LANGUAGE_CODE variable via {% get_current_language as LANGUAGE_CODE %}. Two advantages of this approach is that we instantly have Portuguese translations (see screenshot below), and that we can further customize the widget without needing to potentially translate additional strings ourselves, such as "Today" if ever we decide to enable the widget's button toolbar.

Two disadvantages of this approach is that one, we now have an external i18n dependency, and two, dialects like Brazilian Portuguese cannot be supported in a straightforward manner because Django uses language codes like "pt-br" while JQuery UI uses "pt-BR".

[ian-ross]

Sounds good! (We can always write a custom template tag to convert the regional language codes to the format that jQuery uses if we need that level of detail.)

[seav]

Question: Is jQuery UI's widget good enough? Or would the Bootstrap 3 Datepicker be better so that the widget can match our Bootstrap theme?

[wonderchook]

@seav I think it is good enough for now if you are done with this.

[seav]

@wonderchook, yes, this is done.

[ian-ross]

@seav I think there's something missing here. The datepicker pops up when you edit entities, but not when you're creating entities. I think you just forgot to add the datepicker activation JS code to the relevant templates.

[seav]

D'oh! I'll fix this now.

[oliverroick]

I think, this is good to go. Any objections, @ian-ross?

[ian-ross]

No objections from me: merging now...