I don't mean to be impatient, but come on guys...after 18 months, and you still won't even CONFIRM the problem?!

A) confirmed status doesn't mean anything for the GTK+ team. UNCONFIRMED/NEW are handled the same.

B) It's picked up from your locale settings at least on Linux and Windows. (On legacy Unix looks like there's a fallback to guessing from the user's language); an API to override that seems reasonable but non-urgent.

I'm sorry to say so, but I feel issues like this show the arrogance of Americans. Just because the "locale" combination of language and stuff like week days work well for them, they refuse to see the problems it creates for the rest of the world...

Let me give you an example: Because English is the only translation that exists and works for all OSS, I prefer to have my UI in English. But throughout Europe, the most common day to start the week, is Monday. Now, because some American gtk+ people have decided that Sunday is a better day to start the week if you want to have an English UI - I'm stuck with that!

Why is it so difficult to provide the same option as Evolution does?

Havard: your comment really doesn't help. If you want to have an english UI, you can use various locales: C (US), en_AU (Australia), en_CA (Canada), en_GB (UK), etc. There's no reason to be stuck with american english.

OK, so tell me
1. Which locale will give me US English language and weekday that starts on Monday?
2. Continued from http://bugzilla.gnome.org/show_bug.cgi?id=360101 - how can I set the locale described in (1) ?

"export LC_TIME=en_GB" should work.

Well...en_GB DOESN'T work... :-/

Look at http://gentoo-wiki.com/HOWTO_localedef#Setting_the_beginning_of_the_week
It's incredible that people need to write HOWTOs to work around popular features that are rejected by GNOME/GTK+ developers :-)

Whatever happened to freedom of choice, anyway?

Seems like the easiest option is to change the locale definitions for en_US - do you know how to do that on Ubuntu? I can edit /usr/share/i18n/locales/en_US, but which command do I need to run to put it into effect?

Havard: I'm sorry, I can't help further. There's quite some other information about this in another GTK+ bug (don't have time to look for it at the moment -- but search in bugzilla for "day" and "week" in the GTK+ product)

> Whatever happened to freedom of choice, anyway?

It went down the drain together with politeness and respect.

Maybe it would be a good idea to add an "en@international" (or whatever suitable name) localisation, that would otherwise be like en_GB (because British spelling is outside North America usually the preferred, right?), but differ in a few regards to use even more international conventions, like translating the "calendar:week_start:0" string to "calendar:week_start:1". I would at least like to use a such localisation...

Take it up with the en_GB translation team... (for GTK+ this seems to be Abigail Brady <morwen@evilmagic.org>, Gareth Owen <gowen72@yahoo.com>)

Actually, I have a secret plan to bring back some form of GTK_CALENDAR_WEEK_START_MONDAY at some point, with a default of 'whatever the locale says'. I'm growing tired of all the people who whine about their locale getting it wrong...

Hmmm...

No, I don't like any of the solutions posted so far. I think, really, the solution is to modify how locale information such as the first day of the week is handled on a per-user basis.

Yes, it might entail some changes Linux-wide to locale information lookup (maybe if "locale -k LC_TIME" is the standard way of accessing it, "locale" can handle it instead?) but honestly I'd rather have that then a hacked up GTK_CALENDAR_WEEK_START_MONDAY variable.

And if it does come down to that, remember that Evolution actually already has this variable set up in gconf titled "/apps/evolution/calendar/display/week_start_day", so GTK_CALENDAR_WEEK_START_MONDAY would be redundant as far as I know.

My intent by my forceful speaking is not to vent, but to make sure the developers here don't pass over this lightly.

(In reply to comment #12)
> And if it does come down to that, remember that Evolution actually already has
> this variable set up in gconf titled
> "/apps/evolution/calendar/display/week_start_day", so
> GTK_CALENDAR_WEEK_START_MONDAY would be redundant as far as I know.

Note that that's only an application specific setting. If there's a need for a setting it must be global. Otherwise you will end up changing the start of the week in every single application after creating your user account.

The right thing to do is to set LC_TIME to nb_NO.UTF-8 (I'm guessing Norway from the name Harvard...) 

That will give you:

 English messages
 Time formatting appropriate to Norway

Including other things like the correct day/month/year formats. Now, yes, it will also give you Norwegian day and month names. If that bothers you, you can find another locale to use. 'en_DK' exists on my system, for example.

It's perfectly legitimate to say that GNOME as a desktop should have a way of setting LC_TIME in a preferences dialog. A real issue. Not a GTK+ bug report though. It may even be that GTK+ needs a way to dynamically pick up that setting via an XSETTING. That's a GTK+ bug report, but not this one.

This bug is asking for an API to set it from the application. That means you need to:

 A) Find every app developer that uses a GtkCalendar and make them add a preference for the week start
 B) Find every preference dialog and change it there

I have:

    export LC_TIME=en_DK.UTF-8

in my .bashrc, and it helps mostly (at least the damn time is 24 hour) but even then there are still other annoyances.

++

I must admit that I have long been insanely exasperated by the inability to finely control time and date formatting.

The notion that locale somehow gets this right for everyone is ridiculous; the fact that there's no (system, or better yet GNOME) way to easily create your "own" locale or otherwise override/update an existing one is such a shame.

This is the sort of thing that falls in between the cracks between projects (and more to the point, in the gap between groups of people and their area of influence) and historically Open Source has had great difficulty with such issues. Doesn't mean we can't or won't work to improve it, though.

AfC

Well, I have now tried

    export LC_TIME="no_nn.UTF-8"

and

    export LC_TIME=en_DK.UTF-8

None of them gives me Monday as start of week in the clock applet. Any other suggestions?

A lot of good comments from Jacob, Christian and Andrew - that I can easily agree with. But it doesn't help much in the short term :-( I don't even know who would be the right people to pick it up in the long term, so I won't hold my breath.

I have now tried the solution suggested by Vincent, and it doesn't do what he claims it SHOULD do. So to me, it (still) seems like a bug in the clock applet (No, Owen, this bug report is NOT asking for a new API, just to be able to have weeks starting on Monday in the clock applet...)

##

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME=en_DK.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

(In reply to comment #15)
> This is the sort of thing that falls in between the cracks between projects
> (and more to the point, in the gap between groups of people and their area of
> influence) and historically Open Source has had great difficulty with such
> issues. Doesn't mean we can't or won't work to improve it, though.

I agree 100%!

(In reply to comment #14)
> This bug is asking for an API to set it from the application. That means you
> need to:
> 
>  A) Find every app developer that uses a GtkCalendar and make them add a
> preference for the week start
>  B) Find every preference dialog and change it there  

Despite the challenges, let's not shy away from the true solution to this bug. If such a major change is needed because the current structure is insufficient, so be it! At least tell us how to improve our chances of getting this done and we, or at least I, will work towards that goal.

As for this bug specifically, I'm don't think a temporary solution should be put in place (besides the heavy workaround of creating your own locale <http://gentoo-wiki.com/HOWTO_localedef#Setting_the_beginning_of_the_week>) because that will inadvertently give developers an excuse from gathering together and working on the real thing. It's fix right or bust in my opinion.

Since this bug report is a GTK+ bug report and thus doesn't have the scope required to fix the problem fully, I suggest we create a new bug report at whatever project the locale system resides in and start from there.

Harvard: if LC_TIME doesn't work for you, it may mean that you aren't running on Linux or aren't running on a version of Linux from the last few years. See bug 163842 for history on the check we do. I did test it and it worked for me. Another possibility: if you are trying it for the clock applet, you may not be succeeding in setting LC_TIME at the right point in the login process.

Oh wow..."aren't running on Linux" :))

Well, I run a pretty vanilla Ubuntu 8.04, which IS Linux last time I checked. And, gee, I think it's even "from the last few years"...

I put it into ~/.bashrc - it may not be the right place, but that's what Andrew suggested in comment #15. Do you have a better suggestion?

Also, check the other bug (http://bugzilla.gnome.org/show_bug.cgi?id=360101) that i mentioned in my original descriptions...there seems to be others with the same problem.

*** Bug 552317 has been marked as a duplicate of this bug. ***

After filing the (duplicated) bug 552317 I came to see what is happening here, and was really, really amazed to see how many people suggest setting LC_TIME and other solutions, and no real solution to the problem is even discussed. 

Fixing this bug in gtk+ properly needs only:

- a minor change to the GtkCalendar API (to set and get priv->week_start value),
  these would be new accessors of course

- maybe a GConf variable which can be set to change the starting day for all 
  GtkCalendars (with value from 0-6, to set ANY day as starting day), overriding
  value from LOCALE (defaults to a undefined value, following locale by default).
  Or maybe GConf is not allowed in gtk+ itself? In this case the calendar's init
  function could be modified to accept week start (0-6) as parameter? Or we could
  use the 'calendar properties'?

Considering that the week start day is already a integer in range 0-6 inside the GtkCalendar module, adding accessor functions (API change!) to set and get this would be most likely be less than 20 lines of C, with error checking. I'm not sure how the module would behave if you change the date 'on the fly', though.

As I told in the duplicated other bug, there exist calendars (not many) which don't start the week neither on sunday or monday: my personal example is Saudi Arabia, where week starts on saturday. A 'monday or sunday' toggle is not enough, and implementing free choice of start day is actually just as easy to do as the toggle.

(In reply to comment #21)
> After filing the (duplicated) bug 552317 I came to see what is happening here,
> and was really, really amazed to see how many people suggest setting LC_TIME
> and other solutions, and no real solution to the problem is even discussed. 

If you read the comments you must have overlooked the proposed solutions. Ideas involved introducing a GtkSettings value or inventing a setting on a lower level than Gtk. One of those needs to be followed instead of complaining anew every time in order to figure out a solution.

Adding any application API still doesn't make sense to me. If anything, that setting must be global, otherwise it's going to be a mess to change that setting all over the desktop, including convincing application developers of adding the new setting.

A GtkSettings value (forgot such thing exists) sounds good to me to get the desktop wide setting done. I don't think we can extend this outside GTK applications anyway, if setting ONLY the start date is needed: setting the locale environment variables from GUI for environment is different application again.

Remember that setting LC_TIME will set the month names and other strings to the selected language also in some applications (but not all... confusing). I don't know if this is a bug in these applications or not, but anyway I don't speak Arabic and can't set any LC_TIME value which would give me saturday as week starting date without getting the month names in language I don't understand. 

About the new methods for the API:

In most cases people want to see their local calendar, that's true, but adding methods to the API does not hurt either. What if someone wants to make an application which has for example multiple different calendars for different locations, with different starting days, using GtkCalendar as a widget to render these calendars? 

The API change is not big deal if it can be done by adding two new methods: of course, if the init function's parameters need to be changed that's different story, or if the GtkCalendar code does not actually support changing the week_start after gtk_calendar_init() is run. did not check this yet.

So, what is wrong with following trivial code (did not try even compiling):

static guint
get_week_start(GtkCalendar *calendar)
{
    GtkCalendarPrivate *priv = GTK_CALENDAR_GET_PRIVATE (GTK_WIDGET (calendar));
    return priv->week_start;
}

static void
set_week_start(GtkCalendar *calendar,gint day)
{
    GtkCalendarPrivate *priv = GTK_CALENDAR_GET_PRIVATE (GTK_WIDGET (calendar));
    if (day < 0 || day > 6) {
        g_warning ("Invalid day value for set_week_start ignored\n");
        return;
    }
    priv->week_start = day;
    calendar_compute_days(calendar);
}

I mean, if this works, what's the big fuss about NOT adding these methods to the GtkCalendar object? I know, we should really change gtk_calendar_init() as well to be complete, if these are added and that's a bit different story then for application developers.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/276.