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.
(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.
(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.
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.
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).
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.
Adding Thunderbird localizers to get more and broader feedback.
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.
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 =).
(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...
If you're going to use Download manager as a reference, don't forget bug 419220 and 441167.
Created attachment 404690 [details] [diff] [review] 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!)
(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)
Patch v1 is working for me. It fixes the date formatting both, in multi message view/thread view and in gloda search results.
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 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.