GNOME Bugzilla – Bug 123836
GTK+ should start weeks on Monday by default in C locale
Last modified: 2011-02-04 16:16:03 UTC
#. Translate to calendar:week_start:1 if you want Monday to be the #. * first day of the week; otherwise translate to calendar:week_start:0. #. * Do *not* translate it to anything else, if it isn't calendar:week_start:1 #. * or calendar:week_start:0 it will not work. #. #: gtk/gtkcalendar.c:720 msgid "calendar:week_start:0" As the ISO 8601 standard (http://www.cl.cam.ac.uk/~mgk25/iso-time.html) specifies Monday to be the start of the week, GTK+ running in the C locale should probably also use that by default.
Owen, whats your opinion on this ?
I don't think the ISO standard is relevant here; we are talking about user visible behavior here. The largest block of people running with the "C" translation are probably also running with a locale of en_US, whether or not they actually are in the US. I'm not absolutely opposed to changing the "C" locale and then creating a en_US.po (en.po?) that changes it back, but I don't have a good sense of what convention is used where. The US is not the only part of the world that uses the week-start-on-sunday convention. Putting on 2.4.0 for now, but if there isn't a clear consensus about what we should do, probably should be WONTFIX'ed.
Kjartan and others: opinions?
What about use the locale information instead of that strings. Those things should come from libc
I considered that when writing the code, but there is no standard for getting this information from the locale, and any code would be glibc-specific.
Carlos: That was discussed in bug 87977.
Sorry, I didn't know that. btw, I think we should use glibc 2.2 function when possible and fallback on this "hack" only if that function is not available.
That would only be extra code with no gain - translators would still have to translate the magic string to make the fallback work. Its better to wait until things are properly standardized. Here is what the glibc manual has to say about _NL_TIME_FIRST_WEEKDAY and friends: The file `langinfo.h' defines a lot more symbols but none of them is official. Using them is not portable, and the format of the return values might change. Therefore we recommended you not use them.
The point is that with the glibc function you will get the correct order when does not exists a translation for your locale, the "translator extra work" is not an issue here (it's only an extra string...) Of course, if the glic function can be changed, we should not use it. Returning to this bug issue... We should _always_ use a standard inside the source code and not the american english defaults. If someone wants en_US settings, he/she should use the en_US locale instead of C or POSIX.
The point I'd make is that it's *not* a standard for how to display calendars to users, it's a standard for how to compute the week number in the year. So, I dont' think it's really relevant here one way or the other.
From the postgresql manual (http://www.postgresql.org/docs/7.3/static/functions-datetime.html#FUNCTIONS-DATETIME-EXTRACT) "By definition (ISO 8601), the first week of a year contains January 4 of that year. (The ISO week starts on Monday.) In other words, the first Thursday of a year is in week 1 of that year." We should use always open standards, if your proposal is following any other standard as valid as the ISO ones, then just follow it, if it's not a standard then I don't understand why you don't like the ISO one.
A) As I said in the last comment, the ISO standard is *NOT* a standard for displaying calendars. It's entirely irrelevant here. B) The point of the whole exercise is to display calendars to the user in the form that the user expects. If you can show that most users that are using a locale without a GTK+ translation (English speakers, speakers of really obscure languages) expect week-start-monday, that would be the reason and the only reason to switch the C locale. (Note that one defect of using the translation is that we are keying off of LC_MESSAGES, while we should be keying off of LC_TIME, most likely)
Ok, then it's just a matter to wait for bug reports about this preference, if you get bug reports about it then we should change it. Of course, when I was talking about glibc to fetch this preference I was talking about LC_TIME "database".
The C locale in general seems to be very much standards-oriented. As an example, the C locale uses metric for LC_MEASUREMENT. So assuming C locale using ISO weeks is most likely conceptually the right thing to do. But the bottomline problem is of course, as Owen points out, that the selection will be based on LC_MESSAGES rather than LC_TIME, and that thus the locale preferences become somewhat skewed, causing interesting sideeffects like this.