After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 716533 - shotwell doesn't seem to take LC_TIME or 12/24-hour settings fully into account
shotwell doesn't seem to take LC_TIME or 12/24-hour settings fully into account
Status: RESOLVED FIXED
Product: shotwell
Classification: Other
Component: ux
unspecified
Other All
: High normal
: 0.24
Assigned To: Shotwell Maintainers
Shotwell Maintainers
: 719259 722036 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-08-21 10:45 UTC by Shotwell Maintainers
Modified: 2016-08-21 10:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot to show the odd time format (7.95 KB, image/png)
2010-08-21 10:46 UTC, Shotwell Maintainers
  Details
temporarily switch LC_MESSAGES to LC_TIME to get a correctly translated time format (1.03 KB, patch)
2010-12-14 21:21 UTC, Shotwell Maintainers
none Details | Review
2462.patch (6.87 KB, patch)
2012-09-14 21:26 UTC, clinton
committed Details | Review
Patch for spanish translation (845 bytes, patch)
2016-06-05 12:17 UTC, L. López
none Details | Review
Sort out locale-dependent times (1.75 KB, patch)
2016-08-16 19:03 UTC, Jens Georg
none Details | Review
Sort out locale-dependent times (3.29 KB, patch)
2016-08-17 09:28 UTC, Jens Georg
committed Details | Review

Description Charles Lindsay 2013-11-25 21:46:17 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 

Comment 1 Jim Nelson 2014-01-13 23:07:12 UTC
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.
Comment 2 Jim Nelson 2014-01-13 23:08:43 UTC
*** Bug 722036 has been marked as a duplicate of this bug. ***
Comment 3 Jim Nelson 2014-01-14 19:57:05 UTC
I added the translator comments to the strftime strings in commit c767099.
Comment 4 Jim Nelson 2014-03-04 23:00:19 UTC
*** Bug 719259 has been marked as a duplicate of this bug. ***
Comment 5 L. López 2016-06-05 12:17:28 UTC
Created attachment 329152 [details] [review]
Patch for spanish translation

Update some strings to resflect the use of the 24h format in the spanish language.
Comment 6 Jens Georg 2016-08-13 22:25:31 UTC
(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?
Comment 7 L. López 2016-08-16 13:28:00 UTC
(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.
Comment 8 Jens Georg 2016-08-16 15:13:48 UTC
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?
Comment 9 Jens Georg 2016-08-16 15:17:31 UTC
The whole time string thing is moderately broken :-/
Comment 10 Jens Georg 2016-08-16 16:02:34 UTC
Actually, we should probably just use "%x" here and let strftime do the locale handling
Comment 11 Jens Georg 2016-08-16 19:03:17 UTC
Created attachment 333437 [details] [review]
Sort out locale-dependent times

Signed-off-by: Jens Georg <mail@jensge.org>
Comment 12 L. López 2016-08-17 07:35:05 UTC
(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.
Comment 13 Jens Georg 2016-08-17 08:47:03 UTC
(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?
Comment 14 L. López 2016-08-17 09:15:58 UTC
(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?
Comment 15 Jens Georg 2016-08-17 09:28:33 UTC
Created attachment 333476 [details] [review]
Sort out locale-dependent times

Signed-off-by: Jens Georg <mail@jensge.org>
Comment 16 Jens Georg 2016-08-17 09:47:31 UTC
(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.
Comment 17 Piotr Drąg 2016-08-17 10:25:19 UTC
(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]. :)
Comment 18 Jens Georg 2016-08-21 10:15:31 UTC
Attachment 333476 [details] pushed as 45dfd34 - Sort out locale-dependent times