Closed Bug 596905 Opened 9 years ago Closed 9 years ago

Remove release date in the new about window (about box)

Categories

(Firefox :: General, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- beta7+
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: hsivonen, Assigned: Margaret)

References

Details

(Whiteboard: [strings])

Attachments

(1 file, 5 obsolete files)

Steps to reproduce:
 1) Install a nightly for 2010-09-15
 2) Run it
 3) Choose About Minefield

Actual results:
It says "(released 09-15-2010)"

Expected results:
Expected an en-US version to use one of these date formats:
2010-09-15
September 15th 2010
15 Sep 2010
09/15/2010

The last one is the worst of these, since it may confuse non-U.S. users of en-US builds when the day <= 12.
Blocks: 579547
MM-DD-YYYY is extremely common in en-US, so why would this be unconventional? The code calls formatStringFromName(), which should pick the right format based on the locale.
(In reply to comment #1)
> The code calls formatStringFromName(), which should pick the right format based
> on the locale.

No it doesn't, it just passes in YYYY, MM, DD as numbers and lets localizers decide how to order them:

http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.properties#292

The various options we had for date formatting weren't producing the result we wanted, so that's what we ended up with. It's possible we can find a better solution, but since we're just about at string freeze, I'm not sure that will happen for Firefox 4.
(In reply to comment #1)
> MM-DD-YYYY is extremely common in en-US, so why would this be unconventional?

OK. It may the case that Finns don't expect to find hyphenated dates in that order in en-US UIs even if the format is actually common in the U.S. (I Finnish friend pointed out the date format to me and we both thought it was weird, so I reported a bug.)
(In reply to comment #1)
> MM-DD-YYYY is extremely common in en-US, so why would this be unconventional?

I'm American, born and raised, and I screw it up all the time.

Use either YYYY-MM-DD (ISO 8601) or the long locale-specific version, please.
Is it possible for us to use ISO 8601 (i.e. 2010-09-16) for dates on trunk builds, and then use DD/MM/YYYY and whatnot on release builds?
blocking2.0: --- → ?
status2.0: --- → ?
Anything is possible, but I don't think it should vary.
Blocks: 597012
This is ambiguous for any date where the day of the month is 12 or less. If you really want to have the year last then use a textual representation for the month, either long or short.
(In reply to comment #1)
> MM-DD-YYYY is extremely common in en-US, so why would this be unconventional?

A lot of people around the world, incuding me, use en-US builds for various reasons (and I'm confused all the day by US dates)

The slash notation MM/DD/YYYY at least reminds me to take care, but the ISO format YYYY-09-16 is preferable. MM-DD-YYYY is most confusing for a German.
Attached patch change to iso format (obsolete) — Splinter Review
Changes date string to ISO format (YEAR-MM-DD)
Comment on attachment 476942 [details] [diff] [review]
change to iso format

If it's being standardized, shouldn't the ability to localize the date format be removed entirely? In other words, change the string from:
"(released %1$S-%2$S-%3$S)" where %n$S are various bits of the date, to:
"(released %1$S)" where %1$S is replaced with the standardized format date.
(In reply to comment #10)
> Comment on attachment 476942 [details] [diff] [review]
> change to iso format
> 
> If it's being standardized, shouldn't the ability to localize the date format
> be removed entirely?

I don't think so. There are countries with reasonable, unambiguous date formats.
Whiteboard: [strings]
Attachment #476942 - Flags: review?(gavin.sharp)
Yes, this should block. We need to make sure that it's readable. I really would prefer a text-based date string, but that's been deemed "Really Hard" or something (can we really not get something back from the OS, here?) Anyway. ISO is what we should do in the absence of that, with the ability for localizers to localize away.
blocking2.0: ? → beta7+
(In reply to comment #11)
> There are countries with reasonable, unambiguous date formats.

This is an international project; not everyone will understand everyone else's formats. That's why there's a standard. ;)

(In reply to comment #12)
> ISO is what we should do in the absence of that,
> with the ability for localizers to localize away.

Again, why allow localization? The word "standards" didn't make it into the about dialog text itself, but it is a Mozilla top point.

YYYY-MM-DD (ISO 8601) is standardized and comprehensible by everyone. If we do allow localizers to play with it, then some builds will have dates that vary, and the whole reason a standard needed to be made about _dates_ is that people quote them and misread them and make mistakes. Can we please just go all the way on this dumb little date and axe the ability to localize the number ordering?
Assignee: nobody → margaret.leibovic
The point of ISO 8601 is not to ban all local date formats. We also don't hardcode stuff just to prevent localizers from making mistakes.
True, but in the place where all users are trained to look for if their application is up-to-date, I think we should ban local date formats to make sure there is no potential for misunderstanding. (see also comment 4) There is also no guarantee that the UI localization matches the what the user expects, and dates are a mess as a general concept.

As I already said, the full long localized version of "September 21th 2010" would also be fine. Even just Date.toLocaleString() with the time cut off, i.e. "Tue 21 Sep 2010", would be fine (I think that localizes consistent). It's just the abbreviated date version that has issues.

One last point: the localization route for this is generally supposed to be done on the OS level. It isn't really supposed done by a string.
Dave: yes, that returns the OS locale of the string, but that might not (and often does not) match the browser locale.

The question is: how strange is that? Previously we'd decided that it was a little wonky to have an otherwise en-US return a German date, and so went with numbers. I'm no longer sure that's a smart idea. I'm also no longer sure that this is worth the trouble. Dates are nice and people can reason about them, but perhaps we should just kill it.
Using ISO 8601 doesn't universally mean to "make sure there is no potential for misunderstanding", because localized Firefox builds don't provide the international context which ISO 8601 was made for. That format is actually not very common in countries with reasonable local date formats. In those countries the local date format is exactly what the user will expect and understand.

> One last point: the localization route for this is generally supposed to be
> done on the OS level. It isn't really supposed done by a string.

Not sure what this means. If you're suggesting we should have one build for all locales and pick the right locale based on the OS, then this doesn't belong in this bug.
Dao: I think he's saying that the existing JS libraries get the format from the OS selected locale and date formatter. But yes, as I mentioned, that can result in a case where you have a date string that doesn't match your browser locale.
(In reply to comment #16)
> Dave: yes, that returns the OS locale of the string, but that might not (and
> often does not) match the browser locale.

And there's also a chance that neither the browser locale nor the OS locale matches the user's locale. Localized dates are messy; standard dates are simple.

> Dates are nice and people can reason about them, but
> perhaps we should just kill it.

I like the released date, but I don't entirely disagree.

I would like standardized something here, one way or another.

(In reply to comment #17)
> Using ISO 8601 doesn't universally mean to "make sure there is no potential for
> misunderstanding", because localized Firefox builds don't provide the
> international context which ISO 8601 was made for. That format is actually not
> very common in countries with reasonable local date formats. In those countries
> the local date format is exactly what the user will expect and understand.

Granted, but if you don't understand ISO 8601, you can figure it out. The big 4 digit thing is obviously the year, then out of the two possible orderings for the date and month, descending order makes the most sense because we're already starting with the year. One way or another, though, it is going to be consistent for everyone.

> > One last point: the localization route for this is generally supposed to be
> > done on the OS level. It isn't really supposed done by a string.
> 
> Not sure what this means.

It means I can go into my OS setting and tell it to make everything in my OS use whatever date format I want. If it thinks I want MM/DD/YY and I don't, then I can tell it no, make everything I see YYYY-MM-DD and all applications comply. What I'm saying is that if you don't standardize this to YYYY-MM-DD, then localization format of the date is up to the OS setting via OS locale + user setting.
Let's just kill it. Not worth the fuss, and over in bug 596813 we'll be getting automatic update checking, so ... meh.

Margaret (or someone) if you could also file a follow up bug on building a library that we can use that will return a nicely formatted date string, that'd be grand. I bet web content would appreciate the hell out of it, as well, tbqh.
(In reply to comment #19)
> Granted, but if you don't understand ISO 8601, you can figure it out. The big 4
> digit thing is obviously the year, then out of the two possible orderings for
> the date and month, descending order makes the most sense because we're already
> starting with the year.

This might be true, but not requiring users to "figure it out" still seems better. Our localizers usually know what they're doing, so I'm not really concerned that they'll pick a format which their users wouldn't be familiar with.

Oops, mid-air. Ok then, let's kill it.
I'll file the follow-up bug on building a library.
Attachment #476942 - Attachment is obsolete: true
Attachment #477148 - Flags: review?(gavin.sharp)
Attachment #476942 - Flags: review?(gavin.sharp)
Comment on attachment 477148 [details] [diff] [review]
patch (kill released date string)

>         <description id="version">
>-#expand <label class="version-label" value="__MOZ_APP_VERSION__"/> <label class="version-label" id="released"/>
>+#expand <label class="version-label" value="__MOZ_APP_VERSION__"/>
>         </description>

<description id="version"><label class="version-label"/></description> looks redundant, can you trim it?
Attachment #477148 - Flags: review?(gavin.sharp) → review+
I suspect you want this:
#expand <description id="version" value="__MOZ_APP_VERSION__"/>
Attachment #477148 - Attachment is obsolete: true
Attachment #477153 - Flags: feedback?(dao)
Oops, I messed up the css. Fixed.
Attachment #477153 - Attachment is obsolete: true
Attachment #477154 - Flags: feedback?(dao)
Attachment #477153 - Flags: feedback?(dao)
Sorry, I keep messing up. Ne(In reply to comment #26)
> Created attachment 477154 [details] [diff] [review]
> patch v0.3 (updated to include xul cleanup)
> 
> Oops, I messed up the css. Fixed.

Oops, no I didn't. Sorry, it's early :)
Attachment #477153 - Attachment is obsolete: false
Attachment #477153 - Flags: feedback?(dao)
Attachment #477154 - Attachment is obsolete: true
Attachment #477154 - Flags: feedback?(dao)
Comment on attachment 477153 [details] [diff] [review]
patch (updated to include xul cleanup)

> #version {
>-  margin-top: 5px;
>-}
>-
>-#released {
>-  color: #666666;
>+  margin: 5px 0 0;
>+  padding: 0px;

Are you sure you want to remove the bottom margin?

padding: 0px looks like a no-op.
(In reply to comment #20)
> Let's just kill it. Not worth the fuss, and over in bug 596813 we'll be getting
> automatic update checking, so ... meh.

I concur with your "meh". :p

Yeah, if full auto checking gets implemented right under this line, then it's just clutter that might confuse things.
Attached patch patch v0.4 (more css tweaks) (obsolete) — Splinter Review
You're right, I didn't want to get rid of the bottom margin. This seems to be doing the right thing.
Attachment #477153 - Attachment is obsolete: true
Attachment #477160 - Flags: feedback?(dao)
Attachment #477153 - Flags: feedback?(dao)
Attached patch patch v0.5Splinter Review
I failed to make a new patch. Ugh.
Attachment #477160 - Attachment is obsolete: true
Attachment #477161 - Flags: feedback?(dao)
Attachment #477160 - Flags: feedback?(dao)
Attachment #477161 - Flags: feedback?(dao) → feedback+
status2.0: ? → ---
Filed bug for formatted date string library: Bug 598367.
http://hg.mozilla.org/mozilla-central/rev/f1912fe1996f
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Verified fixed Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100922 Firefox/4.0b7pre
Status: RESOLVED → VERIFIED
Summary: Unconventional date format in the new about window (about box) → Remove release date in the new about window (about box)
Target Milestone: --- → Firefox 4.0b7
You need to log in before you can comment on or make changes to this bug.