User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0 To begin with, I'm aware of that Multilingual Spell Checking of Mail Messages currently is not supported in SeaMonkey 1.0. This is of course higly desirable, e.g. similar to in OpenOffice.org, and discussed in other bugs. I realize that the spellchecker today only checks the spelling against the currently active/selected language - which usually isn't an issue for the majority(?) of people that only, or mostly, tend to write their messages in one language. In that case the feature suggested by me below might be of less importance, just like it is of less importance whether you decide to use "spellcheck before sending" or "spellcheck as you type". But, for us that write messages in different languages all the time, and even use multiple languages in one message, most likely prefer "spellcheck as you type", we have to launch the "Check Spelling" option (Ctrl-k) whenever we begin typing a new message (unless we remember in what language we eventually wrote before sending our last message). In addition, have to launch the "Check Spelling" option several times whilest writing our message, to switch between the different language modes. And every time we wan't to go back and rephrase some part written in an other language we have to re-select that language. This launching of the "Check Spelling" option and selecting language from the drop-down list soon becomes quite tedious - to say the least. I therefore suggest we introduce some kind of Quick Selector for selecting the current language. What about adding an indicator, providing visual feed-back, to what language currently is active/selected? Why not place it in the status bar, next to the signed, encrypted, and on/off-line icons. There is plenty of space there - that to my awareness is not being used during the composition of messages. Language selection could then be accomplished by clicking that icon, which could present a menu (just like when right-clicking) from which to select a language directly (similar to Windows NT's language selector, found in the system tray). This saves ONE click for every change of language - and some more by not needing to click at all just to determine the currently active selection. An alternative (or configurable complement) would be to have multiple language "icons", e.g. one for each language installed (or configurable, a part there of), and all but the one representing the currently active language beeing grayed out. Then one could be allowed to switch between different language modes by just clicking a greyed out language icon. Thus saving TWO clicks for every change of language. And I cannot see why such an implementation could not be reused once Mozilla Mail Composer gets Multilingual support (a la OOo, with language markup for message, paragraphs, and individual words). The placement of the indicator(s) near the indicator icons for signed, and encrypted messages also Placing the indicator(s) near the indicator icons for signed, and/or encrypted icons seem logical to me since they all provide feed-back about the state of the current message, they are at the bottom of the message and thus most likely to be close to where you are typing (i.e. requiring smaller mouse movement to reach) - it is less probable that you use multiple languages in a short message (i.e. typing in the upper part of the Mail Compose Window), isn't it? (Although I never really liked when they moved the signed and encrypted selectors/indicators from the Mail Address Area of the Mail Compose Window). PLEASE NOTE, the implementation of Multilingual Support for mail messages is discussed elsewhere. Here we focus on language selection/switching and providing visual feed-back. What do You think about this? Please, your opinions are welcome! Reproducible: Always The above is written in the light of the current state of SeaMonkey - i.e. SeaMonkey 1.0.

Related to bug 260533 comment 2?

The selector has been implemented in bug 337155 and I think that's the main problem here. *** This bug has been marked as a duplicate of 337155 ***