GNOME Bugzilla – Bug 687945
Display names of days and months using the current language
Last modified: 2012-12-06 11:51:14 UTC
g_date_time_format() (like strftime) looks up the names of weekdays and months in the LC_TIME locale. In a mixed locale environment, more exactly when LC_TIME and LC_MESSAGES have different locales, this means that the names of weekdays and months are displayed in some other language than you would expect. For instance, on my own system I have selected en_GB.UTF-8 for language, while I'm using sv_SE.UTF-8 for regional formats. Hence the days and months are displayed in Swedish instead of English. In response to the Ubuntu bug https://launchpad.net/bugs/1072019 I suggested a wrapper function around g_date_time_format() calls in the indicator-datetime package; please see the g_date_time_format-wrapper attachment. That function, which may change LC_TIME on-the-fly when processing a format specification, seems to work as expected in indicator-datetime. However, I have discussed this with Charles Kerr, and we agreed that it would be more appropriate to make a similar change in GDateTime, so other date/time related apps benefit from it. For now we would primarily like to know if you think it's a good idea.
Created attachment 228515 [details] g_date_time_format-wrapper
Created attachment 228517 [details] [review] days_months_in_current_language I have attached a work-in-progress patch targeting glib2.0/glib/gdatetime.c, which may or may not be useful. Please note, though, that it does not work as is, at least not as well as it should. ;-) A pointer in the right direction would of course be appreciated.
It seems like our current behavior is consistent with the "date" command, which would seem to imply that it's right in some sense. Mixed locale settings are not terribly well-defined, and there are probably people who would consider the current behavior right and the behavior in your patch wrong. (Given that we know there are people with mixed locale settings, and none of them have complained about this before, that's probably even likely.) Anyway, if you're going to do it, you can't use setlocale(); that would interfere with code running in other threads at the same time (eg, possibly causing an error message being returned in another thread to get translated to the wrong language).
Hi Dan, and thanks for your comment! Well, I wouldn't consider the behavior of "date" (or "strftime") as an indication of what's right or wrong. ;-) To me it's apparent that a user who selects a display language typically expects it to be effective also for names of days and months. Having worked with i18n stuff in Ubuntu for a couple of years, I can tell you that people do complain about it once in a while. Probably those bugs just haven't made it to glib. The "See Also" field below contains two URLs to such bugs, btw. On 2012-11-09 00:14, Dan Winship wrote: > Anyway, if you're going to do it, I'm going to try, at least. Not sure if my skill is sufficient to write a patch that works and will be accepted, though. > you can't use setlocale(); that would interfere with code running in > other threads at the same time (eg, possibly causing an error message > being returned in another thread to get translated to the wrong > language). But I need to change the program's current locale, don't I? Is there any way besides setlocale() that can do that? Please note that the days_months_in_current_language patch resets the locale instantly to the previous value.
(In reply to comment #4) > But I need to change the program's current locale, don't I? No, what you need is to get LC_TIME-related information for a locale other than the current LC_TIME locale. Changing the locale is the obvious way to do that, but that would cause side effects, so you can't. It's possible that there's no easy way to do what you want. > Please note that the > days_months_in_current_language patch resets the locale instantly to the > previous value. That just means there's a smaller window for the race condition to happen, but it will still happen sometimes.
I'm very reluctant to go away from the posix behaviour (ie what strftime does). In any case, we can't call setlocale() like that - the locale is global, and you'll interfere with other threads. If we were to do this at all, it would be with uselocale(). But, as I said above, I'm not in favour of this change.
Created attachment 228661 [details] [review] days_months_in_current_language_2 As usual I have difficulties to understand why everybody else don't think like me. :) On 2012-11-10 00:29, Matthias Clasen wrote: > I'm very reluctant to go away from the posix behaviour (ie what > strftime does). Why is that? It would make g_date_time_format() better than strftime() in this respect, since it would facilitate a behaviour in date/time apps in accordance with common user expectations. Better to change g_date_time_format() than letting people reinvent the wheel. I think that the behaviour should be disclosed, and the latest patch includes a suggestion for the reference manual. Even if uselocale() seems to make a significant difference - thanks Matthias ;-) - the latest patch is still not uploadable. The program tends to segfault when a string with multiple conversion specifications is passed to g_date_time_format(). Some assistance with solving this issue would be much appreciated. Another thing is that the proposed change to g_date_time_format() (unlike the g_date_time_format-wrapper I wrote for indicator-datetime) does not affect the day and month names in the indicator-datetime calendar. However, that's probably a pure indicator-datetime issue. -+-+-+- "If you want to make enemies, try to change something." - Woodrow Wilson (1856-1924)
Created attachment 228751 [details] [review] days_months_in_current_language_3 Think I solved the segfault problem. The culprit seems to have been a freelocale() call, so I dropped it and took the opportunity to make the variable that holds the locale object a static variable. Now I propose that the latest patch, days_months_in_current_language_3, is applied as a solution to this bug.
I occasionally use my computer in a language that is not my own, but I always prefer to see Canadian date formats. I understand the appeal of this patch because it's a bit jarring to see the words in dates written in English when everything else is not... This is a pretty serious departure from POSIX, however... without thinking about user expectations (users being "those normal/sane people that have the benefit of not knowing know what LC_TIME is") I'd say that it's almost certain that programmers expect our current behaviour. The question is how much we care about that...
On 2012-11-12 09:17, Ryan Lortie wrote: > This is a pretty serious departure from POSIX Possibly. That's why I suggest that it's disclosed in the docs. * We should always take pains with meeting the expectations of 'ordinary' users. * Programmers should read the docs for the functions they use. * The proposed change would _make it easier_ for programmers of date/time related apps to meet user expectations.
Review of attachment 228751 [details] [review]: ::: glib2.0-2.34.1.orig/glib/gdatetime.c @@ +2254,2 @@ g_string_append (outstr, WEEKDAY_ABBR (datetime)); + uselocale (LC_GLOBAL_LOCALE); this is not right - what if the thread was using a thread-local locale before ? you havfe to go back to the locale returned by the previous call to uselocale()
Also note that you need to have fallback code for when uselocale is not available. See similar code in gstrfuncs.c. Previous discussion on this topic in bug 655960 - people can and do set LC_TIME and expect their dates to come out in that locale, formats and names. I still think that it is pretty broken to take the date format from LC_TIME, but the names from LC_MESSAGES. You end up with a mixed string that looks foreign to both audiences...
Created attachment 228966 [details] [review] days_months_in_current_language_4 On 2012-11-13 11:47, Matthias Clasen wrote: > Previous discussion on this topic in bug 655960 - I didn't know that g_date_time_format() previously behaved the way I propose now, but then via gettext and translators. Please note that I do not propose a reintroduction of the gettext approach. :) > people can and do set LC_TIME and expect their dates to come out in > that locale, formats and names. With this change: s/people/some programmers who are used to strftime/ I would agree. Ok, programmers are also people, but a special kind... > I still think that it is pretty broken to take the date format from > LC_TIME, but the names from LC_MESSAGES. You end up with a mixed > string that looks foreign to both audiences... Please bear in mind that users who would be affected by this change choose to distinguish between language and formats. Given that, I'm convinced that they typically would find it satisfying that the names of days and months - just like other words on the screen - were displayed in the language of their choice. The reporter (programmer) of bug 655960 is probably an exception. As for the proposed code, I have tried to comply with your guidance, Matthias, so now there is a fourth patch version.
I sorry, but I still don't think it makes any sense to use language A's time format with strings from language B...
Hi guys, I am one of those mythical "users" who (would like to) use a mixed-locale system. I prefer to use English as the system language, but the Hungarian regional formats for time, paper size, etc. I am definitely on Gunnar's side in this issue; for me the Hungarian names for months and weekdays seem very out of place in an otherwise English interface. The reason for this, I think, is that months and weekdays are words, while the other visible items that depend on the locale are numbers. Numbers are kind of universal, so it is easier to tolerate a difference in what numbers are displayed (or the ordering thereof) as having an interface with both, say, English and Hungarian text. I don't know if this helps my case, but as I remember, this is how it works in Windows (and KDE); and I think if their users didn't like thid behavior, we would have surely heard of it.
On 2012-11-29 12:04, Matthias Clasen wrote: > I still don't think it makes any sense to use language A's time > format with strings from language B... But is that really what this is about? I wrote this test script: $ cat test.c #include <glib.h> #include <locale.h> #include <stdio.h> main () { GDateTime *d = g_date_time_new_utc (2012, 11, 16, 17, 5, 42); gchar *loc[] = { "en_GB.UTF-8", "en_US.UTF-8", "en_CA.UTF-8", "en_DK.UTF-8", "fr_CA.UTF-8", "fr_FR.UTF-8", NULL }; setlocale (LC_ALL, ""); gint i; for (i = 0; loc[i] != NULL; i++) { setlocale (LC_TIME, loc[i]); printf ("%s:\n", loc[i]); printf ("%%c => %s\n", g_date_time_format (d, "%c")); printf ("%%x => %s\n\n", g_date_time_format (d, "%x")); } } $ And this is its output: en_GB.UTF-8: %c => Fri 16 Nov 2012 17:05:42 UTC %x => 16/11/12 en_US.UTF-8: %c => Fri 16 Nov 2012 05:05:42 PM UTC %x => 11/16/2012 en_CA.UTF-8: %c => Fri 16 Nov 2012 05:05:42 PM UTC %x => 12-11-16 en_DK.UTF-8: %c => 2012-11-16T17:05:42 UTC %x => 2012-11-16 fr_CA.UTF-8: %c => ven 16 nov 2012 17:05:42 UTC %x => 2012-11-16 fr_FR.UTF-8: %c => ven. 16 nov. 2012 17:05:42 UTC %x => 16/11/2012 We see four different time/date formats for the language English and two different formats for the language French. This indicates that a time format is not tied to a particular language, but it expresses the convention in a country or region. So I'd say that what I propose is that region X's time format is used with strings from language A. And I see no problem with that, particularly since that's what the user asks for.
(In reply to comment #16) > So I'd say that what I propose is that region X's time format is used with > strings from language A. And I see no problem with that, particularly since > that's what the user asks for. I don't see how you can conclude that the user is asking for that, when the environment variables that he sets are documented to do something else...
In fairness, the current system provides no mechanism by which the user could possibly ask for anything else...
The user I have in mind does not know anything about environment variables or POSIX. ;-) He just selects a language and makes a choice as regards the formats for a particular region.
No point in going around in circles more. I'm just going to WONTFIX this.