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 103964 - strftime self-check is probably incorrect
strftime self-check is probably incorrect
Status: RESOLVED DUPLICATE of bug 348191
Product: eel
Classification: Deprecated
Component: general
2.9.x
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-01-20 11:13 UTC by Göran Uddeborg
Modified: 2007-06-23 17:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Description Göran Uddeborg 2003-01-20 11:13:51 UTC 
While reviewing the translation of messages for eel, there were a couple of
messages of this kind:

> #. localizers: These strings are part of the strftime
> #. * self-check code and must be changed to match what strtfime
> #. * yields. The first one is "%m/%d/%y, %I:%M %p".
> #.
> #: eel/eel-glib-extensions.c:1128
> msgid "01/01/00, 01:00 AM"
> msgstr "01/01/00, 01:00 "

I took a quick look in the code, but didn't immediately realise what the
point is to do run-time checks of a function like this.

But more importantly, I doubt it could work correctly.  Assume I have
LC_MESSAGES set to sv_SE (so I get the above msgstr), but LC_TIME set to
en_US, (so that strftime will return what is in msgid above),  Then this
test would fail, wouldn't it?  Even assuming the functions involved have no
bugs.  Even if it isn't too common to have different values for different
LC_* domains, it is definitely not a bug.  (And I know about real-world
people who does.:-)
Comment 1 Kjartan Maraas 2005-02-09 23:32:51 UTC 
Removing the string keyword since this isn't really about changing strings. I
think we should just remove the nautilus --check stuff since it's never worked
anyway...
Comment 2 Martin Wehner 2007-06-23 17:12:13 UTC 

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