GNOME Bugzilla – Bug 682928
Time/date display should follow language not region setting
Last modified: 2021-06-09 16:06:07 UTC
With the new possibilities to have a more flexible approach on the Regional and Language settings, different choices can be made which could lead to an inconsistent desktop experience. I am a new Gnome user and I used to run KDE. I have setup the English language as the main language, but as that I live in Austria I want to see the right currency symbol, the metric way of displaying the date, etc. So I set the Regional settings to Austria. Surprisingly I have now the situation where my desktop is in English, but uses the German language for the weekdays and months. It would be much better if to have the ability to have the weekdays and months following the selected Language instead of the Region setting. I don't have that much problems with it as I understand German, but imagine the situation where I am using the Chinese or Russian Region ? A deeper look it seems that Gnome is using the locale settings (LC_TIME, etc) to define the right settings on a system level. Unfortunately these settings seem not to follow the logic with regards to the LANG setting. The representation of the weekdays/months comes through the LC_TIME setting and is independent from the LANG setting. KDE seems to have resolved this by not using the LC_* settings and to create an environment where I can set all the regional settings separately (e.g. I can select the currency that I want, the time-format that I want, etc). This might not be the right approach either, but making sure that the weekdays/months are in the selected Language and not taken from the selected Region would be a huge step in having a more consistent desktop experience.
It took me a while to figure out what you meant. Hopefully this should make it clearer.
Hi Bastien, Apologies for the longer text, but I tried to explain the situation as good as possible. The main issue is that the language for the time is not following the overall language. This could lead to having the Weekday (e.g. Wednesday) displayed in a different language than the other elements of the desktop.
Yes is right, but I'm not totally in accord with the time, the time has to be localized with the regional settings. You can also set it manually.
Launchpad downstream: https://bugs.launchpad.net/language-selector/+bug/1072019
Unfortunately the locale category LC_TIME is used also to determine the display language of weekdays and months. This can be handled in respective app that displays date info. As an example, last year I wrote a patch to make the clock on the gdm greeter do the right thing by involving LC_MESSAGES. It has been applied in the Ubuntu gdm version since, but not (yet) upstream: https://bugzilla.gnome.org/show_bug.cgi?id=651506
FYI, to address this issue in Ubuntu I have proposed a patch of indicator-datetime: https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/132643 This bug should probably be filed against some similar package that is the cause in GNOME for the issue reported by Raymond Wooninck. It's not gnome-control-center.
I confirm that Gunnar fix works in Ubuntu Quantal
(In reply to comment #7) > FYI, to address this issue in Ubuntu I have proposed a patch of > indicator-datetime: > https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/132643 > > This bug should probably be filed against some similar package that is the > cause in GNOME for the issue reported by Raymond Wooninck. It's not > gnome-control-center. I don't see how that's relevant. Time uses LC_TIME, display messages use LC_MESSAGES. The question is whether LC_TIME should follow LC_MESSAGES or the regional formats such as paper size or money..
*** Bug 666924 has been marked as a duplicate of this bug. ***
You can get a list of existing locale categories by running "locale" on the command-line, a number are defined in: http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Locale-Categories.html The way I see it, those categories should be set to the same value as the messages/display language: LC_CTYPE LC_TIME LC_COLLATE LC_MESSAGES And those should follow the region setting: LC_MONETARY LC_NUMERIC LC_MEASUREMENT LC_PAPER (to be over-ridden in the printers panel) But I can also see cases where one would want LC_TIME to follow the region. iOS makes the time format follow the region settings (it's actually pretty much all it changes).
Bastien, I for one don't think that letting LC_TIME equal the locale of the selected language by default would be a correct solution. Actually, isn't the fact that date and time formats vary between countries/regions the very reason why the LC_TIME locale category exists? This is a related bug against the glib product: https://bugzilla.gnome.org/show_bug.cgi?id=687945 I believe that a proper solution to the issue of this bug should be code changes either in glib or, if that route proves to not work, in respective date/time related app.
*** Bug 689649 has been marked as a duplicate of this bug. ***
I'm inclined to agree with the bug report. The language setting should affect the language used in all of the UI. Formats is just for formats that are independent of the language (like metric vs imperial). Hope I haven't misunderstood...
True, but I want some more flexibility. I like to have my system in English, while I prefer metric formats and date formats like dd-mm-yyyy. I now have the UI in English, but the clock displays the months and days in Dutch. It looks a bit off.
(In reply to comment #15) ... > I now have the > UI in English, but the clock displays the months and days in Dutch. It looks a > bit off. Right, if the UI is in English, the months and days should also be in English. (However, the date and time format settings should still have an effect on the ordering of the relevant information, if possible.)
(In reply to comment #14) > I'm inclined to agree with the bug report. > > The language setting should affect the language used in all of the UI. Formats > is just for formats that are independent of the language (like metric vs > imperial). > > Hope I haven't misunderstood... LC_TIME controls both the format used and sometimes the weekday/month names: http://pubs.opengroup.org/onlinepubs/009604499/basedefs/xbd_chap07.html#tag_07_03_05 LC_MESSAGES, as we usually use it in applications can also influence the format, for example, this line in gnome-shell's screen shield date display: 86 this._date.text = date.toLocaleFormat(_("%A, %B %d"));• that'll translate to "%A, %B de %d" in pt_BR, so you'll get something like: Wednesday, 24 de April with the language set to portuguese and LC_TIME set to english. Having LC_TIME follow LC_MESSAGES means that at least we're getting a consistent interface, rather than stuff that's half in one language and half in another. Fixing it so that formats and month/day names are translated separately is almost impossible, given that the POSIX standard bundles them all in the same setting. If you manage to convince glib developers, we could have utilities that do most of the work for us, using the LC_TIME formats, but the LC_MESSAGES names for date formatting.
Colin, what's your opinion on this?
(In reply to comment #18) > Colin, what's your opinion on this? Honestly not my area of expertise; Matthias is likely to know more.
(In reply to comment #16) > (In reply to comment #15) > ... > > I now have the > > UI in English, but the clock displays the months and days in Dutch. It looks a > > bit off. > > Right, if the UI is in English, the months and days should also be in English. > > (However, the date and time format settings should still have an effect on the > ordering of the relevant information, if possible.) That *cannot* work. The order of the elements in the time formats varies so much between different locales, if you use the order from one locale but the month and day names from another locale, it will become a complete mess if the languages are very different. You cannot mix English or German month and day names with Chinese or Japanese date format strings. It gets completely insane when one of the languages is RTL and the other LTR. Mixing month and day names from Arabic with the format string from a language with right-to-left script gives complete nonsense.
(In reply to comment #17) > If you manage to convince glib developers, we could have utilities that do most > of the work for us, using the LC_TIME formats, but the LC_MESSAGES names for > date formatting. No, don’t do that, that won’t work well, you cannot mix the names from one language with the format from another language. This sort of works only when the languages are pretty close, i.e. it sort of works when mixing German and English here (even in such cases there are minor problems with punctuation for example). But it completely breaks down when mixing names from German with formats from Japanese or vice versa. And it gets absolutely ridiculous when mixing names form a language with right-to-left script like Arabic with formats from a language with left-to-right script like German or Japanese.
Hallo Mike. So explain me why if I choose that my system has to speak English, is right that it speak Italian. I can understand that is difficult and complex, but IMHO the actual behaviour is absurd. Regards njin
Once Quote my post on Launchpad: I installed Ubuintukylin in Italy, Ubiquity detect that I'm in Italy and automatically set the system. Once system is installed, everything is in Chinese but the calendar is translated in Italian. Regards And for the OEM ?
Fabio: Not sure how your latest comments are related to this bug report. Plus "indicator-datetime" is Ubuntu and unrelated to GNOME. For Ubuintukylin and Ubiquity stuff which is unrelated to GNOME, please ask in an Ubuntu forum.
*** Bug 708740 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > Once > Quote my post on Launchpad: > > I installed Ubuintukylin in Italy, Ubiquity detect that I'm in Italy and > automatically set the system. > Once system is installed, everything is in Chinese but the calendar is > translated in Italian. I believe it is a mistake to automatically set LC_TIME to it_IT.UTF-8 just because the system detects you are in Italy. LC_TIME should be set to a format of a locale which you are used to and where you understand the language. So in most cases it should be set to the same locale as LANG. It doesn’t really make sense to set to time and date format to something like 2013年10月01日火曜日 17時08分44秒 for a user who does not speak Japanese, only because he happens to install his system in Japan. And it doesn’t get any better by replacing the month names and weekday names with translations from another language, then you end up seeing weird mixtures like 2013年October01日Tuesday 17時08分44秒 So if you install your system in Japan and choose Italian as your language, then I think LC_TIME should also default to Italian. You man choose something else like LC_TIME=ja_JP.UTF-8 if you are really comfortable seeing the date and time fully in Japanese. If not, it is better to choose a locale for LC_TIME you are comfortable with. Mixing 2 locales in the date and time format, i.e. taking the format string from one language and replacing the month names and weekday names from another language just creates nonsense unless the 2 languages mixed are rather closely related. One should just not do such mixing.
I think we'll end up with not setting LC_TIME in the region panel, so by default, it would be dependent on the default language. People can shoot themselves in the foot by modifying config files if they so wish. Needs gnome-control-center and gnome-settings-daemon changes.
*** Bug 709713 has been marked as a duplicate of this bug. ***
I showed this to a user who knew both English and Japanese, using the Japanese language but United States "Formats." He agreed that the mix of Japanese and English in the calendar was terrible. He thought that the calendar should be displayed entirely in English, since he explicitly chose the date/time settings to be United States, but he would have been content with an entirely Japanese calendar as well. (In reply to comment #27) > I think we'll end up with not setting LC_TIME in the region panel, so by > default, it would be dependent on the default language. People can shoot > themselves in the foot by modifying config files if they so wish. I know this is a tough problem, but surely this means we have to remove dates and times from the Formats dialog. Isn't that one of the main benefits to setting the region separately from the language in the first place? (In reply to comment #26) > (In reply to comment #23) > I believe it is a mistake to automatically set LC_TIME to it_IT.UTF-8 > just because the system detects you are in Italy. I suspect the right place for that bug would be against Ubuntu's Ubiquity installer.
(In reply to comment #29) > I know this is a tough problem, but surely this means we have to remove dates > and times from the Formats dialog. Isn't that one of the main benefits to > setting the region separately from the language in the first place? Sorry, I just noticed from the initial report: (In reply to comment #0) > I have setup the English language > as the main language, but as that I live in Austria I want to see the right > currency symbol, *the metric way of displaying the date*, etc. So I set the > Regional settings to Austria. Emphasis added
Is there a workaround for this? I set LC_TIME to us_US in ~/.i18n but gnome-shell does not pick it up on normal startup (on Fedora 20). However, it is picked up by bash (running in gnome-terminal under gnome-shell) and if I run "gnome-shell -r" from there I end up with the correct (for my taste) time display.
*** Bug 728606 has been marked as a duplicate of this bug. ***
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.