55614 - Text changes in Preferences dialog

Status: VERIFIED INVALID

(SeaMonkey :: Preferences, defect, P3)

Description

[Blake Ross]

OK, this is somewhat of a meta bug, but somewhat not. I'd like to use this to 
track all necessary text changes to any pane in the Preferences dialog.  You 
can either mark other pref wording change bugs as dups of this, or set them up 
as dependencies, but either way, I'd like everything that has to be done to be 
in the form of a comment to this bug report.  Obviously this won't get into the 
branch (i18n), but I'd like to do a massive pref wording update at once in the 
trunk.  When I finish, hopefully capitalization, punctuation, and phrases will 
be consistent across all the text in the dialog, all of the text will be 
helpful and make sense, and so forth.  Perhaps a pane-by-pane approach would be 
best, starting from the top and going down.

(sarah, matthew, vera, jennifer: this bug is sure to generate lots of 
notifications, so feel completely free to remove yourself from this bug!)

Comment 1

[verah (gone)]

Jennifer and I have a partial plan, but we need to wait until other priorities 
are out of the way before working on this. I plan to go through the UI text in 
all the preferences dialogs... *after* October 13th! (That's when I finish my 
final draft of the online help.)

Comment 2

[Matthew T (active 1999-2002)]

You could have just resummarized bug 51154 instead. Ah well ...

Corrected prefs UI text, part 1:
<http://bugzilla.mozilla.org/showattachment.cgi?attach_id=14022>

Comment 3

[Matthew T (active 1999-2002)]

Attachment: Corrected prefs UI text, part 2

Comment 4

[Matthew T (active 1999-2002)]

*** Bug 51154 has been marked as a duplicate of this bug. ***

Comment 5

[Matthew T (active 1999-2002)]

Ok, those two attachments make the prefs UI text about as good as it can get, 
without changes being made to the prefs chrome itself. And it's probably not 
worth making twiddly changes to the prefs chrome before BenG and I totally rework 
the prefs dialog in the near future (muahahaha).

Part 1 covers the Appearance, Navigator, and Advanced categories and 
subcategories, and was approved by Vera in bug 51154. Part 2 covers the Composer 
and Mail & Newsgroups categories and subcategories, and follows the same style as 
Part 1.

Goferit, Blake ...

Comment 6

[rudman]

Wait, please don't go for it, Blake. Any changes will affect our online Help,
which is based on the current UI. We worked with UE/UI folks to get the wording
and style the way it is. While your suggestions may be improvements, give us a
chance to review it. As Vera commented, that won't happen until after 10/13. So
your work is appreciated, Blake, but it needs to be evaluated for its affect on
both Netscape help and on localization.

I thought that these sort of changes had to be approved by Matt Fisher, no? He's
the component owner of prefs, at least according to
http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser.

Comment 7

[Matthew T (active 1999-2002)]

Ok, that comment just leaves me confused.

Firstly, the argument about affecting user help doesn't apply here. These changes 
will not affect Netscape user help, because this is a Bugzilla bug not a Bugscape 
bug, and no-one is suggesting that the changes should be checked into the 
Netscape branch. They will not affect Mozilla user help, because Mozilla doesn't 
have any user help yet. And when I do finish the Mozilla user help, if it doesn't 
match the UI then that is surely an issue to be dealt with in the user help, not 
in the UI.

Secondly, I'm not sure if you really meant it when you said that you have `worked 
with UE/UI folks to get the wording and style the way it is'. I would hope that 
the current wording is the way it is because UI people *haven't* worked on it 
yet, not because they have. My suggestions fix most of the worst mistakes, but 
some unfortunately cannot be fixed without changes to the chrome.

Thirdly, I don't understand why the `affect [sic] on localization' should be an 
issue. Some Mozilla localizations have not been updated since M14 or earlier, and 
other parts of the UI text have changed significantly since then. Why should the 
prefs be a special case?

Fourthly, no patch for these changes has been made yet. How do you expect them to 
be reviewed and approved, by whoever, without a patch?

And fifthly, my name's not Blake.

Comment 8

[rudman]

Matthew, your reference to Blake at the end of the message seemed to me like he
was going to make some changes (or that you were suggesting that he make
them---my misunderstanding).

As to your other points, when the Netscape branch is merged back with the trunk,
the changes would affect the Netscape UI, and consequently the help.

In any case, as Vera indicated, she could look at your suggestions after 10/13,
and I assume you're OK with having her input.

Comment 9

[Karl Ove Hufthammer]

Speaking as a Mozilla localizer, I have no problems with these changes being 
checked in in the Mozilla branch (the sooner, the better).

Comment 10

[jglick]

I believe the tech pubs group is just asking for the chance to review and 
comment on the proposed changes before they are implemented. I don't think 
that is too much to ask, since once Netscape merges back into the truck, these 
changes will affect the Netscape builds also.

Comment 11

[Blake Ross]

*** Bug 51149 has been marked as a duplicate of this bug. ***

Comment 12

[sairuh (rarely reading bugmail)]

i'm still not sure if we should use this to list all the prefs text issues,
rather than having seperate bugs --since multiple people touch and own the
various panels.

but, since a couple of bugs [51149, 51154] have already been dup'd in favor of
this one, here are some inconsistencies/issues i've found [in today's trunk
bits]:

1. in the Smart Browsing panel, notice that "location bar" is referred to in the
lowercase within the Internet Keywords section, but in uppercase in the Location
Bar Autocomplete section. which shall it be?

2. in the Themes panel, in the lower third where the Author is mentioned --there
should be a colon, ie, "Author:" --right now there isn't and it kinda looks odd
without it. imho.

Comment 13

[verah (gone)]

It looks like the "location bar/Location bar" issue has been fixed. I agree with
Sairuh regarding "Author" (it needs a colon). And I'm *finally* reviewing
Matthew's documents... sorry for the long delay. I'll comment soon.

Comment 14

[verah (gone)]

I've been looking at each of the proposed changes, and I think most of them make
the dialogs more clear. I'm commenting line-by-line and will attach my comments
soon.

However, there's one large issue that needs to be settled. Matthew has
intentionally used first person in most of the dialogs (for instance, changing
"When Mozilla start up, open..." to "When I start Mozilla, open..."). The
problem is that there is quite of bit of help text in these dialogs, which is,
naturally, in second person ("History is a list of pages YOU have previously
visited," "The Location Bar history remembers YOUR most recent...," etc.)

There's a long-standing rule for text in windows on the computer -- don't mix
first and second person in the same dialog. Generally, dialogs are mute about
person unless there's help text, which is always in second person. This rule is
followed because observations of people reading paragraphs that switch back and
forth between first and second person have shown that this switching reduces
reading comprehension.

I've checked OS elements on both Windows and Mac OS, and I've found that the "no
mixing of persons" rule is still being followed (though I did see a couple of
exceptions on Windows). OTOH, I know that this (and many other grammatical
conventions) are merrily broken all over most web pages.

So the question is, do we want to follow the rule? Should we mock something up
and test it with some real users?

I'm hoping that Robin and Steve (writer and former editor, respectively) will
add their comments. Also copying Kristi (another writer!) for her comments. 

Comment 15

[verah (gone)]

One more general comment: I notice that Matthew's proposed changes include
making the headings in the dialog lower case (except for the first letter of the
first word, of course) -- Others will be likely to disagree; as I recall there
was a discussion of this at among the Netscape contingent and (though as usual,
I advocated lower case) most prefered headings with init. caps.

Also, Matthew's headings sometimes, but not always, have a colon at the end. My
preference is to keep the headings consistent -- either always have colons, or
never have them.

So, I'm attaching my comments to Matthew's documents. 

Comment 16

[verah (gone)]

Attachment: Matthew's proposed UI text changes w/Vera's comments (1)

Comment 17

[verah (gone)]

Attachment: Matthew's proposed UI text changes w/Vera's comments (2)

Comment 18

[Matthew T (active 1999-2002)]

The mixing of first and second person is a problem caused by the inclusion of 
explanatory help text in the dialog at all in this version of the prefs UI -- 
such annoying text could be avoided entirely with the better arrangement of prefs 
and inclusion of additional strings before/after some controls, something which I 
did not have the luxury of doing since this was an attempt at an nsRTM fix.

And if you really think mixing first and second person is a problem, there's a 
certain `My Sidebar is yours' marketing slogan I'd like to discuss with you ...

I can't see any examples of the colon problem you mention. A colon should be used 
only where a string acts as the first part of a sentence and one or more items 
(e.g. checkboxes or list items) complete the sentence in various ways, and I 
think I kept to that rule throughout.

Comment 19

[Blake Ross]

[Mozilla will have a spellchecker soon]

Comment 20

[sairuh (rarely reading bugmail)]

another inconsistency: use of single vs double quotes. again, let me know if 
this should be filed seperately. not sure what it *should* be --either 
ways, it should be consistent throughout the prefs.

cc'ing some mailnews and composer folx since this crops up in their panels. i 
currently don't have access to a commercial build, but i *think* this issue 
might crop up in the Instant Messenger pref panels [double quotes used?] 
--suzanne, is there an internal bug for that?

* Composer panel, double quotes used in "pretty print"

* Message Display panel, single quotes used in ':-)'

* Message Composition panel, single quotes used in 'quoted printable'

* Send Format panel, single quotes used in 'Send email as plain text (no HTML)'

* Address Books panel, single quotes used in 'Collected Addresses'

* Debug panel, single quotes used in 'About'

Comment 21

[Matthew T (active 1999-2002)]

Mac OS convention is to use double curly quotes. Is there a Windows convention?

Comment 22

[Ben Bucksch (:BenB)]

I independantly filed a minor wording change bugs yesterday, e.g. bug 65480 and
one for Mailnews, IIRC. Search for filer <[e-mail]>, if you are
interested in possible overlaps.

Comment 23

[Ben Bucksch (:BenB)]

mpt wrote:
> I suggest changing `Enable features which help to interpret web
> pages' to `Advanced options'

I disagree. "Advanced options" is redundant (better remove the box altogether
then), while the current wording limits the scope and is accurate.

Comment 24

[Blake Ross]

Changed my mind again.  It's easy to checkin wording changes now (well, when the 
freeze is over) because we've got a generic rs=. Let's handle it on a case by 
case basis. Sorry.

Comment 25

[sairuh (rarely reading bugmail)]

mass verification of Invalid bugs: to find all bugspam pertaining to this,
set your search string to "MagaritaLuisaChascarilloAvoidsInvalidBugs".

if you think this particular bug is *still* an open issue, please make sure of
the following before reopening:

a. where relevant, do check that it's actually still a problem with ***recent
trunk builds*** on the all appropriate platform[s]

b. provide clear, compelling reasons why this bug should be considered a valid one.