Opened 10 years ago

Closed 6 years ago

#1061 closed defect (fixed)

Start week day on calendar

Reported by: antoni.aloy@… Owned by: jezdez
Component: Internationalization Version: master
Severity: minor Keywords: i18n-fixed
Cc: Triage Stage: Fixed on a branch
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by gwilson)

I thinks this is an issue of internationalization.
The calendar widget starts the week on Sunday but in some countries (Spain for example) the week starts on Monday. On the other hand I haven't seen any way to change the date display format on the admin application, it displays 2005-12-14 instead of 14-12-2005 or 14/12/2005 which would be the default locale for Spain.

Attachments (3)

calendar.diff (4.2 KB) - added by jezdez 8 years ago.
Implemented WEEK_START_DAY and a little change to the calendar javascript code
calendar2.diff (5.0 KB) - added by jezdez 8 years ago.
Refactored patch for use with DateField, DateTimeField and TimeField, please patch a fresh checkout
1061.diff (1.6 KB) - added by garcia_marc 7 years ago.
Fix and example of how djangojs.po files should be updated to work on every language

Download all attachments as: .zip

Change History (34)

comment:1 Changed 9 years ago by anonymous

  • milestone set to Version 0.92
  • Severity changed from normal to major
  • Type changed from enhancement to defect

comment:2 Changed 9 years ago by hugo

  • milestone Version 0.92 deleted
  • Severity changed from major to normal

This is more a problem of localization than internationalization, but could be fixed easily by adding a WEEK_STARTS_MONDAY switch to the config and to use that in the calendar code (by passing it from the view function to the javascript that draws the calendar).

comment:3 Changed 9 years ago by adrian

  • priority changed from normal to lowest
  • Severity changed from normal to minor

comment:4 Changed 9 years ago by asmodai@…

I can name already three countries where the first day of the week is: Saturday, Sunday, and Monday. So that WEEK_STARTS_MONDAY switch needs to be a bit more configurable than that.

comment:5 Changed 8 years ago by Simon G. <dev@…>

  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 8 years ago by f

  • Component changed from Admin interface to HTTP handling
  • Keywords SUNDAY added
  • Needs documentation set
  • Patch needs improvement set
  • Resolution set to fixed
  • Status changed from new to closed
  • Triage Stage changed from Design decision needed to Accepted

comment:7 Changed 8 years ago by gwilson

  • Component changed from HTTP handling to Admin interface
  • Description modified (diff)
  • Keywords SUNDAY removed
  • Needs documentation unset
  • Patch needs improvement unset
  • Resolution fixed deleted
  • Status changed from closed to reopened

reverting spam.

comment:8 Changed 8 years ago by toke

What about: WEEK_START_DAY = 0-6 ? Monday == 0 ... Sunday == 6 as in datetime?

comment:9 Changed 8 years ago by antoni.aloy@…

It's a matter of convention, so getting the datetime one is as good as any other one.

comment:10 Changed 8 years ago by anonymous

It's more complicated than that, there are regional settings usually that let users select from a week numbering scheme (first full week after start of month = first week, first week that crosses nye = first week, week starts on monday, week starts on sunday)
http://en.wikipedia.org/wiki/Week#Week_number
http://en.wikipedia.org/wiki/ISO_week_date

I used to have a better link but can't seem to find it atm

comment:11 Changed 8 years ago by jezdez

  • Owner changed from nobody to jezdez
  • Status changed from reopened to new

Changed 8 years ago by jezdez

Implemented WEEK_START_DAY and a little change to the calendar javascript code

comment:12 Changed 8 years ago by jezdez

  • Has patch set

comment:13 Changed 8 years ago by aaloy

I have applied the patch but it does not work for me, it simply makes calendar not appear anymore :(

comment:14 Changed 8 years ago by jezdez

Hm, sorry to hear that, did you restart your django process?

comment:15 Changed 8 years ago by aaloy

The patch works for DateTimeFields but no for DateFields.

Changed 8 years ago by jezdez

Refactored patch for use with DateField, DateTimeField and TimeField, please patch a fresh checkout

comment:16 Changed 8 years ago by aaloy

Tested! It works on both DateField and DateTimeField

comment:17 Changed 8 years ago by jezdez

  • Keywords sprintdec01 added

comment:18 Changed 7 years ago by garcia_marc

  • Component changed from Admin interface to Internationalization
  • Keywords i18n admin added; sprintdec01 removed
  • milestone set to 1.0 beta
  • Owner changed from jezdez to garcia_marc
  • Patch needs improvement set

I think that the patch is too much complicated to achieve it (and probably commiters agree, so it hasn't been commited for several months).

I'll develop a better patch, and try to have this feature on 1.0.

I know that this is not explicitly in Jacob's maybe list, but I thing that if a good patch exists when 1.0 beta, it should be included, so tagging it as 1.0 beta.

comment:19 follow-up: Changed 7 years ago by jezdez

Ehm, why do you think my patch is complicated?

comment:20 in reply to: ↑ 19 Changed 7 years ago by garcia_marc

Replying to jezdez:

Ehm, why do you think my patch is complicated?

I think that your patch can be improved easily, and following more "django standards". It's a good job, because you pointed out where the problem is, and how to fix this situation, but I think that a better patch is necessary.

I explained more clearly how my patch will be in the next thread:
http://groups.google.com/group/django-developers/browse_thread/thread/db149543262b5b21/c51f020880badf41#c51f020880badf41

Don't take it personally, for sure you'll be able to improve my patch as well... :)

comment:21 Changed 7 years ago by garcia_marc

  • Keywords i18n-rf added

Changed 7 years ago by garcia_marc

Fix and example of how djangojs.po files should be updated to work on every language

comment:22 Changed 7 years ago by garcia_marc

  • Patch needs improvement unset
  • Triage Stage changed from Accepted to Ready for checkin

New patch fixes this issue using standard django's way to specify date formats... that is creating settings as strings on code, and marking them for gettext translation.

If the patch is commited, the djangojs.po file should be excluded. I've attached it just for showing how the patch will work.

The behaviour of admin calendar based on this patch, will be to set first day of week based on current language. If no setting is found, then it will be used default application language setting, then english setting, and finally Sunday.

comment:23 Changed 7 years ago by jezdez

Great! That patch is much more elegant!

comment:24 Changed 7 years ago by gwilson

  • milestone 1.0 beta deleted

An enhancement, not 1.0.

comment:25 Changed 7 years ago by garcia_marc

  • milestone set to post-1.0

comment:26 Changed 7 years ago by bcurtu

I think there is a mistake in your patch yet.

There is an additional change you must do, because the patch fixes the calendar header, but not the number positions. So you must include an additional change, on line 64:

var startingPos = new Date(year, month-1, 1).getDay()-CalendarNamespace.firstDayOfWeek;

comment:27 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:28 Changed 6 years ago by garcia_marc

  • Keywords i18n-fixed added; i18n admin i18n-rf removed
  • Triage Stage changed from Ready for checkin to Accepted

Fixed in branches/soc2009/i18n-improvements.

comment:29 Changed 6 years ago by garcia_marc

  • Triage Stage changed from Accepted to Fixed on a branch

comment:30 Changed 6 years ago by jezdez

  • Owner changed from garcia_marc to jezdez

comment:31 Changed 6 years ago by jezdez

  • Resolution set to fixed
  • Status changed from new to closed

(In [11964]) Fixed #7980 - Improved i18n framework to support locale aware formatting (dates and numbers) and form processing.

Thanks to Marc Garcia for working on this during his Google Summer of Code 2009!

Additionally fixes #1061, #2203, #3940, #5526, #6449, #6231, #6693, #6783, #9366 and #10891.

Note: See TracTickets for help on using tickets.
Back to Top