Spinning off from bug 343299: ------- Comment #1 From philippe 2006-06-30 18:41 PST [reply] ------- Additional: there should be an option to allow to switch dictionaries for people who use multiple languages. -- Apple sets some sort of default (per user? per app?) in some unknown way, so we need to have UI to allow our users to set a default and to let our multilingual/polyglot users switch languages in each text field. (This has been a common complaint on the forum, for example.)

(In reply to comment #0) > Apple sets some sort of default (per user? per app?) in some unknown way, so we > need to have UI to allow our users to set a default and to let our > multilingual/polyglot users switch languages in each text field. (This has > been a common complaint on the forum, for example.) > The default dictionary for spell checking in Cocoa apps (at least, Mail.app, TextEdit,...) is based on the login language. If you set up your <User> to use French, the default dictionary will be the French one, unless you specify otherwise in an application. That pref is then set for all apps that are not running for that one user. In other words, that pref is saved globally (maybe in com.apple.Dictionary.plist or in .GlobalPreferences.plist, not sure), not in the application specific plist file (I consider that a weakness in Apple's implementation).

murph, can you have a look at this soon-ish and make sure it's feasible?

Sure Smokey, I'm taking a look at it right now… Except for the spell checking handled elsewhere in our UI, the browser form element checking is all performed utilizing mozilla API's right now. At the moment, I'm unsure as to what underlying dictionary those APIs are referencing. This means we're not explicitly using Cocoa's NSSpellChecker service. I think, with regard to spell checking, we're going to end up behaving more like Firefox and less like full-fledged Cocoa apps such as Mail and TextEdit, since we can't display the standard spelling panel. This should nevertheless be feasible and I'll try make it work as seamless as possible, especially since it's a widely requested feature.

To elaborate on my previous comment: It turns out, after looking into this in more detail, the mozilla API we're using actually does wind up using the standard Cocoa NSSpellChecker class underneath. It seems as though pink's mozOSXSpell fundamentally handles the spell checking operations. mozOSXSpell is an implementation of mozISpellCheckingEngine (which allows it work with editors in the browser content) but does its work as a thin wrapper around NSSpellChecker. I'm pretty sure this is the case, but if anyone knows better feel free to set me straight here. Based on that, I have a working technique to change languages. It's also possible to obtain the languages installed on the system, but I have to figure out how to convert the ISO abbreviations (like en or fr) into something suitable for the user to choose from.

Alright, I've been comtemplating this one for a few days. Here's where I'm at… Switching dictionaries is very simple, since Camino's spell checking fundamentally rests on top of NSSpellChecker, and just involves messaging the shared spell checker with setLanguage:. That's cool, but what languages should the user be able to choose from? The difficulty in answering that question has been my holdup so far. The best approach would probably entail retreiving the "AppleLanguages" default from the NSGlobalDomain in standard user defaults. This value corresponds to the preferred languages ordered list set by the user in the "International" system preference pane. This would return an NSArray of NSStrings such as (en, "en-GB", fr, de, es, it, nl, sv, nb, ja, "zh-Hans", da, fi, pt, "zh-Hant", ko, hu). We can hand any of those canonical designations to the spell checker to change the language. The user, however, needs to be able to choose from actual language names presented in the current system language. There are a few facilities for doing that as well, but much of that functionality was addressed in Tiger and we have only a few limited options for 10.3. NSLocale was introduced in 10.4, but it's just a toll-free bridge from CFLocale which did exist in 10.3. CFLocale only provides a technique to go in the opposite direction, from a string to canonical value (using CFLocaleCreateCanonicalLocaleIdentifierFromString()). I had other ideas to accomplish this with CFLocale, but failed after experimentation. That leaves us with old Carbon methods declared in MacLocales.h, which is a part of CoreServices. These functions, specifically LocaleGetName(), provide the behavior we need. The problem: these functions are for locales, and there are minor differences between a "locale" and "language," particularly when dealing with languages with a region attached (such as "en-GB" for British English, or "fr-CA" for French Canadian) These utilty functions expect a locale designation, in which underscores are actually used, making the previous examples "en_GB" and "fr_CA". Moreover, Apple migrated to new canonical forms for certain languages in Tiger, which now returns "zh-Hant" instead of "zh_TW" for example. The old functions in MacLocales.h are unable to recognize "en-GB", "fr-CA", and "zh-Hant" - they return only the language itself, sans region, meaning "English", "French", and "Chinese" are returned respectively. What should be returned is "English (United Kingdom)", "French (Canada)", and "Chinese (Taiwan)". In case anyone's curious, here's some more explanation about the locale vs. localization topic: <http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFLocales/Articles/CFLocaleWorking.html> I'm fairly sure that these MacLocales.h utility functions are our only choice in taking a canonical designation and converting it into something suitable for the user to see in a menu item. Other approaches for determining which languages to throw into a "switch dictionary" menu could be to examine Camino's app bundle and just use the localizations we provide. This technique unnecessarily limits the language choices though, since OS X provides a ton of dictionaries we'd miss doing it that way. So, that's the hitch with this bug! If I'm incorrect about anything I mentioned above, or perhaps just missed something obvious, feel free to let me know. Basically, it all comes down to where should we get a list of languages to present to the user?

The wrinkle I see in this is that there are only a few dictionaries in a standard Mac OS X install (and one, Multilingual, that doesn't correspond to a locale at all). Surely there has to be a way of asking NSSpellChecker what dictionaries are actually installed (instead of throwing darts at locale lists and the International prefs)....

(In reply to comment #6) > Surely there has to be a way of asking NSSpellChecker what dictionaries are > actually installed (instead of throwing darts at locale lists and the > International prefs).... So far the answer to this, in (what seems now to be annoyingly typical) NSSpell* fashion, is no (or not really): http://www.cocoabuilder.com/archive/message/cocoa/2006/1/13/154341 http://www.cocoabuilder.com/archive/message/cocoa/2004/5/24/107877

(In reply to comment #7) > So far the answer to this, in (what seems now to be annoyingly typical) > NSSpell* fashion, is no (or not really): > > http://www.cocoabuilder.com/archive/message/cocoa/2006/1/13/154341 > http://www.cocoabuilder.com/archive/message/cocoa/2004/5/24/107877 Yeah, lol, this isn't exactly the hottest topic on Cocoa-Dev, since most programs never need to populate their own list of supported languages and instead rely on standard Cocoa classes as well as the OS to provide that stuff automatically. We're in a somewhat unique situation it seems. Thanks for the screenshot, that's good to see since I have the same list, line for line, on 10.4.8. I'm beginning to think we might have no choice but to use that as our base list. This will get this bug moving, hopefully into 1.1, and satisfy probably about 95% of our users who are strongly requesting for this feature be offered. Plus, going with a static listing approach will reduce the complexity of the code, which increases proportionally to how dynamically we generate this list. This static listing created by us doesn't have to be hard coded and require an entire recompile in the situation where a language has been added. A property list could be used, existing on its own or in the user-defaults system. Handling NSSpellChecker's setLanguage: method a string such as @"British English" does not work, meaning a list of canonical designators, @"en-GB" in this case, will have to be kept along with the names. The International system preference pane, under Language and then Edit List…, allows a choice from just about every language under the sun. Obviously, Apple doesn't provide a spelling dictionary for every single one, they're mainly for setting up that preferred locale list and then searching application bundles to see which languages they offer a localization for. Then, regardless of the existence of a system spell-checking dictionary, some applications may support your language of choice. But, are there any languages listed there which are accompanied by and will insert a new dictionary into the spelling panel's list of choices when added?

Other questions that would need to be answered before using a hard-coded list: - Is there any way for users to add new dictionaries? - Are dictionaries for all languages installed even if the system localizations for those languages are never installed?

(In reply to comment #9) > Other questions that would need to be answered before using a hard-coded list: > - Is there any way for users to add new dictionaries? Yes. See the second bullet in this section: http://wiki.caminobrowser.org/Website:Documentation_Changes_for_1.1#General.2FFAQ

(In reply to comment #9) > Other questions that would need to be answered before using a hard-coded list: > - Are dictionaries for all languages installed even if the system localizations for those languages are never installed? Yes, I have tested and can verify that spelling dictionaries are always present regardless of whether the corresponding language translation packages were chosen when installing Mac OS X. I didn't test cases in which a tool like Monolingual <http://monolingual.sourceforge.net/> is used and removes languages in a possibly more destructive way. NSSpellChecker's setLanguage: does return a boolean value which indicates if the Language pop-up list in the Spelling panel lists the specified language.

What we could alternatively do here is provide access to the standard Cocoa spelling panel (the one that appears when you choose Edit->Spelling->Spelling… in TextEdit, for instance). Supporting the panel outside of a NSText based control is possible: checkSpelling: is sent to the firstResponder when "Find Next" is clicked in the spelling panel. Inside this method, we'd have to determine what the next misspelled word is and call updateSpellingPanelWithMisspelledWord: on the shared NSSpellChecker. Additionally, the NSIgnoreMisspelledWords and NSChangeSpelling protocols would have to be implemented to support the remaining spelling panel actions. The most difficult task is bridging the checkSpelling: method with nsIInlineSpellChecker/nsIEditorSpellCheck, because interactive spell checking (stepping over misspelled words via GetNextMisspelledWord) doesn't seem to be available within the context of an inline checker. A comment in nsIEditorSpellCheck.h hints at this: "Turns on the spell checker for the given editor. enableSelectionChecking set means that we only want to check the current selection in the editor, (this controls the behavior of GetNextMisspelledWord). For spellchecking clients with no modal UI (such as inline spellcheckers), this flag doesn't matter." I'll keep trying, but I wanted to detail this secondary approach here because it's possible someone more familiar with the core mozilla code might see a way to implement this that I didn't.

To expand upon my previous comment, I think supporting the standard "Spelling…" panel is the best approach we can take. My prior technique was along the lines of introducing a submenu titled "Language" into the input field's context menu (like Fx2). The list of languages inside this submenu would have, as we're all aware of now, required an unstable hacked-up technique or a static hard-coded list. There is no supported method in any Cocoa/Carbon/System API for obtaining a list of languages identical to what appears in the Spelling panel. So, I suggest adding a context menu item titled "Spelling" to the input field whose submenu mimics exactly what you'd get right/control-clicking in a Cocoa text control: Spelling > Spelling... (Shows the spelling panel) Check Spelling (Rechecks the entire range in the editor) Check Spelling as You Type (enables/disables checking on this field - bug 348702) Supporting the spelling panel means changing languages can then be done in a familiar way for users (within the panel itself, just like other Cocoa apps). It also allows for interactive checking, specifically the ability to iterate over all misspelled words using the "Find Next" button and perform actions on each one. The iteration has an added incentive in our case, because quickly selecting and acting on many misspelled words by right-clicking each one is annoying at the moment (see bug 365183, bug 343296). My last comment indicated I was having trouble supporting the callbacks from the Spelling panel and jumping around to each misspelled word. I spent a lot of time messing around with the mozilla API since then and have implemented this behavior perfectly now. So, the "Find Next", "Ignore", and "Correct" panel buttons perform the proper action when used on any text field, exactly like they would in a TextEdit document. I'm almost ready to submit this code as a patch, hopefully in the next couple of days.

Alright, here's where I'm at: As for implementing the spelling panel's "Find Next" behavior - ideally this would involve asking the inline spell checker of the focused editor to jump to and then select the next misspelled word from the carat location. This functionality is offered among the spell checking components as nsIEditorSpellCheck::GetNextMisspelledWord, which actually calls nsISpellChecker::NextMisspelledWord. I found early on that NextMisspelledWord never seemed to work correctly. I decided to take a look at the source to learn why... NextMisspelledWord works by utilizing a nsITextServicesDocument object to obtain a text block and then iterate to each word in that block, check it, and if found to be incorrect generate a list of suggestions and return the word. nsITextServicesDocument's job is to present the entire document (web page) as a bunch of flattened text blocks. The incorrect behavior exhibited by NextMisspelledWord stems from this text services object - the initial text block it returns is equal to the entire text content of the page, not just the text value of the current editor. To describe the situation further, here's a concrete example: I'm on a site with an input text field somewhere in the middle of its content, such as http://w3.org/, and I type an incorrectly spelled word into the "Search W3C" text field. Now in code, I obtain the inline spell checker of the current editor and call its GetNextMisspelledWord method, which simply defers this task to nsISpellChecker::NextMisspelledWord. During the first execution of NextMisspelledWord, instead of obtaining only the text I've entered into the text editor, it operates on the entire text content of the web page. Each word is then processed one-by-one in the order it appears in the page source and checked for correctness. The iteration stops when a misspelled word is found. So, on w3.org, this means all text content (beginning with: "Leading the Web to Its Full Potential...") is scanned and checked until the word "Amaya" (further down the left hand side) is reached. Execution is stopped at "Amaya" since it is the first misspelled word discovered on the entire page. Interestingly, any subsequent call to NextMisspelledWord will correctly operate on only the text entered into the editor. This is because the nsITextServicesDocument is now aware of the focused editor's location and knows how to return only the relevant text block to the spell checker. This behavior is even more unreliable on other web pages though, and often fails to work properly on these sites no matter how many times it is called upon. On http://google.com for instance, typing some text into the search field and calling NextMisspelledWord performs a spell check not on what was entered into the search box - instead content outside of the search field is obtained ("Personalize this page | Sign in" in my case) and a check is performed on it instead. Unlike the above case dealing with the W3C site, which demonstrated correct functionality by NextMisspelledWord the second time it was is called, succeeding calls to NextMisspelledWord on Google never adjust the text block and always spellcheck the same irrelevant area outside of the focused editor. Basically, I'll summarize by saying that nsIEditorSpellCheck::GetNextMisspelledWord (which, again, calls nsISpellChecker::NextMisspelledWord) does not behave as expected and therefore fails to satisfy our requirement of iterating over the misspelled words in the focused text editor. Furthermore, it does too much unneeded work by re-checking each word it reaches and then generating a list of suggestions when it discovers a misspelled word. It also does not wrap around to the beginning of the text. We simply need a method to perform a linear search and highlight closest red-underlined word to the current carat location. The spelling panel will generate suggestions when -[NSSpellChecker updateSpellingPanelWithMisspelledWord:] is sent. I am by no means perfectly fluent among the Core-related code, but after close examination I'm fairly confident the behavior I describe above is what's actually happening. From what I could tell, NextMisspelledWord isn't called upon from any component found in the Core, Camino, or Firefox code bases at all. A quick look at the Firefox source seems to indicate that its developers created a nsISpellCheckController object to search and obtain misspelled words. Our options are to implement a technique to find the next misspelled word ourselves or modify the Core components we rely on. I do not view modifying/fixing Core code as the most viable choice. Camino seems to be the only client using the Core spell checking modules in need of a way to jump around to each incorrect word in this manner. Handling the "Find Next" search in Camino code, outside of Core, is the approach I initially embarked upon when I found NextMisspelledWord to operate so unreliably. Regardless of the correctness of the Core API, all existing methods perform extra work by re-checking each word and obtaining a list of suggestions, which we do not need. I realize that I'm probably providing way too much detail here and should just fix the bug. Nevertheless, I wanted to fully explain the situation and why I may end up submitting a patch which finds misspelled words using a procedure other than the seemingly-obvious nsIEditorSpellCheck::GetNextMisspelledWord.

Please find out if GetNextMisspelledWord is indeed broken. If it's buggy we should at least find out if it could realistically be fixed in the core on the 1.8 branch before we re-invent the wheel at the Camino layer.

That buggy behavior might make sense for doing something like content.editable and checking that text; dunno.

I've found there to be two behaviors exhibited by nsISpellChecker::NextMisspelledWord when used via nsIEditorSpellCheck::GetNextMisspelledWord. Neither of the two seem to work as expected and are indicative of a bug with this component. The first behavior happens on every site I tested with the exception of a google-related service (google.com, gmail.com, etc.). The first time NextMisspelledWord is called upon, it will actually perform a spell check on the flattened down text content of the entire document, instead of selectively checking only the text found in the currently focused editor. Any subsequent calls made to NextMisspelledWord do properly check only the editor's text, and work as expected. I traced back the problem to InitSpellChecker() in nsEditorSpellCheck.cpp - in the area of code which sets up the nsITextServicesDocument used by the nsISpellChecker. A simple fix (patch attached) involves changing around the second parameter of SetDocument: - rv = mSpellChecker->SetDocument(tsDoc, PR_TRUE); + rv = mSpellChecker->SetDocument(tsDoc, PR_FALSE); The documentation for this method: /** * Tells the spellchecker what document to check. * @param aDoc is the document to check. * @param aFromStartOfDoc If true, start check from beginning of document, * if false, start check from current cursor position. */ Supplying a different option here enables mozSpellChecker::SetupDoc to properly configure the location of the text services document when it is called upon during mozSpellChecker::NextMisspelledWord. With the patch applied nsIEditorSpellCheck::GetNextMisspelledWord performs a check on the correct block of text the first time. The second behavior I experienced can be demonstrated using any google site (for instance: the search box on Google.com, or a Gmail compose message textarea). Performing the same misspelled word find never works properly no matter how many times has been called. Furthermore, some assertions are triggered when utilizing the NextMisspelledWord method on these sites, so I'd say we're encountering a definite bug. A log of the exact assertions can be found here: http://pastebin.mozilla.org/3768. One final aspect of nsIEditorSpellCheck::GetNextMisspelledWord and nsISpellChecker::NextMisspelledWord hindering us is that searching through misspelled words does not currently wrap around to the beginning of the text. The word search continues progressively through the editor and cannot loop around. We might need an enhancement to permit such behavior, as I'm not sure it's caused by the suspected bugs examined above. So, to the best of my knowledge, we are experiencing actual bugs here - and probably even two different ones. If this is in-fact true, I agree it'd be a bad idea to re-implement the functionality above in the Camino layer. We'll need someone who works on Core to take a look and confirm everything discovered here. I can file a bug under that product if preferable. The evidence I mentioned above is primarily a quick summary and I can provide more detailed information about how the failure seems to be occurring if need be.

Fix allows NextMisspelledWord to work properly the first time it is called, instead of spending the first execution adjusting the text block and then only exhibiting correct behavior from the second time onward. I'm not sure if there are any negative side-effects caused by supplying a different parameter for SetDocument. I didn't encounter anything. This still leaves the assertions on google.com and the ability to wrap.

Please do file two new bugs against core for the problems you found (assuming they haven't already been filed). If there's no API for wrapping, then it'll have to be done at the Camino layer for 1.1 at least, because we aren't going to be able to get new API on the branch.

I'd say reliance on nsIEditorSpellCheck::GetNextMisspelledWord() will sort-of block this bug until that method able to return a consistent value. The problem with it is, ignoring the fact that wrapping isn't possible at the moment, there's no way to easily know for sure when GetNextMisspelledWord has reached the end of the editor's misspelled words. GetNextMisspelledWord will proceed to - upon reaching the final incorrect word found inside the editor - jump out onto the entire page content and return the next misspelled word it finds. So, even taking care of wrapping up in the Camino layer is difficult since we have no definite way of realizing when to wrap. See the dependencies, bug 370186 and bug 370346, for more detail. One possible workaround involves comparing the nsISelection of the editor to the returned word. Cases where finding has proceeded out onto the page and found an irrelevant word would return a value that is not equal to the editor's selected text, since this selection would still be left on the last incorrect word in the editor. I'll be bummed if this doesn't make 1.1, so I will keep an eye on those Core bugs and keep working on a solution to iterate the misspelled words which is essential in supporting the spelling panel.

I crafted up a technique to force the correct behavior out of GetNextMisspelledWord() based upon the workaround I mentioned above. This allows us to sidestep the two bugs I filed against Core. But... there's another, larger, problem. It turns out that GetNextMisspelledWord() does worse than not wrapping and returning irrelevant words. On many sites, it's completely broken and triggers assertions. I did mention this fact in a previous comment, but I thought it only concerned Google sites for some reason, because every other site I compared behavior against initially worked properly without assertions. Well, further testing has indicated that the method is very broken on too many sites to consider it a viable solution to the misspelled word iteration problem. I will file bugs for this issue and have prepared a really simplified html test case which might be indicative of the problem. I spent a good amount of time coding up an awesome way to work around those first two bugs, which leaves me disappointed to learn that GetNextMisspelledWord() is completely useless at the moment. I want to again restate what GetNextMisspelledWord() has to do with implementing a way to switch languages in the first place: By far the best approach is to support and provide access to the standard Cocoa spelling panel. Thus, a primary responsibility of supporting the panel means iterating progressively over misspelled words when the "Find Next" button is clicked. One final workaround I'll propose is to traverse words manually using nsISelectionController->WordMove() and then call nsIInlineSpellChecker->GetMisspelledWord(). The latter call simply checks if a given offset location is contained in one of the misspelled word ranges (areas with red underlines, that is). Additionally, it is possible to determine if the editor does not contain any incorrect words and avoid having to progress through each one entirely, only later discovering there's nothing misspelled. This is accomplished by asking nsISelectionController for its SPELLCHECK_SELECTION - which is collapsed if nothing is misspelled. Anyway, I realize doing so would constitute implementing our own version of a GetNextMisspelledWord() method, which we agreed wasn't appropriate for re-inventing in the Camino layer, but I think it's the only option left besides waiting on Core bug fixes. What does everyone think? I'll have some time this weekend, so if there's a way to get this into 1.1b1, I'm all for working to get it done.

So here's where we could go on this bug, I think: a) murph figures out a fix for this and it's approved/landed in the next 3 days for b1 b) we land strings for the context menu now and murph figures out a fix which lands before 1.1 c) murph tells us he's discovered it's not fixable without Core fixes (i.e., not for 1.1) I feel like we're looking at scenario B is the most likely one at the moment. murph, can you confirm that we'll need 4 strings, roughly like this, for this fix? "SpellingSubmenu" = "Spelling"; "SpellingPanel" = "Spelling…"; "CheckSpelling" = "Check Spelling"; "CheckSpellingAsYouType" = "Check Spelling as You Type";

(In reply to comment #22) Yeah Smokey, I agree that based upon the current situation those are in-fact the three scenarios likely to unfold. Since any fix here will now involve implementing the spelling panel - avoiding the original approach which provides access to directly switch languages via the input submenu - I'll confirm that the 4 strings you mentioned are definitely required. This will allow us to match the UI/behavior of standard Cocoa text fields. Concerning the other two subitems, CheckSpelling can be implemented really simply by just checking the entire range in the editor, and CheckSpellingAsYouType needs to be hooked up with Bug 348702. I think you're also spot on with the estimation that approach B is the forerunner at the moment. I would really love to have this in-place for 1.1, since it really belongs alongside the release which introduces spell checking capabilities. We have three Core bugs, one of them (the assertions; report pending) is actually too serious to work with and will have to be avoided entirely. This means that our favorite GetNextMisspelledWord method is unavailable until fixed in Core. The other two bugs were easy to work around and I did have a working patch for that case. So, the newest bug report will be the one which we'll need to endorse as the top priority of the three. Avoiding GetNextMisspelledWord will unfortunately introduce a more hackish approach to iterating over the misspelled words, but it's the only means of fixing this bug without waiting on Core. However, I've been looking at so much of the Core editor and spell checking code lately that there's a slight chance I might be comfortable enough with it and be able to fix the broken behavior myself. Later today I'll see if there's any possible fix for b1. That time-window is quickly closing though, so at the very least I will try my best to implement this behavior, one way or another, in time for 1.1. If there were no Core bugs, we'd be off worrying about something else by now. But, in the meantime, those 4 strings can be localized.

Simon, can you have a look at the 3 Core bugs murph filed (and/or suggest someone familiar with that code that can help out)? They're blocking the last bit of spelling fixes for 1.1, and while murph can hack around two of them, bug 371137 is absolutely a show-stopper :(

Strings in comment 22 checked in on trunk and MOZILLA_1_8_BRANCH

Completely blocked on core -> not going to happen for 1.1. Probably our best bet it to try to lean on someone to fix the editor bugs in 1.9. Once that happens we'll revisit the milestone here; if it's soon enough we could try to get it landed on 1.8 (so this could happen for Camino 1.2). Sorry Sean :( Thanks for the valiant effort!

Make sure I put some sort of documentation/FAQ up about this (the ugly work-around of switching the lang via the panel via the CM via a chrome text field)....

10.5+ has -[NSSpellChecker availableLanguages], which is exactly what we would need for adding a menu in 10.5+. Interestingly, while it's not returning language *names*, it appears to be using locale codes (with _), not language codes, which could make the approach of comment 5 possible.

Oh, and if we are 10.5+ anyway, we can use -[NSLocale displayNameForKey:value:] to get the language names.

This implements a context menu ("Spelling Language") in text fields for changing the spelling language. I don't want to push this into the Edit menu, since we won't have the usual Spelling menu and putting something in the same place but with different content than other apps could be weird/confusing. I fixed bug 348702 at the same time, since I didn't want to show the language menu in fields that aren't being spell-checked. I'll split the panel stuff into a new bug once this lands, since we'll still want to do that instead someday.

Trunk patch coming relatively soon, but it's the same except for the _1_8_BRANCH stuff and the NSLocale skullduggery.

Comment on attachment 306340 [details] [diff] [review] Language context menu (branch) Nice! > "CheckSpellingAsYouType" = "Check Spelling as You Type"; >+"SpellingLanguage" = "Spelling Language"; Two comments: 1) On 10.5, "Check Spelling as You Type" has been changed to "Check Spelling While Typing" :p Yay Apple! Is it a big pain for us to do this "right" (and if so, too big a pain)? 2) Those two look a little odd all the way at the bottom, but given we can't yet replicate the entire Spelling/Spelling and Grammar submenu (which itself is towards the bottom, depending on how much CM bloat a particular app has), I think this is fine. Have you tested any forums/webapps that use the "disable spelling" thingy to make sure we are tracking that state properly and actually enabling it when a user chooses to enable a page-disabled text field?

This fixes 1) (I'll do the same to branch on checkin). I agree with 2, but figured this was best for the time being. I did test spellcheck=false, and it works as expected.

Updated with the localization and a change to the Multilingual entry handling per discussion with pink. This is as it will land.

As trunk will land; updated Multilingual handling.

Comment on attachment 306354 [details] [diff] [review] branch patch v2 sr=pink

Comment on attachment 306355 [details] [diff] [review] trunk patch v2 sr=pink

Bug 420161 filed for the spelling panel support that the middle of this bug discussed.

Landed on trunk and MOZILLA_1_8_BRANCH. Just to be clear: this will only be fixed for Leopard users, due to limitations of the OS in previous versions.