354045 - Improve 'Browse...' string for Options-Downloads section in FF 2.0 Help

Status: VERIFIED FIXED

(Firefox Graveyard :: Help Documentation, defect)

Description

[Ton [:Tonnes]]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1) Gecko/20060923 BonEcho/2.0
Build Identifier: 

Makes 'Browse...' appear in italic and changes it to 'Choose...' for mac.
This also reverts 2 occurrences of &pref.singular; in the Startup section that were erroneously introduced by bug 341899.

Reproducible: Always

Comment 1

[Ton [:Tonnes]]

Attachment: The fix

Comment 2

[Jeff Walden (gone starting June 8)]

Comment on attachment 239905 [details] [diff] [review]
The fix

>Index: browser/locales/en-US/chrome/help/prefs.xhtml

>     the textbox immediately below), which corresponds to the <em>Show my home
>-    page</em> &pref.singular;.  Alternately, you can choose to display a blank page on
>+    page</em> option.  Alternately, you can choose to display a blank page on
>     startup (perhaps to eliminate the time required to load that page from the
>-    Internet) by selecting the <em>Show a blank page</em> &pref.singular;.</p>
>+    Internet) by selecting the <em>Show a blank page</em> option.</p>

Aside from this already being this way on trunk, why is this change necessary?  There are some cases where using "option" instead of the platform-specific term is correct, but I don't believe this is one.  Please convince me (or anyone else, for that matter).  :-)

The second change looks good to me, although I'd make one <em/> enclose the two <span/>s instead of having each enclose its own <em/>.  Could you post a patch doing just that?  r=me on that patch (since your approval request is almost certainly going to be denied without an r+)

Comment 3

[Jeff Walden (gone starting June 8)]

(In reply to comment #2)
> Please convince me (or anyone else, for that matter).  :-)

The "or anyone else" corresponds to the implied "you" in this sentence, since it's not at all clear when I actually reread it.  ;-)

Comment 4

[Ton [:Tonnes]]

(In reply to comment #2)
> Aside from this already being this way on trunk, why is this change necessary? 
> There are some cases where using "option" instead of the platform-specific term
> is correct, but I don't believe this is one.  Please convince me (or anyone
> else, for that matter).  :-)

Until recently, all 3 paragraphs referred to 3 'options' (for the start page preference) that can be chosen from when starting the application. While reporting my last nits to sheppy, one of which being the pref.singular change in accessibility.xhtml, I/we suddenly felt there could me more occurrences and started to hunt them down. As became clear, this hunt was an overactive one, resulting in a few occurrences being reverted, 1 of these in prefs.xhtml included, but these 2 were left in.

I've contacted sheppy about this and he did not really felt the need to change this and post a new patch for it (attachment 239044 [details] [diff] [review] had been checked in at that time) because it would not really make a difference. Though this would be true for Windows, it would not for other platforms. Then it turned out preferences or options would not make a real difference in its meaning in this case for en-US, but that could be different for other locales, as it would for ours. After all he agreed to take this in in a future change if the tree was open again.

In short: as my other edit occurs in the same file, I just took it along. And after all, technically there's no point in calling 2 of those 3 cases a preference, which I believe refers to a choice, not a setting, or we might call all (these 3 and other) options preferences. ;)

Do you still need separate patches? :)

Comment 5

[Ton [:Tonnes]]

Attachment: Browse string only

As requested.

Comment 6

[Jeff Walden (gone starting June 8)]

Comment on attachment 239927 [details] [diff] [review]
Browse string only

I clearly should have been looking at the source code more when I wrote this to notice this platform-specific problem.

Comment 7

[Jeff Walden (gone starting June 8)]

(In reply to comment #4)
> Then it turned out preferences or options would not make a real difference in
> its meaning in this case for en-US, but that could be different for other
> locales, as it would for ours.

Maybe I'm just naive, but I've been expecting localizers to use their best judgement and adjust wording and other such things as necessary for their specific languages and regions.  This would be one such place where I'd expect localizers to deviate from en-US as they deem necessary.

> And after all, technically there's no point in calling 2 of those 3 cases a
> preference, which I believe refers to a choice, not a setting, or we might
> call all (these 3 and other) options preferences. ;)

AH!

I missed that this was the case; yes, consistency is a worthwhile goal, and the third case seems to work better with "option" than possibly with "preference" (either that or I've just been trying to come up with reasons to justify the patch for too long ;-) ).  Consider this an r=me on a patch consisting of this change and the Choose.. change as implemented in the second patch.  :-)

Comment 8

[Ton [:Tonnes]]

Attachment: Complete fix

Comment 9

[Mike Schroepfer]

Comment on attachment 239980 [details] [diff] [review]
Complete fix

Approved Help Change for RC2.

Comment 10

[Jeff Walden (gone starting June 8)]

Fixed on branch, leaving open until I determine what needs to also go in on trunk and commit said changes...

Comment 11

[Jeff Walden (gone starting June 8)]

Trunk changes (the second hunk of the patch) committed.  Thanks for the filing the bug, writing the patch, and putting up with my questions, Ton!

Comment 12

[Jackie Liu]

"Browse..." is italicized in "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061003 BonEcho/2.0".  

=> VERIFIED FIXED

Comment 13

[Tracy Walker [:tracy]]

verified with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1) Gecko/20060928 BonEcho/2.0