User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b3pre) Gecko/2008020202 SeaMonkey/2.0a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9b3pre) Gecko/2008020202 SeaMonkey/2.0a1pre A patch from revision 1.2 to 1.3 for mail_help.xhtml (bug 85925) changed the description of the forwarding mode preference from "inline (in the body of the message), or as an attachment (by default)" to "inline (in the body of the message; this is the default), or as an attachment". This was obviously done while working on early Mozilla Suite and Netscape versions in parallel. Indeed, Netscape 6.x switched the default forward mode from "attachment" to "inline". Mozilla didn't follow though, and a respective RFE (bug 230448) to make that change thus far was unsuccessful for SeaMonkey. Thus, the current wording of the help text is misleading for SeaMonkey at this point. There is also an inconsistent formatting, putting "inline" in emphasis (italics) whereas "as attachment" is not. Reproducible: Always Steps to Reproduce: In SeaMonkey Help, go to Using Mail > Sending Messages > Forwarding a Message.
Created attachment 301179 [details] [diff] [review] Proposed corrections This patch removes the "this is the default" phrase completely, as it is only stated in this single occurrence anyway. Thus, the phrase is neutral if the default forwarding mode for SeaMonkey should be changed in the future or is overridden in a customized distribution. Also, the emphasis for "inline" has been removed. I'll edit those back in if requested, but I couldn't find any purpose why those were emphasized in the first place.
Assignee: neil → rsx11m.pub
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → seamonkey2.0alpha
Comment on attachment 301179 [details] [diff] [review] Proposed corrections Thanks for catching this :-) I think your proposal makes sense - the default setting should be easy to notice anyway. It's strange that only "inline" is emphatized - I would have expected both choices to be emphatized. Anyway, those <em> can surely go away. However, I think we can make it a bit more clear for users by using the <em> in one place: <p>When you forward a message, you can specify how to place new text relative - to the original text: <em>inline</em> (in the body of the message; this is - the default), or as an attachment.</p> + to the original text: inline (in the body of the message), or as an + attachment.</p> In the above case I think it could be useful to make both emphatized. That is, can you please attach a new patch with <em>attachment</em> in the above section?
erm, emphatized --> emphasized
Created attachment 301287 [details] [diff] [review] Proposed corrections (v2) First occurrence in the main entry emphasized per comment #2. I came across this recently while working on the related bugs... BTW: Does this patch need any superreview?
Comment on attachment 301287 [details] [diff] [review] Proposed corrections (v2) > BTW: Does this patch need any superreview? No, it doesn't. I'm going to land this for you asap. Thanks again for the patch! Btw: - the attachment displayed <em>inline</em> (in the body of the message). For + the attachment displayed inline (in the body of the message). For other file types, Mail & Newsgroups lets you open the attachment using This is a nit, but note that we generally want this to be re-indented. That is, in this case "other file" could have been moved up one line. No need to submit another patch now though, I'm going to fix this (and the other) on check-in.
Attachment #301287 - Flags: review?(stefanh) → review+
Landed with some re-indentation: Checking in suite/locales/en-US/chrome/common/help/mail_help.xhtml; /cvsroot/mozilla/suite/locales/en-US/chrome/common/help/mail_help.xhtml,v <-- mail_help.xhtml new revision: 1.86; previous revision: 1.85 done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Great, thanks for your quick review and for checking in the patch.
I'm afraid that this is not quite done yet. I was focusing on the statement for the default and the formatting, thus it didn't come to my attention that the introductory sentence in the main entry appears to be reversed: "When you forward a message, you can specify how to place new text relative to the original text" is upside-down, since the setting actually specifies how the original (forwarded) message is handled. Also, it should not be restricted to text, e.g., images as part of multipart/related HTML messages are inlined as well. Something like "you can specify how its contents are included in the new message" should be more accurate. Sorry for missing this in the first round. I'm working on a patch relative to revision 1.86 and can just attach it to this bug here to reopen it, unless you prefer to have this filed as a separate bug.
Oops, you're right. Thanks for catching that. Yeah, that looks more like a variant of explaining "replying to a message". Lets have another round here, feel free to reopen when you're ready.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: Remove wrong statement and inconsistent formatting for forwarding mode from mail_help.xhtml → Wrong statements and inconsistent formatting for forwarding mode in mail_help.xhtml
Created attachment 301607 [details] [diff] [review] Follow-up for introductory sentence Wording as proposed in comment #8. The other occurrences should be ok.
Attachment #301607 - Flags: review?(stefanh)
Comment on attachment 301607 [details] [diff] [review] Follow-up for introductory sentence Thanks. I'll land this for you tomorrow - (UTC+1 here).
Attachment #301607 - Flags: review?(stefanh) → review+
UTC+1? That's indeed a very good reason... :-) I've noticed that some localization teams have already applied yesterday's changes, thus unfortunately double work for them as well.
Don't blame yourself, as a reviewer I should have noticed. Besides, it's a really small change and we're in pre-alpha. Checking in suite/locales/en-US/chrome/common/help/mail_help.xhtml; /cvsroot/mozilla/suite/locales/en-US/chrome/common/help/mail_help.xhtml,v <-- mail_help.xhtml new revision: 1.87; previous revision: 1.86 done Feel free to open another bug if you find more oddities ;-)
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.