First day of week

[Marc Garcia]

Hi all!

I'll start working on a new (hopefully better) patch for ticket #1061
[1] that will allow customization of first day of week on django's
admin calendar.

IMHO this patch is very important, specially for all Django developers/
users working on countries where Sunday is not the first day of the
week, that are many [2]. It also be great to allow setting the date
format that is used in admin, and may be the whole Django.

My idea for achieving it, is specify the first day of week, and the
date format for every language, so when a website visitor set the
localization, not only translation is set, also this other
localization stuff.

The standard way to do that is under locale create LC_TIME directories
[3] with all those settings, and then use them on the code.

Could this structure be implemented in Django?

Do you have other ideas?

Could it be added to 1.0 maybe list? I think that those features are
essential for developing not only international websites, also for
developing non international websites for most countries (not US, of
course ;). If it's added to list, I'll try to have a good patch before
1.0 beta.

Thanks in advanced,
Marc

[1] http://code.djangoproject.com/attachment/ticket/1061
[2] http://en.wikipedia.org/wiki/Week#First_day_of_the_week
[3] http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/IBMp690/IBM/usr/share/man/info/en_US/a_doc_lib/files/aixfiles/LC_TIME.htm

[Antoni Aloy]

2008/6/26 Marc Garcia <garci...@gmail.com>:

>
> Hi all!
>
> I'll start working on a new (hopefully better) patch for ticket #1061
> [1] that will allow customization of first day of week on django's
> admin calendar.

+1 on that Mark.
If I can help just let me know.

--
Antoni Aloy López
Blog: http://trespams.com
Site: http://apsl.net

[Jannis Leidel]

Hi Marc,

> IMHO this patch is very important, specially for all Django
> developers/
> users working on countries where Sunday is not the first day of the
> week, that are many [2]. It also be great to allow setting the date
> format that is used in admin, and may be the whole Django.

I totally agree, it's a rather nasty interface bug.

> My idea for achieving it, is specify the first day of week, and the
> date format for every language, so when a website visitor set the
> localization, not only translation is set, also this other
> localization stuff.
> The standard way to do that is under locale create LC_TIME directories
> [3] with all those settings, and then use them on the code.

This is a double-edged sword, on the one hand it would be wonderful to
have complete locale support but on the other hand this makes issue
#1061 larger than it really is. My patches there fix the interface
bugs, but should be replaced by a more sane system sometime.

Why not making "full locale support" a post-1.0 feature and fix the
calendar bug for now, considering the tight schedule?

Cheers,
Jannis/jezdez

[Antoni Aloy]

2008/6/26 Jannis Leidel <jan...@leidel.info>:

> This is a double-edged sword, on the one hand it would be wonderful to
> have complete locale support but on the other hand this makes issue
> #1061 larger than it really is. My patches there fix the interface
> bugs, but should be replaced by a more sane system sometime.
>
> Why not making "full locale support" a post-1.0 feature and fix the
> calendar bug for now, considering the tight schedule?
>

To be honest I have to say that Jannins approach wokrs for at 99%, so
perhaps a two phase approach could be a solution. After all, Python
makes refactoring a breeze, doesn't it?

[Marc Garcia]

Well, IMHO Jannis patch solves the problem for non internationalized
applications (probably not 99% of them), and in a way that isn't the
best one (also IMHO).

I think that the best way to pass a i18n parameters from python
libraries to javascript is the existing view '/admin/jsi18n/'. Doing
it this way patch code will be probably reduce by 25%. The JavaScript
also could be easily improved by changing:

58 for (var i = week_start_day; i < week_start_day+7; i++)
{
59 if (i < 7) {
60 dayIndex = i;
61 } else {
62 dayIndex = i - 7;
63 }
64 quickElement('th', tableRow,
CalendarNamespace.daysOfWeek[dayIndex]);

by

58 for (var i = 0; i < 7; i++) {
59 quickElement('th', tableRow,
CalendarNamespace.daysOfWeek[(i + week_start_day) % 7]);
60 }

So for me the patch is a good begining, and very useful not just
because it works, also because it's a good base for a new patch. But I
think that another patch is necessary (not just because I think I can
improve it, because it hasn't been commited in several months).

Anyway, and coming back to the topic, what I want to do is getting the
value from a library based on babel [1], that will use
django.utils.translation.get_language to get the locale, and easily
it'll return the first day of week, the date format, or anything we
need for the current locale.

Then the only missing thing is set where this library should be
called, and change current hardcoded locales by calls to this library.

It doesn't sound crazy to me developing all this stuff in one month,
specially because I think that many people will be interested in
cooperating, so this will be very useful for all developers
programming internationalized websites.

[1] http://babel.edgewall.org

[Russell Keith-Magee]

On Fri, Jun 27, 2008 at 3:23 AM, Marc Garcia <garci...@gmail.com> wrote:
>
> Could it be added to 1.0 maybe list? I think that those features are
> essential for developing not only international websites, also for
> developing non international websites for most countries (not US, of
> course ;). If it's added to list, I'll try to have a good patch before
> 1.0 beta.

Unfortunately, everyone has a different list of 'must have' features
for v1.0. If we tried to include everything that everybody considers
'must have', v1.0 would never ship. From that perspective, we're not
going to add anything else new to the official list.

Yours,
Russ Magee %-)

[Marc Garcia]

I don't think that this should be included in the 'must have' list (to
avoid postponing 1.0 date). What I want is to consider this feature
for the may be list, so if a good patch is ready before 1.0 beta, it
could be commited. So if it's not ready on that time, then we forget
this feature for now, and 1.0 schedule isn't affected.

The only thing is that a commiter should review the patch before
commiting. Do you thing that it'll be too much? I can imagine the
hectic status before the releases...

On Jun 27, 11:16 am, "Russell Keith-Magee" <freakboy3...@gmail.com>
wrote:

[Marc Garcia]

I've created the new patch for this issue.

As I said before, IMHO it'll be important to commit this patch before
1.0, so current behavior is very uncomfortable for users in many
countries. And finally the patch was quite simple, just a couple of
javascript lines of code (I didn't know before that django already has
a method for defining i18n settings).

Thanks,
Marc