User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022204 Minefield/3.0b4pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022204 Minefield/3.0b4pre Because the month and day names in the Download Manager are taken from the OS, they cannot be localized. Firefox localized for language A may well have the dates appear in language B if that's the OS language. (And Firefox localized in a language foreign to the OS can never have the dates in the right language.) Reproducible: Always Steps to Reproduce: 1.Tools > Download Manager 2. 3. Actual Results: Month and Day names in OS language. Expected Results: Month and Day names should be localized like the rest of Firefox.

See also bug 409832: right now on Mac Os X dates are always displayed in English (because of bug 368838).

I took the liberty to add the year for downloads more than one year old.

Unfortuenly, the string freeze for Gecko1.9/Firefox 3 was Friday. This won't make it in :(

(In reply to comment #3) > Unfortuenly, the string freeze for Gecko1.9/Firefox 3 was Friday. This won't > make it in :( > I didn't notice that. Then how about using the tooltip instead? It is still not localized, but at least the string is in one language.

Comment on attachment 308449 [details] [diff] [review] Make names of months and weekdays localizable clearing review request since we cannot take this for Firefox 3

Comment on attachment 308449 [details] [diff] [review] Make names of months and weekdays localizable I ran this patch against mozilla-central and it still seems to work. This should make it into Firefox 3.1. Re-requesting review.

Comment on attachment 308449 [details] [diff] [review] Make names of months and weekdays localizable I think it's better to fix bug 441167 than to patch each and every consumer.

WONTFIX per comment 8

Only part of this is bug 441167. Parts of the download manager uses nsIScriptableDateFormat, parts of the download manager don't. The parts using nsIScriptableDateFormat should be fixed in bug 441167. The parts not using nsIScriptableDateFormat should still be fixed here. Either by making it localizable directly (my patch) or by making it use nsIScriptableDateFormat. If you thing that the download manager should use nsIScriptableDateFormat, please reopen this bug, and I will try to make a patch.

The parts that don't use the JavaScript Date object, which should also be respecting the app locale. We don't do any date parsing ourselves, so the API's that we call should be patched if they are buggy.

The Date object is actually documented to work the way it does. The download manager just misuses it. But ok, I will file a bug on the Date object.

(In reply to comment #12) > The Date object is actually documented to work the way it does. The download > manager just misuses it. But ok, I will file a bug on the Date object. I was unaware of this. Then let's just get the DM to use nsIScriptableDateFormat everywhere please.

IIRC, the problem with Date is that it is localized, but it's using OS APIs, so the locale selected is the OS locale, and not the Firefox application locale.

(In reply to comment #13) > (In reply to comment #12) > > The Date object is actually documented to work the way it does. The download > > manager just misuses it. But ok, I will file a bug on the Date object. > I was unaware of this. Then let's just get the DM to use > nsIScriptableDateFormat everywhere please. > The options in nsIScriptableDateFormat are: Windows: dateFormatNone: dateFormatLong: Sunday, August 10, 2008 dateFormatShort: 8/10/2008 dateFormatYearMonth: 2008/08 dateFormatWeekday: Sun Linux: dateFormatNone: dateFormatLong: 2008-08-10 dateFormatShort: 2008-08-10 dateFormatYearMonth: 08/08 dateFormatWeekday: Sun Mac: ? So, the best I can come up with (if nsIScriptableDateFormat must be used) is this: if (date == today) use timeFormatNoSeconds else if (date < 1 week ago) use dateFormatWeekday else use dateFormatShort Would that be an acceptable way of displaying the dates?

Shawn, Jesper: any progress on this?

I guess this bug depends on the conclusion in bug 460988, which hasn't been reached yet. Should dates be localized according to the user's locale settings in the OS or according to the locale of Firefox. The former gives better platform consistency and better user control, while the latter gives a more coherent interface and gives more power to display dates in smarter ways (like what is done in the download manager).

I'd like to get our UE folks to comment here. While the discussion in the calendar bug 460988 has interesting arguments, it doesn't have UE folks on it. Nor did the toolkit bug 441167 to go from OS default locale to app locale.

Just for comparison.

>Should dates be localized according to the user's locale settings >in the OS or according to the locale of Firefox. The former gives better >platform consistency and better user control, while the latter gives a more >coherent interface and gives more power to display dates in smarter ways (like >what is done in the download manager). Is there any way for us to both localize, and also display dates in smarter ways (for languages where this makes sense)? Ideally all of Firefox should be in the same language. If this happens to be a language that the OS doesn't support, then users have even more of an affinity for Firefox.

If dates should follow the locale of Firefox and not the preferences in the OS, we could implement date formatting in a way that does not depend on the OS. That would allow us to add any special formatting we like. I think it would still be possible to retrieve wanted OS preferences like the 12/24-hour preference discussed in bug 460988 (at least for Windows, I don't know about others). I guess the ordering of date and month in numeric dates is the tricky bit. Does people expect the order to follow their preferences or the language of the application?

(In reply to comment #23) > I guess the ordering of date and month in numeric dates is the tricky bit. Does > people expect the order to follow their preferences or the language of the > application? Like I (and others) have argued in bug 460988, definitely the OS locale pref. What's the point of having an OS pref otherwise? People have it set to what they prefer, why would the application think it knows better?

So it sounds like the ideal solution is: -Firefox uses the correct language for the dates (in some cases this is a language that the OS does not support), so that all of Firefox is in the same language. -Firefox formats the dates in a smart way for all languages we support. This capability isn't just useful for the download manager, but will likely also be needed for future features. So we need new strings for time periods, like "Today," "Yesterday," etc in addition to all of the month names. -Firefox respects the OS setting for 12 vs. 24 hour clock, and month first vs. day first. However, Firefox applies this setting to the language it is using, instead of simply reprinting the dates from the OS. I have to admit I did a pretty quick read of this bug and bug 460988, so let me know if that doesn't make any sense, or I am missing some obvious drawback.

It seems we are not getting anywhere here. I therefore request review for this patch with the following comments: The patch fixes this bug by displaying the date in one locale instead of two, so that it is always readable. However, it uses the locale preferred by the user and not the Firefox locale. Current situation: Different parts of the date are localized into different languages making the date display grammatically incorrect and hard to read. This is what this bug and bug 452377 is about. Better situation: The date is localized into the user's preferred locale as set in the OS. This is what my patch does. Ideal situation: The date is localized into Firefox' locale. This is what the exact same patch would do once bug 441167 is fixed. I think it is safe to fix this bug now, as it gives a better situation, and no further work on this bug would be needed to get to the ideal situation.

Comment on attachment 368776 [details] [diff] [review] Patch: Use one source for date L10N instead of two This won't be able to make 1.9.1 now since we are past the string freeze (and I'm fairly confident that this wouldn't be considered a high enough value change to break the freeze). With that said, this would absolutely need ui-r since we are changing how we display downloads. We had the "Yesterday" bit for a very explicit reason. r=sdwilsh on the code changes, but this *cannot* land until it gets ui-r.

It sounds like this is an obvious win for situations where there are two localizations being displayed at the same time, and moves us closer to the ideal solution. Before I give a ui-r+ though, doesn't this have a detrimental effect when the localization of Firefox and the OS happens to be the same (like both in english)? The nice thing about terms like "Yesterday" is that often people can't remember what day it is.

(In reply to comment #28) The goal is to make the date l10n consistent on systems where the OS locale preference and the Firefox locale are not the same. This has a negative side effect also on systems where the OS locale preference and the Firefox locales are the same, because "Yesterday" is lost. Can we live with that? An alternative would be to keep "Yesterday" and only fix the dates which are displayed with date and month name. However this would only partly fix this bug. The date display for each download will be in one locale and would be readable, but the date display for two different downloads may not be in the same locale. This will however still add the year to the label. Do you think that would be better, Alex?

>An alternative would be to keep "Yesterday" and only fix the dates which are >displayed with date and month name. However this would only partly fix this >bug. The date display for each download will be in one locale and would be >readable, but the date display for two different downloads may not be in the >same locale. Since the majority of Firefox users are likely to be in a situation where their Firefox local and OS local are the same language (en-us, de, fr, es-es), I think it makes sense to go for the halfway approach and keep terms like "Yesterday." This really isn't ideal, but feels like the right balance given the distribution of users. Do you have a sense of what percentage of users are going to see a list of downloads with mixed languages being used? Having each line in a single language instead of the dates themselves being in two languages is at least an improvement. >This will however still add the year to the label. Sorry for not being completely up to speed on this, is the year added to the labels that are based on the OS local?

(In reply to comment #30) > Do you have a sense of what percentage of users are > going to see a list of downloads with mixed languages being used? I don't know. I haven't counted, but I guess between 1/3 and 1/2 of people where I live use English software, but almost everyone use the Danish locale. But I would guess that is not nearly as common in bigger languages than mine and maybe not as common in less international invironments. > Sorry for not being completely up to speed on this, is the year added to the > labels that are based on the OS local? This is what I see with OS locale DA and Firefox EN-US (See screenshot attached): Current label: marts 26 Gramatically correct label: 26. marts Label with date from OS: 26. marts 2009 The OS only provides two ways of displaying dates, and exactly the way it is displayed in the download manager is not one of them. The format can also vary a lot depending on OS and locale.

Comment on attachment 368776 [details] [diff] [review] Patch: Use one source for date L10N instead of two My understanding is that this patch has two attributes: positive: users who have different languages between Firefox and their OS won't have a download manager that is a chaotic mess negative: users who have the same language between Firefox and their OS will lose the descriptive names for times (like "yesterday") given that I believe the later user population is much larger than the former (en-us, de, fr, es-es), I'm going to wait to give this ui-r+ until bug 441167 is resolved as well. It's also entirely possible that we will have both bugs fixed in time for a future release, so this doesn't actually delay the improvement at this point.

How does this impact people who have en-us builds, but (eg.) en-au OS setting? How about if the OS setting is customised with a "dd/mmm/yy" short date format?

Closing this old bug, the new Downloads Panel is localized with new APIs.