GNOME Bugzilla – Bug 789205
date in Top Bar don't follow regional format
Last modified: 2018-09-21 16:46:58 UTC
Created attachment 361886 [details] screenshot if "Show date" is checked in Tweaks, the date doesn't display with the proper regional format style. It does in the drop-down menu. To me today it's Thursday, October 2019. See attached screenshot.
The top bar clock is using gnome-desktop's WallClock, reassigning.
Created attachment 361890 [details] [review] wall-clock: Use LC_TIME for strftime format string translations In order to handle the clock's various display setting correctly for different locales, we mark strftime format strings for translation. However those translations are looked up according to the locale defined by LC_MESSAGES, while the conversion characters themselves are resolved according to LC_TIME, with rather odd results when mixing locales. The correct solution would be to install translations for format strings in the LC_TIME catalogue and look them up with dcgettext(), but we don't have the infrastructure to do that easily. Work around this by adding a helper method that looks up a string in LC_MESSAGES using the locale defined by LC_TIME and use that to translate the format strings, which has the same result.
Created attachment 361891 [details] [review] wall-clock: Use LC_TIME for strftime format string translations - keep marking format strings for translation - use the correct domain instead of NULL
*** Bug 795912 has been marked as a duplicate of this bug. ***
Is there any way to see the status/scheduling of this bug in terms of it's standing in the stack of tasks you guys are working on?
Review of attachment 361891 [details] [review]: I mean, the patch was already here, just sitting awaiting review, but nobody watches Bugzilla for gnome-desktop so no review was going to be forthcoming. Anyway, r- due to the setenv() use. This will cause the desktop to randomly crash if the user is sufficiently unlucky. The possible solutions are the same as I described in https://gitlab.gnome.org/GNOME/gnome-desktop/merge_requests/15#note_294280: either add new API to gettext() if you're brave, or just install a subprocess in libexecdir and launch it for looking up the translation. Obviously the later is much easier and the approach I would expect, but the former is an option. It might seem overkill to have a subprocess to look up a translation, but it's not overkill if it's required for correctness. I don't see any way around it.
(In reply to Michael Catanzaro from comment #6) > Review of attachment 361891 [details] [review] [review]: > > I mean, the patch was already here, just sitting awaiting review, but nobody > watches Bugzilla for gnome-desktop so no review was going to be forthcoming. > > Anyway, r- due to the setenv() use. Sorry, setlocale(), which of course is not safe either. (Yes, I know the surrounding code does this, but that should be fixed rather than copied.) (Yes, I know gnome-initial-setup does this too, but I've no clue how to fix that.)
-- 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/gnome-desktop/issues/72.