519958 - makeFriendlyDateAgo improperly l10n'ified

Status: RESOLVED FIXED

(Thunderbird :: Search, defect)

Description

[Alex Ihrig [:Thunderbird_Mail_DE]]

The search results page displays the english date format in summaries of the results. l10n-builds should display the correct localized date format. Fixing this could result in a late-l10n checkin.

Comment 1

[Mark Banner (:standard8)]

(In reply to comment #0)
> The search results page displays the english date format in summaries of the
> results. l10n-builds should display the correct localized date format. Fixing
> this could result in a late-l10n checkin.

Can you attach a screenshot of this issue? How does it compare to the message list view?

Last I heard the date values in the timeline (month etc) were based on the system locale settings.

I'm therefore guessing the date format in the search results would also be displayed in the system locale settings.

Comment 2

[Alex Ihrig [:Thunderbird_Mail_DE]]

(In reply to comment #1)
> Last I heard the date values in the timeline (month etc) were based on the
> system locale settings.

In thread pane, the date column is using the system locale settings (in Germany: dd.mm.yyyy hh:mm). That's right.

> I'm therefore guessing the date format in the search results would also be
> displayed in the system locale settings.

Both, the date column in thread pane and the search results page are using the localized date strings (including the time line). But the date formatting on the results page in the message summaries isn't correct for l10n-builds.

Comment 3

[Alex Ihrig [:Thunderbird_Mail_DE]]

Attachment: Screenshot with en-US date formatting in German 3.0pre build

Comment 4

[David Ascher (:davida)]

Ah, thanks for the screenshot.  I suspect the same problem occurs in the thread summary view and "multi-message" summary view.

The problem is that the function makeFriendlyDateAgo (http://mxr.mozilla.org/comm-central/source/mailnews/base/util/templateUtils.js#61) is likely not quite doing the right thing.

Note that the intent of that display is not to be a full date display, but a shortened version -- it should say things like "yesterday" (or the l10n version ;-) for messages from yesterday.  Given that understanding, is the problem the order of the two words?  Do you need it to say "4 Juli" instead of "Juli 4"?  That kind of l10n problem makes sense to me, and would require that we make strings to replace the fixed "#1 #2" and "#1 #2 #3" in that function.

Comment 5

[Simon Paquet [:sipaq]]

In Germany you would generally say "4. Juli" (Fourth of July) but that would be manageable with two strings (one for the day and the one the month).

Comment 6

[Simon Paquet [:sipaq]]

I'm removing the "late-l10n" keyword for now unless it has been decided by the release driver, whether this really blocks the release.

IMO it should, but I'm not making the decisions here.

Comment 7

[Simon Paquet [:sipaq]]

Adding Thunderbird localizers to get more and broader feedback.

Comment 8

[Rimas Kudelis [use needinfo to ping]]

My suggestion:
Since we're in the string freeze, and this problem is a little more global than just Thunderbird, here's what we could do:

- for now, reuse entities from toolkit/chrome/mozapps/downloads/downloads.properties, namely, 'yesterday' and 'monthDate'. These are the same "short" type of strings, just used in the Download Manager (press Ctrl+J or Ctrl+Y, and you'll see them),

- in future versions, resolve this problem globally (in Toolkit). 

Part of this problem is already partly adressed - we have toolkit/chrome/global/dateFormat.properties. Also, AFAIR, Calendar has really good date forming capabilities, and dateFormat.properties is derived directly from Calendar. I can't remember toolkit's dateFormat.properties being actually used anywhere though (please correct me if I'm wrong).

I think what we need is to actually improve have this improved in toolkit side, since there are really lots of different use cases for different date formats, and it's not mail, calendar or browser specific.

Comment 9

[David Ascher (:davida)]

I agree w/ the strategy of making toolkit-wide date localization functions & strings.  

Unless I'm missing something about the two properties files you mention, I don't think that we can solve the sort order (day/month vs. month/day) using those strings, though.  I wonder if there's a way to detect what the order of month/day/year should be from the locale-aware date formatting functions built into JS...


As an aside, I think that just order isn't enough if we want to be fully native -- in French for example I'd think we'd want "4 Juillet" (same order as german) but "1er Mars", not "1 Mars", implying more code & templates, not just strings.  (First cut: we'd need to define some pluralization-like system indicating whether to use the ordinal number or the cardinal number; and then strings for ordinal numbers).  For example, I'm not a localizer, but I think that in French, the ordinal would only be used for 1.  (this is obviously not for TB3 =).

Comment 10

[Rimas Kudelis [use needinfo to ping]]

(In reply to comment #9)
> Unless I'm missing something about the two properties files you mention, I
> don't think that we can solve the sort order (day/month vs. month/day) using
> those strings, though.  I wonder if there's a way to detect what the order of
> month/day/year should be from the locale-aware date formatting functions built
> into JS...

You missed this:
http://hg.mozilla.org/releases/mozilla-1.9.1/file/866358b0b6fc/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties#l97

As I said, it's in Download Manager, but maybe it would work, at least until Tb 3.next?

> As an aside, I think that just order isn't enough if we want to be fully native
> -- in French for example I'd think we'd want "4 Juillet" (same order as german)
> but "1er Mars", not "1 Mars", implying more code & templates, not just strings.
>  (First cut: we'd need to define some pluralization-like system indicating
> whether to use the ordinal number or the cardinal number; and then strings for
> ordinal numbers).  For example, I'm not a localizer, but I think that in
> French, the ordinal would only be used for 1.  (this is obviously not for TB3
> =).

There's a lot of stuff we need. My example is with grammatical cases: in Lithuanian, the case of the month name depends on whether it's used with a day after or not, so while October alone is Spalis, 'October 1' should say 'spalio 1 d.'. This is where Download Manager lacks ATM.

What I'm looking forward is for a way to define quite a big set of available date formats in toolkit, and see them reused in all apps. For example, this could include:
* very close dates like "today", "yesterday", "tomorrow", "the day before yesterday", "the day after tomorrow",
* close dates like "October 1",
* generic dates, long format, as in "October 1, 2009",
* generic dates, short format, as in "10/01/2009",
* (probably) same formats, but with time and/or weekday added,
* standalone weekdays,
* standalone month names,
* the presentation of standalone years ('2009 m.' in Lithuanian),
* probably something else...

Important thing is that month names and/or weekdays should be translatable separately for each of those cases, or at least some differentiation should be agreed upon. E.g., for Lithuanian, standalone month names should be translated differently from those followed by a day, but other languages might have different requirements.

All this date formatting functionality should be available somewhere in Toolkit, well documented and used in all our apps. That would be just so much better than what we have now...

Comment 11

[Francesco Lodolo [:flod]]

If you're going to use Download manager as a reference, don't forget bug 419220 and 441167.

Comment 12

[David Ascher (:davida)]

Attachment: patch v1

Ok, as suggested I'm using "monthDate" from the download manager properties file for the month + day case.  I'm using toLocaleDateString() for the day + month + year case, even though it makes the english version a little less readable (IMO), but because it yields us an 1l0n solution.

Asking for ui-review because of the latter bit.

(l10n'ers, please feel free to comment as well!)

Comment 13

[David Ascher (:davida)]

(I'm putting my head in the sand about the two download manager bugs mentioned in comment #11, because that feels like a much bigger fish to fry, involving toolkit, which is fairly frozen for 1.9.1 -- at this point, I just want to avoid making l10n horrible in most locales.  I don't yet understand the statistics on the users who want a locale that's different than their OS configuration, but I'm going to assume that faaborg is right and that it's smaller than the set of users affected by this bug as it stands)

Comment 14

[Alex Ihrig [:Thunderbird_Mail_DE]]

Patch v1 is working for me. It fixes the date formatting both, in multi message view/thread view and in gloda search results.

Comment 15

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 404690 [details] [diff] [review]
patch v1

it's worth having it l10n-able even if we get the slightly odd english look.

Comment 16

[Mark Banner (:standard8)]

Comment on attachment 404690 [details] [diff] [review]
patch v1

r=Standard8. Please file a follow-up bug blocking 3.1 that resolves what to do with the string dependency on toolkit/tidying up the date display generally.

Comment 17

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/07c07166b28e