GNOME Bugzilla – Bug 87977
First day of week should not be Sunday
Last modified: 2005-09-11 00:28:51 UTC
The calendar widget currently displays Sunday as first day of week by default. This is wrong for some locales like "sv" where Monday is always used as first day of week (http://www.se.gnome.org/sv/lokal/datum_och_tid/index.en.html). The first day of week default should depend on the locale used.
Since the starting day of the week is currently exported in the API, changing this would be a (fairly minor) incompatible API change.
*** Bug 98888 has been marked as a duplicate of this bug. ***
"ru" locale has Monday as starting day of week too.
same for Bulgarian also it seems this information is present in the glibc 2.2.x and above locales (albeit not allways correct, as with the sv locale)
*** Bug 103014 has been marked as a duplicate of this bug. ***
Here is a patch which makes the default week-start-day locale-dependent. Since getting this information from nl_langinfo() is a glibc extension, I decided to not use nl_langinfo(), but the "magic translated string" technique.
Created attachment 16439 [details] [review] patch
- Braces misplaced - We should describe "GTK_CALENDAR_WEEK_START_MONDAY" and the property as deprecated in the docs, though we can't really deprecatean enumeration value using the #ifndef GTK_DISABLE_DEPRECATED very well. - I don't think having a property's default value correspond depend on the locale works. One of the ideas of the default value is that when serializing an interface, you can omit properties that are equal to the default. I think we probably should go with the blah_set convention like GtkTextTag, where if the property isn't explicitely set then we use the value from the locale. See gtk_toolbar_unset_style() for an example of something like this in the C API. The much simpler alternative is to simply ignore GTK_CALENDAR_WEEK_START_MONDAY entirely and use the value from the locale; I don't know if we can get away with that. Searching cvs.gnome.org/lxr for uses might tell you something.
Hmm, using the "blah_set" approach doesn't really work here, since there is no explicit setter for week_start_monday, just a set_display_options(). So setting any display option would end up marking week_start_monday as explictly set, to either true or false. I'll code up the "ignore the setting approach". lxr does what it always does to me, it doesn't work. Can't even find WEEK_START_MONDAY in gtk...
Created attachment 18444 [details] [review] ignore-the-option approach
The last patch got committed after some cleanups.
*** Bug 114198 has been marked as a duplicate of this bug. ***
*** Bug 123447 has been marked as a duplicate of this bug. ***
*** Bug 127045 has been marked as a duplicate of this bug. ***
*** Bug 130076 has been marked as a duplicate of this bug. ***
I have a problem with this patch. I have: LANG=en LC_ALL=es_ES That's because I want to read the strings of the programs in its original english, but I want other formats (Numeric, monetary, time) set to spanish. The days of the week are shown correctly in spanish, but the week starts on Sunday, as opposed to spanish time format, that begins on monday. A friend told me that you are not using nl_langinfo() to discover the time properties, because is not portable, and using instead a strings translation method. I think it could be solved using the strings translation method, but using as LANG the language set in LC_TIME, in spite of the original LANG setting of the user. In that way, one could use LANG=en and LC_TIME=es without problems.
Bug #102416 is also affected. I see also the date wrong: miércoles, febrero 04 2004 Instead of: miércoles 04 febrero 2004 The weekday is translated, but the order is taken from the LANG setting.
First, you are using incorrectly the variables. LC_ALL is a macro to set all LC_* vars to the same value. You should use instead: LANG=es_ES LC_MESSAGES=en That way is more correct. About this bug report... Your proposal have a problem, you need a call to setlocale to change the locale where you get the strings from and that function is not thread safe.
And there is no way of making a call to gettext specifying a distinct locale? Any idea?
Hi carlos. I was testing you suggestion of the locale settings: LANG=es_ES LC_MESSAGES=en And now I get the "date" output in english: $ export declare -x LANG="es_ES" declare -x LC_MESSAGES="en" $ date Fri Feb 6 03:27:42 CET 2004 Even after setting: $ export LC_TIME="es_ES" $ date Fri Feb 6 03:29:40 CET 2004 Is the LC_TIME set to the same value of the LC_MESSAGES? I can't set time in spanish and strings in english with your suggested LC/LANG settings.
There is a way to choose a different locale, but it's new and it's not available in all systems (you need latest glibc, same problem that nl_langinfo). Also, what's the problem with the data output? The problem you are having with date it's just that you don't have the needed locale support. look at /etc/locale.gen and add the needed locales. Remember that es_ES != es_ES@euro you need the full locale string. You should add also the en_EN locale and use it instead of "en"
Maybe we can put ifdefs for the glibc way of work, or set an option on gconf to override. I think this is not a common setup, so I don't mind to tweak the setting in the gconf-editor. I tried both es_ES and es_ES@euro with same results: $ export declare -x LANG="es_ES@euro" declare -x LC_MESSAGES="en" $ date Fri Feb 6 15:10:21 CET 2004 $ export LC_TIME=es_ES@euro $ date Fri Feb 6 15:11:03 CET 2004 Only with: $ export LC_ALL=es_ES@euro $ date vie feb 6 15:11:43 CET 2004 (perhaps is a problem of my distro)
The problem is with "en", you must use a valid locale string, just add the en_EN locale to your locale.gen file and rebuild the locale database. This is an offtopic problem, please, send any future comment directly to me. About the #ifdefs... I'm looking at something like that for other library. If I get something interesting I will try to expand it to any other module that needs it.
*** Bug 137144 has been marked as a duplicate of this bug. ***
I'm closing this bug now, since the original problem was fixed. If you feel strongly about the mixed locale use cases, please file a separate bug and attach a patch to optionally use nl_langinfo() if it is available.
*** Bug 150567 has been marked as a duplicate of this bug. ***
*** Bug 156373 has been marked as a duplicate of this bug. ***
People should check bug 163842 which implements this in a more correct way (on most platforms atleast).
*** Bug 315942 has been marked as a duplicate of this bug. ***