User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081210 (like Firefox 3.0.4) Build Identifier: Thunderbird 3.0+ I would like to be reminded that my encoding is wrong, when clicking on "Send" button -as it used to be the case, so that I might just go back to my message and choose the appropriate encoding (different to unicode). Unicode is fine for 99% of MUA-OS-device combinations, but still not for 100%. Just give me an option (in about:config it suffices) to choose from, and leave the new behaviour as default, for the novice user. Reproducible: Always Steps to Reproduce: 1. 2. 3.

That's one of the most expensive requests possible, for a hidden pref which exposes UI. Sixty different localization teams will all have to translate the strings, then try to figure out where they are actually seen to test their translation. A few will find it, most will not, and some will be broken without knowing it. It will never be QAed or tested during normal testing, only when one of the very few people who have set the pref first sends a mismatch email, after a bug in it (introduced because the developer who caused it didn't even know that there still *was* UI) has already made it into a shipped product, at which point it better not be a bug which requires a string change, since it will then be long long after that product's string freeze. On the other hand, an extension, that would be the perfect solution.

The strings were all there in prior to 3.0 builds ;-)

The dialog box and respective backend code was removed by bug 410333, also fixing bug 328938 and bug 311821 in the process. Then, there is bug 224391 to make UTF-8 the default encoding regardless of the locale. This would be a good idea if everybody was agreeing on using UTF-8 only, but that's unfortunately not the case (yet). Thus, I can see that in a multi-lingual environment where the classical 8bit-only encoding is needed, you may run into a problem. There is also bug 410333 comment #21 describing such a conflict between Asian and Western encoding. Did you try the workaround recommended there to use intl.fallbackCharsetList.* for the purpose of defining alternate character sets? If this doesn't help either, extending bug 448842 from a Japanese to an international scope would be advised. In general, I think that finding (or optimizing) an automated solution to pick the correct encoding for the composed text would be better than reviving that modal dialog box just for the purpose of being alerted to switch the encoding manually.