GNOME Bugzilla – Bug 716533
shotwell doesn't seem to take LC_TIME or 12/24-hour settings fully into account
Last modified: 2016-08-21 10:15:38 UTC
---- Reported by shotwell-maint@gnome.bugs 2010-08-21 03:45:00 -0700 ---- Original Redmine bug id: 2462 Original URL: http://redmine.yorba.org/issues/2462 Searchable id: yorba-bug-2462 Original author: corec - Original description: I'm using a mixed language environment which has LC_MESSAGES set to en_US.%(=caps)UTF%-8 and all other LC_ variables set to fi_FI.%(=caps)UTF%-8. This brings a problem as Shotwell doesn't seem to respect LC_TIME variable on all places. LC_TIME should govern date and time formats shown to user(1). If I run Shotwell normally I get all texts in English as they should, date in Finnish format as it should and time in partial English format without "AM/PM" stuff. I'll attach a screenshot so you'll see what I mean. Also the "Adjust date and time" window shouldn't show the "AM/PM/24Hr" combobox for those languages that use only one format. I mean if that info is possible to be dug out from somewhere. :) (1): http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html Related issues: related to geary - 3824: internationalization: locale-specific date formatting (Fixed) related to shotwell - 6939: Date format in side bar (Open) ---- Additional Comments From shotwell-maint@gnome.bugs 2013-06-26 15:34:00 -0700 ---- ### History #### #1 Updated by corec - over 3 years ago What I mean with the partial English format is that if I have a photo which has time of “19:20â€, Shotwell will show only “7:20†without the trailing AM of PM. It's quite confusing when you don't know if it was taken at morning or evening. Here in Finland we only use the 24 hour representation. #### #2 Updated by Marcel Stimberg almost 3 years ago The issue seems to appear in less customized language environments as well, e.g. if you set the language to ru_RU.utf8 (which should use a 24h format) you get this “12h without am/pm†times. Reported here: https://bugs.launchpad.net/shotwell/+bug/689055 #### #3 Updated by Marcel Stimberg almost 3 years ago I investigated the issue a bit more, the two cases are a bit different. The time in the properties sidebar is by default formatted as “%I:%M %p†(i.e. 12h am/pm format). This time format is marked for translation, i.e. translators should provide an equivalent in the respective language. @corec: Because you have set LC_MESSAGES to en_US.%(=caps)UTF%-8, no translation is used, i.e. you get the standard format string. However, when doing the formatting, your LC_TIME variable _is_ taken into account, and as the Finnish locale does not set a am/pm equivalent for %p you get this “partial English formatâ€. In the simpler case of the Russian locale, the time format is simply not translated in the PO file (it should be “%H:%Mâ€). To avoid all these issues, I'd propose to simply use the format string “%X†(=locale time format) for all locales, i.e. not marking it as translatable but letting strftime do the job, taking LC_TIME automatically into account. The only “regression†would be that this format normally includes seconds -- but actually I'd personally prefer to have the seconds displayed :-) #### #4 Updated by Adam Dingle almost 3 years ago I've crated a separate ticket for the Russian translation #2958. #### #5 Updated by Marcel Stimberg almost 3 years ago If you want to keep using a translation for the time format here, maybe a solution would be to temporarily switch LC_MESSAGE to the value of LC_TIME when asking for the translated time format? This patch should do what I have in mind. #### #6 Updated by Adam Dingle almost 3 years ago * **Priority** set to _High_ #### #7 Updated by Adam Dingle almost 3 years ago Marcel, thanks for the thought you've put into this. We discussed this recently at Yorba. We thought about your suggestion to use %X, but we're reluctant to do that since we'd rather not display seconds in the information area since we think they will be irrelevant for most photographs. It's a bit late to take your patch for 0.8, but we'll consider it for 0.9. We could alternatively play other tricks to be able to display a locale-specific time without seconds – see e.g. http://stackoverflow.com/questions/2507726/how-to-display-locale-sensitive- time-format-without-seconds-in-python #### #8 Updated by Marcel Stimberg almost 3 years ago There has been a very similar discussion for the new datetime indicator in ubuntu (the replacement for the clock applet). See this discussion for more details and a patch (using a similar approach to my patch): https://bugs.launchpad.net/ubuntu/source/indicator-datetime/bug/652976 The cleanest solution would actually be to use dcgettext for dates and times, i.e. something like string format = dcgettext(Resource.APP_GETTEXT_PACKAGE, "%I:%M %p", LocaleCategory.TIME); However, this will look for translated times in the LC_TIME directory and not in LC_MESSAGES where the usual translations end up -- I'm not sure whether this would be possible to integrate in the current translation workflow. #### #9 Updated by Adam Dingle almost 3 years ago * **Target version** set to _0.9_ #### #10 Updated by Adam Dingle over 2 years ago * **Target version** deleted (<strike>_0.9_</strike>) A bit late to look at this for 0.9 now. #### #11 Updated by Adam Dingle over 2 years ago * **Target version** set to _0.11_ Would be nice to fix for 0.11 if possible. #### #12 Updated by Lucas Beeler over 2 years ago * **Target version** deleted (<strike>_0.11_</strike>) #### #13 Updated by Lucas Beeler about 2 years ago * **Description** updated (diff) * **Status** changed from _Open_ to _Review_ * **Target version** set to _0.12_ #### #14 Updated by Adam Dingle over 1 year ago * **Target version** deleted (<strike>_0.12_</strike>) #### #15 Updated by Adam Dingle over 1 year ago * **Description** updated (diff) Also reported downstream at https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1035067 #### #16 Updated by Adam Dingle over 1 year ago * **Target version** set to _0.13_ #### #17 Updated by Adam Dingle about 1 year ago * **Status** changed from _Review_ to _Open_ * **Assignee** set to _Clinton Rogers_ I looked into this more and looked at the attached patch. As Marcel mentioned in comment #8 above, the Unity date/time indicator switches locales in the same way when looking up format strings. Unfortunately this isn't threadsafe since setlocale() affects the entire process. So really we should either 1) use uselocale() instead of setlocale(), or 2) use setlocale(), but look up the format string translation during startup and cache the result for later use There's no Vala binding for uselocale(), so (2) is probably the easiest approach. Clint, could you implement that so we can commit this for 0.13? #### #18 Updated by Jim Nelson about 1 year ago There's one proviso to the patch that must be taken into account: the LANGUAGE environment variable must be cleared prior to monkeying with the locales (and reset when finished). More information here: http://redmine.yorba.org/issues/3824#note-14 #### #19 Updated by Clinton Rogers about 1 year ago * **File** 2462.patch added * **Status** changed from _Open_ to _Review_ * **% Done** changed from _0_ to _70_ #### #20 Updated by Clinton Rogers about 1 year ago * **Status** changed from _Review_ to _5_ * **% Done** changed from _70_ to _100_ * **Resolution** set to _fixed_ c9b40dfe1bd3cf0a9ad9361753cce7f62710846e #### #21 Updated by Charles Lindsay 7 months ago * **Status** changed from _5_ to _Fixed_ #### #22 Updated by Tomáš Hnyk 5 months ago When setting my locale to LC_TIME=en_GB.UTF-8 I get PM and AM format but according to this (and what Language Support in System Setting shows): http://superuser.com/questions/327248/linux-forcing-24 -hour-locale I should get 24 hour locale? What is wrong? If I set it to for example to Czech locale cs_CZ.utf8, I get 24 hour format, so it does get picked up, it only seems GB is somehow badly read? #### #23 Updated by Jim Nelson 5 months ago When you run Shotwell with LC_TIME set, do you see this? (process:29578): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. #### #24 Updated by Tomáš Hnyk 5 months ago Yes, that is exactly what I get. What does it mean? Is something wrong with my system (ubuntu 13.04) or Shotwell? #### #25 Updated by Jim Nelson 5 months ago I don't know what it means, but I'm seeing it on my Raring machine and I'm certain it's responsible. I found this page: http://www.linuxquestions.org/questions/linux-software-2/gtk-warning -**-locale-not-supported-by-c-library-202951/ Which suggested this command: $ sudo dpkg-reconfigure locales It didn't solve the problem for me, but it's a start. You might keep digging to see what you find. #### #26 Updated by Tomáš Hnyk 5 months ago Hm, that actually solves the error. However, the date is still AM/PM. I tried setting en.IE.UTF-8 which according to this should set 24-hour format: http://unix.stackexchange.com/questions/62316/why-is-there-no-euro-english- locale but it does not :-/. #### #27 Updated by Lucas Beeler 5 months ago @Jim: Could you try opening the System Settings applet on your computer, and then opening the "Language Support" control panel? Note that the name of this control panel has changed over various versions of Ubuntu. It has also been called "International" or "International Support." Anyway, when you first open this panel, you should get a message saying "Language support is not properly set up. Would you like to set it up now?" Then simply click "Yes." #### #28 Updated by Tomáš Hnyk 5 months ago I opened the panel many times and the first time I had this dialog, but now it does not come (and I clicked yes so the support should be installed). Is there a way to discern if it is just Shotwell that does not understand the locale or if it concerns all applications? I cannot think of any other application that would show this. #### #29 Updated by Jim Nelson 5 months ago * **Category** set to _ux_ * **Status** changed from _Fixed_ to _Open_ * **Assignee** deleted (<strike>_Clinton Rogers_</strike>) * **Target version** deleted (<strike>_0.13_</strike>) I've gone through all this and am still seeing the problem. Additionally, I run my desktop using 24-hour time anyway, and Shotwell still shows AM/PM regardless of the LC_TIME environment variable. I'm reopening this until we have a better idea of what the problem is here. Tomás, the only application I can think of that you could test against is Nautilus, by looking at a file's properties (modified date/time). #### #30 Updated by Tomáš Hnyk 5 months ago Hm, nautilus shows military time even if I set locale to US :-/. #### #31 Updated by Jim Nelson 5 months ago The best of both worlds! Since Nautilus is probably already running (it handles the desktop), you might need to kill it and re-rerun with different settings or environment variables. #### #32 Updated by Adam Dingle 5 months ago By the way, I believe that Nautilus doesn't use LC_TIME or other environment variables to decide whether to display 24-hour time. Instead, it uses GNOME's 12/24-hour time setting, which is unfortunately not exposed in Ubuntu's version of the GNOME control center. See https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1174261 --- Bug imported by chaz@yorba.org 2013-11-25 21:46 UTC --- This bug was previously known as _bug_ 2462 at http://redmine.yorba.org/show_bug.cgi?id=2462 Imported an attachment (id=261729) Imported an attachment (id=261730) Imported an attachment (id=261731) Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
There are, I believe, two separate but related problems here. First, Shotwell is using LC.TIME to fetch the format strings for the various pretty-printed dates and time by temporarily setting the locale to the language locale (Geary uses a similar trick). However, when those locale-specific strftime formatting strings were added to the code, no translator comments were added. So, most translators just skip by them because they look like garbage ("%-I:%M %p"), meaning most translations are using US formats. That needs to be fixed. However, that merely means translators will be in the position to decide what time formats make sense for their locale. Since there's a desire to allow for 12/24 hour formats to be chosen by the user, Shotwell should also have 24-hour format strings (which should be localized, although I suspect they won't have to be touched by translators) and determine which set of strings to use at runtime by examining the above setting. The second item could be broken off as a separate ticket, but I'm leaving it here now until some work is done to get this whole matter shaped up.
*** Bug 722036 has been marked as a duplicate of this bug. ***
I added the translator comments to the strftime strings in commit c767099.
*** Bug 719259 has been marked as a duplicate of this bug. ***
Created attachment 329152 [details] [review] Patch for spanish translation Update some strings to resflect the use of the 24h format in the spanish language.
(In reply to L. López from comment #5) > Created attachment 329152 [details] [review] [review] > Patch for spanish translation > > Update some strings to resflect the use of the 24h format in the spanish > language. Does that really make sense? That's forcing 24h all the time, no, ignoring the setting in shotwell?
(In reply to Jens Georg from comment #6) > Does that really make sense? That's forcing 24h all the time, no, ignoring > the setting in shotwell? Well, may be it's not the ideal solution but I think it's the only possible solution. Following the code: 1- Properties.vala uses Resources.get_hh_mm_format_string() to get the timestamp on the desired format. > protected string get_prettyprint_time(Time time) { > string timestring = time.format(Resources.get_hh_mm_format_string()); > > if (timestring[0] == '0') > timestring = timestring.substring(1, -1); > > return timestring; > } 2- In Resouces.vala: "Resources" class initializes some consts to null (some cache-like schema) until it's requested, then fetch_lc_time_format is called to update them. > public string get_hh_mm_format_string() { > if (HH_MM_FORMAT_STRING == null) { > fetch_lc_time_format(); > } > > return HH_MM_FORMAT_STRING; > } 3- fetch_lc_time_format() simply initializes those consts to the values from .po files: > HH_MM_FORMAT_STRING = _("%-I:%M %p"); https://github.com/GNOME/shotwell/blob/644f056255e903d56eff4a152911da86ea164803/src/Resources.vala#L753 At this point there is no way to handle 12/24h format beyond po files. As far as I can see there is no Glib time format modifier that handles 12/24h from user LC_* variables, you have to choose one at translation level. In Spain maybe 99% of us use 24h format, definitively virtually no one uses 12h. The current format ("%-I:%M %p") is very annoying to us. "%p" resolves to "" and "%-I" is ambiguos (there is no diference between 12am or 12pm, both are formated as "12") Finally, this bug is 6 years old, its time to fix it.
Oh. I had seen the org.yorba.shotwell.preferences.ui use-24-hour-time setting, but apparently that's not used anywhere. weird. Can you coordinate with the gnome translation people if you are not part of the spanish translation team to get this in then?
The whole time string thing is moderately broken :-/
Actually, we should probably just use "%x" here and let strftime do the locale handling
Created attachment 333437 [details] [review] Sort out locale-dependent times Signed-off-by: Jens Georg <mail@jensge.org>
(In reply to Jens Georg from comment #8) > Oh. I had seen the org.yorba.shotwell.preferences.ui use-24-hour-time > setting, but apparently that's not used anywhere. weird. It's used just for "Adjust time/date" dialog. > Can you coordinate with the gnome translation people if you are not part of > the spanish translation team to get this in then? I'm not part of the translation team however, last time I checked, joining the team required lots of bureaucracy for just two lines. I have seen other solutions like #10 or, specially, #11 (but using %X instead of %x) which look better.
(In reply to L. López from comment #12) > (In reply to Jens Georg from comment #8) > > Oh. I had seen the org.yorba.shotwell.preferences.ui use-24-hour-time > > setting, but apparently that's not used anywhere. weird. > > It's used just for "Adjust time/date" dialog. > > > Can you coordinate with the gnome translation people if you are not part of > > the spanish translation team to get this in then? > > I'm not part of the translation team however, last time I checked, joining > the team required lots of bureaucracy for just two lines. > > I have seen other solutions like #10 or, specially, #11 (but using %X > instead of %x) which look better. Yeah, sorry, I mixed up %x (date) and %X (time). Can you point me to the better-looking examples?
(In reply to Jens Georg from comment #13) > Yeah, sorry, I mixed up %x (date) and %X (time). Can you point me to the > better-looking examples? I'm sorry, I expressed myself wrong, I intended to say that your solution seems OK to me. IMHO using %x/%X is a good compromise among other options. Can this fix be backported to current stable branch?
Created attachment 333476 [details] [review] Sort out locale-dependent times Signed-off-by: Jens Georg <mail@jensge.org>
(In reply to L. López from comment #14) > (In reply to Jens Georg from comment #13) > > Yeah, sorry, I mixed up %x (date) and %X (time). Can you point me to the > > better-looking examples? > > I'm sorry, I expressed myself wrong, I intended to say that your solution > seems OK to me. IMHO using %x/%X is a good compromise among other options. > > Can this fix be backported to current stable branch? What do you mean by current stable? 0.22? That should not be used anymore due to security issues with online publishing.
(In reply to L. López from comment #12) > I'm not part of the translation team however, last time I checked, joining > the team required lots of bureaucracy for just two lines. > You can always report bugs and patches on Bugzilla! Product l10n, component Spanish [es]. :)
Attachment 333476 [details] pushed as 45dfd34 - Sort out locale-dependent times