Closed Bug 490649 Opened 14 years ago Closed 14 years ago

Ampersand usage should be consistent in clear recent history dialog [en-US]

Categories

(Firefox :: Private Browsing, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3.6a1

People

(Reporter: adw, Assigned: adw)

References

Details

(Keywords: user-doc-complete, verified1.9.1, Whiteboard: [non-l10n-impact string change])

Attachments

(1 file)

The recent clear recent history dialog refresh (bug 480169) uses the strings "Browsing and Download History" and "Form & Search History".  "Browsing and Download History" should use an ampersand.

Not sure if there's consensus on whether this needs an entity name change.  I'll attach two patches, one with, one without.
The consensus is that we don't rev the entity name, and just post to .l10n about that change.
Thanks, Axel.
Attachment #375045 - Flags: review?(l10n)
Status: NEW → ASSIGNED
Status: ASSIGNED → NEW
Whiteboard: [non-l10n-impact string change]
Status: NEW → ASSIGNED
Comment on attachment 375045 [details] [diff] [review]
patch, no entity name change

r=me, additional review request on beltzner to follow the process from .planning.
Attachment #375045 - Flags: review?(l10n)
Attachment #375045 - Flags: review?(beltzner)
Attachment #375045 - Flags: review+
Blocks: 480169
No longer depends on: 480169
Dao, you've been changing all the depends-on-480169 relationships in this bug and others to blocking 480169.  I'm new here, so I might be misunderstanding how we use depends vs. blocking, but how does this bug block 480169?  That's completely backwards.  480169 is over and done with, and this bug and others depend on its changes.
There are two kinds of followup relations. One is "once bug 480169 is fixed, we can move forward with bug 490649" and the other is "bug 490649 is a leftover from or an issue with the fix for bug 480169". In the former case, bug 480169 would block bug 490649, in the latter case it's vice versa.

One could say that bug 480169 isn't over and done -- it will be over and done when its dependency tree is cleared (https://bugzilla.mozilla.org/showdependencytree.cgi?id=480169&hide_resolved=1).
Yeah, bugzilla hasn't been ideal for this kind of tracking, but comment 5 reflects current best-practices. Hopefully bug 287334 will allow us to have real "regresses/regressed by" fields - I'm going to file a followup on doing that on b.m.o.
beltzner, do we want to take this? As said in comment 1, this is not a l10n-impact change to a file in en-US, and I'd be fine with taking it still.
Attachment #375045 - Flags: approval1.9.1?
Comment on attachment 375045 [details] [diff] [review]
patch, no entity name change

Adding this to the approval queue.  We certainly don't need to block on it, but I think it's a good, and tiny, polish fix to a feature that we expect to highlight in this release.
Comment on attachment 375045 [details] [diff] [review]
patch, no entity name change

a191=beltzner
Attachment #375045 - Flags: review?(beltzner)
Attachment #375045 - Flags: review+
Attachment #375045 - Flags: approval1.9.1?
Attachment #375045 - Flags: approval1.9.1+
Keywords: checkin-needed
Ehsan, this was never pushed to trunk.  Could we do that?
Keywords: checkin-needed
Sorry; I don't know why I assumed that it had already landed on trunk!

http://hg.mozilla.org/mozilla-central/rev/52c12a6e10b3
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
verified FIXED on builds:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090526 Minefield/3.6a1pre ID:20090526031623

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre ID:20090526031155
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.