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 552156 - Date/Time formats are not translatable
Date/Time formats are not translatable
Status: RESOLVED FIXED
Product: hamster-applet
Classification: Deprecated
Component: general
unspecified
Other Linux
: Urgent blocker
: ---
Assigned To: hamster-applet-maint
hamster-applet-maint
Depends on:
Blocks:
 
 
Reported: 2008-09-13 19:44 UTC by 28872d13
Modified: 2008-09-15 13:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch strftime usage (8.62 KB, patch)
2008-09-13 20:28 UTC, 28872d13
none Details | Review
Translatable date and interval strings (1.95 KB, patch)
2008-09-14 18:50 UTC, Claude Paroz
none Details | Review
Fix date/time i18n (6.95 KB, patch)
2008-09-15 11:57 UTC, 28872d13
none Details | Review
Fix indentation (7.28 KB, patch)
2008-09-15 12:03 UTC, 28872d13
none Details | Review

Description 28872d13 2008-09-13 19:44:41 UTC
Whenever strftime is used in hamster-applet, the argument given to it is not marked as translatable, thus not allowing translations to change the format into their native one.
Comment 1 28872d13 2008-09-13 20:28:16 UTC
Created attachment 118678 [details] [review]
Patch strftime usage

I'm not too sure if all of those should be translatable. Also, when displaying the time span in the stats dialog, and the start month matches the end month, something like 'September 13 - 15, 2008' is shown, but the string is constructed by two format strings: '%B %d' and '%d, %Y'. This is impossible to translate into a language like German, where this would have to be '13. - 15. September, 2008'
Comment 2 Toms Bauģis 2008-09-13 20:34:33 UTC
ah, crap, pitty that i read your comment just now. will have to think of something smarter, but for now, made available for localization all UI visible dates.
Comment 3 Toms Bauģis 2008-09-13 20:44:45 UTC
oh, and actually you could translate the one from before:

that would be "%d" for the start string and "%d. %B %Y" for the end one :)

all the cases are separated clearly, so a little of imagination and the situation is solvable. marking this as fixed.

i wonder if i should notify localization teams?!
Comment 4 28872d13 2008-09-13 20:53:11 UTC
(In reply to comment #3)
> that would be "%d" for the start string and "%d. %B %Y" for the end one :)
But the problem is that by translating '%B %d' to '%d', I lose information. Even if I move it to '%d, %Y', who guarantees that '%B %d' isn't used in the GUI elsewhere in a completely different context, so that I'd lose the %B completely? Furthermure, I have too little knowledge about other languages to elaborate on that, but that it works in German doesn't mean it works in all languages...
Comment 5 Toms Bauģis 2008-09-13 21:01:05 UTC
nah, you translate one instance in that specific file and line number.
if we apply same string somewhere else the string will be marked as fuzzy - isn't that so?


in total, you have 3 strings in control - the start and the end date, and how they both look together.
Comment 6 28872d13 2008-09-13 21:19:31 UTC
(In reply to comment #5)
> nah, you translate one instance in that specific file and line number.
> if we apply same string somewhere else the string will be marked as fuzzy -
> isn't that so?
No, you don't. Just look at the po-files - above every string, every occurence of that string is listed. And they're always translated equally. And I'm quite glad that that's the case because otherwise it would be even more confusing and error-leading. What you want is [1]. But even then, you still need to follow [2]. What's probably the nicest, but also the most awful from a programmer's point of view, is to allow something like '%d1. - %d2. %B1 %Y1' (allowing two or more dates to be used in one string). I personally would be ok with it just using a translation context, though. We should perhaps ask someone from the i18n team for insight.

[1] http://live.gnome.org/TranslationProject/DevGuidelines/Translation_contexts
[2] http://live.gnome.org/TranslationProject/DevGuidelines/Never_split_sentences
Comment 7 28872d13 2008-09-13 21:23:56 UTC
Concerning your commit comment, according to [1] it IS a string freeze break, but doesn't require approval, since the strings were not marked as translatable by accident. You better go notify gnome-i18n :-)

[1] http://live.gnome.org/TranslationProject/HandlingStringFreezes
Comment 8 Toms Bauģis 2008-09-13 22:08:45 UTC
reopening until we come up with something that is not so ambiguous 
Comment 9 Claude Paroz 2008-09-14 18:50:15 UTC
Created attachment 118701 [details] [review]
Translatable date and interval strings

I confirm this is currently hardly translatable for French, where the interval thing should be something like "1 - 2 janvier 2008", the month name being after the day numbers.
Here's a patch who should allow translators of most languages to translate it correctly. Something similar should be implemented for stats.py.

However, this needs gnome-i18n approval to be committed for the 2.24 release.
Comment 10 Claude Paroz 2008-09-14 19:09:24 UTC
And while browsing reports.py, it seems that table headers in the report are also untranslated:
    <th>Date</th>
            <th>Activity</th>
            <th>Category</th>
            <th>Start</th>
            <th>End</th>
            <th>Duration</th>
        </tr>
Comment 11 Toms Bauģis 2008-09-14 22:55:50 UTC
Thanks for the patch Claude, but this invites string break which we better postpone after 2.24 - the strings are translatable (although, admittedly, hardly, but still doable) 

And also, for date formatting, we should come up with something as generic as the original options for strftime.

As for headers in reports.py - fixed in HEAD, could you please notify i18n list? - you seem to be subscribed.

Thanks and sorry!
Comment 12 Wouter Bolsterlee (uws) 2008-09-15 10:25:33 UTC
(In reply to comment #3)
> oh, and actually you could translate the one from before:
> 
> that would be "%d" for the start string and "%d. %B %Y" for the end one :)
> 
> all the cases are separated clearly, so a little of imagination and the
> situation is solvable. marking this as fixed.
> 
> i wonder if i should notify localization teams?!
> 

"%d. %B %Y" is a pretty strange date format in English. It will result in something like "15. September 2008". The "." is German I think, it's not used at all in English (nor Dutch).
Comment 13 Wouter Bolsterlee (uws) 2008-09-15 10:29:22 UTC
This one is also strange:

> #. end date format for overview label for interval in same month
> #: ../hamster/reports.py:32 ../hamster/stats.py:276
> msgid "%d, %Y"

It will end up as e.g. "15, 2008" (without a month!), which makes no sense at all to me.
Comment 14 Patryk Zawadzki 2008-09-15 10:33:10 UTC
Wouter is right. English (and French and probably others) uses suffixes - 1st, 2nd, 3rd, 4th - for ordinal numbers where other languages use a dot.

A correct version would probably be either "15th of September" or "September, 15".
Comment 15 28872d13 2008-09-15 10:48:50 UTC
(In reply to comment #12)
> "%d. %B %Y" is a pretty strange date format in English. It will result in
> something like "15. September 2008". The "." is German I think, it's not used
> at all in English (nor Dutch).
That was an example to show that it is doable _in German_. '%d. %B %Y' is the translated German string, not the original English one.

Comment 16 28872d13 2008-09-15 10:49:59 UTC
(In reply to comment #13)
> This one is also strange:
> 
> > #. end date format for overview label for interval in same month
> > #: ../hamster/reports.py:32 ../hamster/stats.py:276
> > msgid "%d, %Y"
> 
> It will end up as e.g. "15, 2008" (without a month!), which makes no sense at
> all to me.
What about 'September, 13 - 15, 2008'?
Comment 17 Wouter Bolsterlee (uws) 2008-09-15 11:04:59 UTC
(In reply to comment #16)
> (In reply to comment #13)
> > This one is also strange:
> > > #. end date format for overview label for interval in same month
> > > #: ../hamster/reports.py:32 ../hamster/stats.py:276
> > > msgid "%d, %Y"
> > It will end up as e.g. "15, 2008" (without a month!), which makes no sense at
> > all to me.
> What about 'September, 13 - 15, 2008'?

Concatenating strings is ALWAYS WRONG from a i18n point of view. What if languages use different formats where e.g. the year is placed upfront?
Comment 18 Wouter Bolsterlee (uws) 2008-09-15 11:06:14 UTC
Confirming this bug and raising severity. Breaking string freezse is not to be taken lightly, so we'd better get this resolved ASAP.
Comment 19 Wouter Bolsterlee (uws) 2008-09-15 11:07:49 UTC
(In reply to comment #15)
> (In reply to comment #12)
> > "%d. %B %Y" is a pretty strange date format in English. It will result in
> > something like "15. September 2008". The "." is German I think, it's not used
> > at all in English (nor Dutch).
> That was an example to show that it is doable _in German_. '%d. %B %Y' is the
> translated German string, not the original English one.

Not true. The string "%B %d. %Y" appears at several places in the code, and is wrong in English.

#. start date format for overview label if start and end years don't match
#. end date format for overview label if start and end years don't match
#. date format for single day
#: ../hamster/reports.py:25 ../hamster/reports.py:26 ../hamster/reports.py:35
#: ../hamster/stats.py:264 ../hamster/stats.py:266 ../hamster/stats.py:280
msgid "%B %d. %Y"
Comment 20 André Klapper 2008-09-15 11:15:39 UTC
If this would not have been set to blocker, I would have done that too.

Tonight at 23:59 UTC is hardcode freeze. Can we please work this out very quickly?
Comment 21 28872d13 2008-09-15 11:18:37 UTC
(In reply to comment #17)
> Concatenating strings is ALWAYS WRONG from a i18n point of view. What if
> languages use different formats where e.g. the year is placed upfront?
Which is exactly what we're talking about this whole time. Please read the previous comments.
Comment 22 28872d13 2008-09-15 11:22:21 UTC
(In reply to comment #19)
> Not true. The string "%B %d. %Y" appears at several places in the code, and is
> wrong in English.
Yeah, but you seemed to be talking about '%d. %B %Y' (quote: »"%d. %B %Y" is a pretty strange date format in English«). Sorry if I got that wrong. Still, this issue needs to be resolved. What about changing it to '%B %d, %Y'?
Comment 23 Wouter Bolsterlee (uws) 2008-09-15 11:24:34 UTC
(In reply to comment #11)
> Thanks for the patch Claude, but this invites string break which we better
> postpone after 2.24 - the strings are translatable (although, admittedly,
> hardly, but still doable) 

I don't agree. We'd better resolve this in the CORRECT way, since it's hardly translatable right now for many languages. I assume that Claude approves the string freeze break introduced by his own patch. If so, here's my +2 approval.
Comment 24 Wouter Bolsterlee (uws) 2008-09-15 11:26:05 UTC
(In reply to comment #22)
> Still, this issue needs to be resolved. What about changing it to '%B %d, %Y'?

That makes sense. Does Claude's patch need changes for that?

Comment 25 28872d13 2008-09-15 11:57:45 UTC
Created attachment 118737 [details] [review]
Fix date/time i18n
Comment 26 28872d13 2008-09-15 12:03:57 UTC
Created attachment 118739 [details] [review]
Fix indentation

Sorry, blame gedit for the wrong indentation
Comment 27 Toms Bauģis 2008-09-15 12:07:56 UTC
Thanks Philipp, but i'll commit a solution that accepts all formatting strings, instead of just few fixed ones, in a second. 
Comment 28 Claude Paroz 2008-09-15 12:29:13 UTC
Toms, what do you mean by "all formatting strings". Could you provide examples or filenames, so as a more complete patch can be cooked?
Comment 29 Toms Bauģis 2008-09-15 12:39:58 UTC
Commited fix, this is how looks a string containing several dates, in PO template:


#. overview label if start and end years don't match
#. letter after prefixes (start_, end_) is the one of
#. standard python date formatting ones- you can use all of them
#: ../hamster/reports.py:29 ../hamster/stats.py:275
#, python-format
msgid ""
"Overview for %(start_B)s %(start_d)s. %(start_Y)s - %(end_B)s %(end_d)s. %"
"(end_Y)s"
msgstr ""



that is you have full control over date display, by using start_ and end_ variables - you can use all that are supported by python's strftime (http://docs.python.org/lib/module-time.html)

hope this is good enough.

this, however does break strings. 
Comment 30 Wouter Bolsterlee (uws) 2008-09-15 12:52:35 UTC
(In reply to comment #29)
> Commited fix,

I don't see a ChangeLog update. Commit message is this:

r510 | tbaugis | 2008-09-15 14:35:54 +0200 (Mon, 15 Sep 2008) | 2 lines
ok, full fix to avoid amiguity in strings involving dates.
fixes bug 552156
Comment 31 Wouter Bolsterlee (uws) 2008-09-15 12:55:47 UTC
Anyway, the strings are still not fixed. The two strings both have two "."
characters. All of those should be removed, as I already pointed out in comment
12. Please fix.

#. overview label if start and end years don't match
#. letter after prefixes (start_, end_) is the one of
#. standard python date formatting ones- you can use all of them
#: ../hamster/reports.py:29 ../hamster/stats.py:275
#, python-format
msgid ""
"Overview for %(start_B)s %(start_d)s. %(start_Y)s - %(end_B)s %(end_d)s. %"
"(end_Y)s"

#. overview label if start and end month do not match
#. letter after prefixes (start_, end_) is the one of
#. standard python date formatting ones- you can use all of them
#: ../hamster/reports.py:31 ../hamster/stats.py:280
#, python-format
msgid "Overview for %(start_B)s %(start_d)s. - %(end_B)s %(end_d)s. %(end_Y)s"
Comment 32 Wouter Bolsterlee (uws) 2008-09-15 12:56:20 UTC
Hmmm. Even more. Same goes for these ones:

#. overview label for interval in same month
#. letter after prefixes (start_, end_) is the one of
#. standard python date formatting ones- you can use all of them
#: ../hamster/reports.py:33 ../hamster/stats.py:285
#, python-format
msgid "Overview for %(start_B)s %(start_d)s - %(end_d)s. %(end_Y)s"

#. overview label for single day
#. letter after prefixes (start_, end_) is the one of
#. standard python date formatting ones- you can use all of them
#: ../hamster/reports.py:36 ../hamster/stats.py:291
#, python-format
msgid "Overview for %(start_B)s %(start_d)s. %(start_Y)s"

Comment 33 Wouter Bolsterlee (uws) 2008-09-15 12:57:58 UTC
Can you add more translator comments to this string as well? It's not obvious what it is used for. Is it for display? If so, why the strange syntax with . characters in between? d-m-Y is not a conventional date format in English either (though it is in e.g. Dutch), so this is most likely to cause confusion.

#. date format in HTML report
#: ../hamster/reports.py:111
#, python-format
msgid "%(report_d)s.%(report_m)s.%(report_Y)s"
Comment 34 Wouter Bolsterlee (uws) 2008-09-15 13:03:19 UTC
What's up with al those . characters? Remove it here as well, please :)


#. date format in overview window fact listing
#. prefix is "o_",letter after prefix is regular python format. you can use all of them
#: ../hamster/stats.py:172
#, python-format
msgid "%(o_A)s, %(o_b)s %(o_d)s."

Comment 35 Wouter Bolsterlee (uws) 2008-09-15 13:08:53 UTC
And another one that should be removed:

#. date format in month chart in overview window (click on "month" to see it)
#. prefix is "m_", letter after prefix is regular python format. you can use all of them
#: ../hamster/stats.py:223
#, python-format
msgid "%(m_d)s., %(m_b)s"

Comment 36 Toms Bauģis 2008-09-15 13:11:14 UTC
Wouter - how about you come up with a patch? - i'm getting really confused in your comments

Not using standard formats could be because of my origin and general ignorance towards date formats.
Comment 37 Wouter Bolsterlee (uws) 2008-09-15 13:13:51 UTC
(In reply to comment #36)
> Wouter - how about you come up with a patch? - i'm getting really confused in
> your comments

Mind if I fix the date formats in SVN to be correct? That will adress all my issues for now, except for comment 33. Can you explain what this string is used for in more detail?

> Not using standard formats could be because of my origin and general ignorance
> towards date formats.

No worries, your friendly attitude is much appreciated.

Comment 38 Toms Bauģis 2008-09-15 13:18:26 UTC
Fixing stuff in SVN should be fine, thanks!

regarding 33: changed
#. date format in HTML report 

to 
# fact date column in HTML report



should be good enough now
Comment 39 Wouter Bolsterlee (uws) 2008-09-15 13:33:25 UTC
2008-09-15  Wouter Bolsterlee  <wbolster@svn.gnome.org>

	* hamster/reports.py:
	* hamster/stats.py:

	Use American English date formats. Fixes the issues
	in comments 31, 32, 33, 34, and 35 of bug #552156.
Comment 40 Wouter Bolsterlee (uws) 2008-09-15 13:34:46 UTC
Ok, I think the date formats are ok right now. Philipp, Claude: could you please acknowledge or complain about my latest changes?

Toms, thanks for your quick response time.
Comment 41 28872d13 2008-09-15 13:45:18 UTC
(In reply to comment #40)
> Ok, I think the date formats are ok right now. Philipp, Claude: could you
> please acknowledge or complain about my latest changes?
I'm perfectly fine with them and thus closing this. Claude, feel free to reopen if you still spot something.

> Toms, thanks for your quick response time.
Kudos to Toms! :-)

Comment 42 Toms Bauģis 2008-09-15 13:51:57 UTC
thank you, guys!