(Quoting myself from bug 895751 comment #9) > BTW: There are similar labels in Mail & Newsgroups (Character Encoding > prefpane and the Folder Properties dialog) but they should be unambiguous > given the extended labels there or other options in the vicinity making it > clear what the term "Default Encoding" relates to. I've slightly changed my mind on this. The "legacy content" note may be useful to have as an explanation for the Default Character Encoding in the Mail & News preferences in the Message Display group as well to describe what it will do, given that there are other "(...)" items for explanation in this prefpane's labels. Also, the Help content for this prefpane needs updating for a couple of other changes as well.
Other changes made to that pane before bug 895751 but yet have to be considered in its Help content: - Bug 408335 removed "Apply default character encoding to all incoming messages" - Bug 410333 reworded "Always use this default character encoding in replies"
This patch makes more changes to the Help content than to the actual prefpane, but anyway. * The note added to the "Message Display" group is almost the same as the one for bug 895751, with a few differences: 1. placed below the menulist and in "()" parentheses to match similar comments later on for other options; 2. replaced "fails to" with a de-emphasized "does not" given that the RFC204x do not /require/ a charset parameter (defaulting to ASCII, which shouldn't be a problem anyway as all charsets should be a superset of the 7-bit ASCII page); 3. I didn't change the "Default Character Encoding" label to "Fallback" as the term "Default" is used later for the "Composing Messages" section, and it would fits the rationale in item #2 above better. * In the Help content, I've modified the text a bit; replaced "recommended ... likely" with a simple "used for", then later made it "sometimes" to better convey that it's only sometimes used for content which doesn't have a charset specified; also, I've added mailing lists as example where I sometimes see those missing. * The description for forcing the default charset has been removed. * The "Tip" was wrong, View > Character Encoding applies only when you view a message, it cannot be used when looking at a folder to change its default (that's actually in Folder Properties, but that would be out of scope here); I've rephrased that to match what the menu actually does. * Mentioned that QP encoding is only needed when talking to a 7-bit server. * Split off the reply-specific option into its own bullet item and updated the label. BTW: Asking for Ian's review only as the patch in Bug 895751 didn't seem to require any ui-review either.
Attachment #786622 - Flags: review?(iann_bugzilla)
Comment on attachment 786622 [details] [diff] [review] Proposed patch >+++ b/suite/locales/en-US/chrome/common/help/mailnews_preferences.xhtml >@@ -666,42 +666,41 @@ > <li>Under the Mail & Newsgroups category, click Character Encoding. (If > no subcategories are visible, double-click Mail & Newsgroups to expand > the list.)</li> > </ol> > > <ul> > <li><strong>Default Character Encoding</strong>: Click this drop-down list to > select the character encoding you want Mail & Newsgroups to use as the >+ default for incoming mail and newsgroup messages. This encoding is used for >+ messages you've received in which the character encoding (MIME charset) >+ is not specified, sometimes seen when reading messages from mailing lists >+ or in international newsgroups. See below about changing from Default to Fallback. As legacy content is now mentioned in the pref pane, should it also be mentioned in the help? >+++ b/suite/locales/en-US/chrome/mailnews/pref/pref-character_encoding.dtd > <!ENTITY viewDefaultCharset.label "Default Character Encoding:"> I think it is worth matching what we have for the Browser here, so can we change this to Fallback Character Encoding? > <!ENTITY viewDefaultCharset.accesskey "D"> This would probably have to be "E", don't forget the entity names will have be changed for both this and the one above. >+<!ENTITY viewDefaultCharset.desc "(Used for legacy content that does not declare its encoding.)"> This would be better matching the new entity names above, maybe viewFallbackCharset.*? Only f+ for the moment as I'd like to see the new patch.
Attachment #786622 - Flags: review?(iann_bugzilla) → feedback+
All comments addressed.
Comment on attachment 803924 [details] [diff] [review] Proposed patch (v2) (In reply to Ian Neal from comment #3) > > <!ENTITY viewDefaultCharset.label "Default Character Encoding:"> > I think it is worth matching what we have for the Browser here, so can we > change this to Fallback Character Encoding? Eh, I have to change the labels in the Folder Properties dialog then as well. New patch coming up.
Ok, changing the Folder Properties dialog not going to work within the scope of this bug as folderProps.xul is MailNews Core. Thus, it would have to be coordinated with Thunderbird to perform the same label changes in their prefs. This patch contains one addition relative to attachment 803924 [details] [diff] [review] though, that's a note mentioning the ability to override the fallback charset in the Folder Properties. In the process, I've noticed that there doesn't seem to be any documentation on the Folder Properties dialog and its tabs at all, and no bug report pending on those either, thus I'll go ahead and file one.
I've filed bug 916817 to cover the common Folder Properties labels and bug 916823 to make respective changes in Thunderbird's preference panes.
Comment on attachment 804514 [details] [diff] [review] Proposed patch (v3) >+++ b/suite/locales/en-US/chrome/common/help/mailnews_preferences.xhtml >+ <li><strong>Fallback Character Encoding</strong>: Click this drop-down list >+ to select the character encoding you want Mail & Newsgroups to use as >+ the fallback for incoming mail and newsgroup messages. Senders are supposed >+ to declare the character encoding in which they are to be displayed, but >+ legacy content (e.g., from mailing lists or in international newsgroups) A note to myself here really, but British English doesn't use a comma after e.g. >+ may not do so. This encoding is used for such messages you've received >+ in which the character encoding (MIME charset) is not specified. r=me
Attachment #804514 - Flags: review?(iann_bugzilla) → review+
Thanks Ian, push for comm-central please. (In reply to Ian Neal from comment #8) > A note to myself here really, but British English doesn't use a comma after e.g. Yes, those subtle differences are frequently confusing...
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.24
You need to log in before you can comment on or make changes to this bug.