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 336253 - locale's time/date representation
locale's time/date representation
Status: RESOLVED DUPLICATE of bug 205137
Product: evolution
Classification: Applications
Component: Mailer
2.6.x (obsolete)
Other All
: High major
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 344516 (view as bug list)
Depends on: 205137 256905 303420 323289 332792 343686 344516 348929 350825 506988
Blocks: 236276 343558 347240 378562 380843
 
 
Reported: 2006-03-27 21:38 UTC by Karsten Bräckelmann
Modified: 2013-09-10 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Karsten Bräckelmann 2006-03-27 21:38:05 UTC
The mail list should use %X (the locale's time representation), rather than hardcoding every value seperately. Just like e-d-s now finally uses %x.

This way we don't abuse translators any longer, to do this work manually, which already is available. Things like this are used all over the place and in a variety of for translation marked strings.

As an additional bonus, this will properly listen to LC_TIME. Yay. :)
Comment 1 Tor Lillqvist 2006-03-29 20:23:14 UTC
This would be the correct thing to do, yes, IMHO.
Comment 2 André Klapper 2006-03-29 20:26:38 UTC
targetting to 2.7.

yes, this is important if we want evolution to be properly translated.
Comment 3 André Klapper 2006-03-30 00:41:14 UTC
this could be a duplicate of bug 205137.
Comment 4 André Klapper 2006-04-06 12:00:49 UTC
i'm going to misuse this as a meta bug for date format issues.
Comment 5 André Klapper 2006-08-22 19:24:57 UTC
adding srini to CC - this affects the User Interface and bites lots of people.
Comment 6 Alex Rousskov 2006-10-19 15:19:23 UTC
I agree that there is a problem, but disagree that using "%x %X" is the ideal solution.

IMHO, it would be much better to allow the user to specify the exact format for the date column. For example, I would like to use "YY/MM/DD HH:MM" format even if my LOCALE defines "%x %X" differently. Once "%x %X" is supported, I can probably create a custom locale to redefine the Xs, but that seems like an overkill.

On a semantic level, %x probably determines how dates are rendered in a "stand alone" or "isolated" context. We are dealing with a different context here -- a column in a table. Space, alignment, consistency, and similar issues become imprortant here, and %x does not address those.

For extra points, several formats can be offered to control presentations of dates "long ago", "yesterday", and "today", without disabling the current smart algorithm.

The custom format(s) must be defined in LOCALE terms, of course. This fix should not introduce more translation problems.

Needless to say, that the _default_ format setting for "long ago" dates can be "%x" and for "today" it could be "%X".

Thank you.

P.S. I assume, based on a random search result, that
%x 	Represents the date format defined by the d_fmt statement. 
%X 	Represents the time format defined by the t_fmt statement.
http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/IBMp690/IBM/usr/share/man/info/en_US/a_doc_lib/files/aixfiles/LC_TIME.htm
Comment 7 Wouter Bolsterlee (uws) 2007-10-22 11:51:49 UTC
I think making all strings translatable, perhaps with context using the Q_ macro from Glib, would be the best thing to do. Extensive translator comments can help us come up with GOOD translations that fit the constraints imposed by the small space available.
Comment 8 André Klapper 2008-01-19 01:49:39 UTC
*** Bug 344516 has been marked as a duplicate of this bug. ***
Comment 9 David Richards 2009-01-26 17:30:21 UTC
Adding myself to the CC.  It seems that users generally do not like seeing "Fri" and "Friday" in the various UI screens.  They would much rather seen dates.
Comment 10 Milan Crha 2009-07-03 08:57:12 UTC
Using the more general bug report for this.

*** This bug has been marked as a duplicate of 205137 ***