Community
Participate
Working Groups
When spell-check is enabled, every word is marked as having been misspelt. I suppose that's because the dictionary is missing (or empty).
This was in RC3
We do not provide a dictionary out of the box. For 3.0 we should add this to the README. Post 3.0: the preference page should not be OK if spell checking is enabled without a dictionary.
Added to the 3.2 README.
Has the mechanism for doing this been decided yet? Mozialla Firefox is now redistributing one (e.g. Program Files/Mozialla Firefox/en-US.dic) and I wonder what license that's under. There's also: http://wiki.mozilla.org/index.php?title=L10n:Dictionaries&redirect=no
>I wonder what license that's under. From comment 4 I assume it is installed on your machine, so why not take a look and report here what license it uses? ;-)
I would like to use that one, but I'm not since I need to follow the instructions that we're giving to Mylar users ;) Those currently have them installing this one: http://wordlist.sourceforge.net/ FAQ entry on setup is: http://wiki.eclipse.org/index.php/Mylar_FAQ#Spell_Checking I just did a bit of investigation and it looks like Firefox is now redistributing that very dictionary, created by Kevin Atkinson, modified and licensed under LGPL: https://addons.mozilla.org/firefox/3497/ In the case of redistributing the dictionary, is the LGPL a showstopper? If so, perhaps we could ask Kevin to create a web link that users could easily retrieve the dictionary from in order to install it into their Eclipse workspace?
>In the case of redistributing the dictionary, is the LGPL a showstopper? I'm not a lawyer ;-) With everything which is not EPL we have to go and ask one. It might be easier when giving instructions on how to setup the workspace instead of either fetching or repackaging it.
I plan to write up an e-mail for our lawyer to see what we can do. I agree that the current solution needs improvement.
(In reply to comment #6) > In the case of redistributing the dictionary, is the LGPL a showstopper? Janet Campbell gave a talk at the Eclipse Summit Europe about legal issues. One statement was that the LGPL is a show stopper for distributing from Eclipse.org servers. It would be much easier if it would be EPL or the Apache License. But GPL and LGPL are almost impossible to be distributed from Eclipse.org. AFAIK the ECF guys have a similar problem. They have a plug-in that requires a LGPL library. They solved it by providing the plug-in from an update site not located on the Eclipse.org servers.
We use the same update site dependency mechanism for a tigris.org jira WS wrapper. But this doesn't work well for bundles/zipped installs, only for update manager based installs. If redistributing the LGPL is a showstopper, I wonder if we can consider asking Kevin Atkinson to contribute his word list under the EPL, and have us use work from a fork of that? Then we could also add patches with our own Eclipse-specific jargon (e.g. I'm tired of "Bugzilla" always being underlined in red). But I don't know if forking an LGPL word list into an EPL list is a legal operation, so writing that letter to the lawyer seems worthwhile :) Then there's also the out-of-the-box solution that WTP uses for retrieving non EPL XML schemas and such: put a button and field on the spelling page that says "download dictionary from: [url]", make the default URL be the SourceForge project as long as he agrees to maintain that URL now and forever, and have the user click through the license for the dictionary (also a URL).
Not all dictionaries are plain word lists i.e. some use a special format that we'd need to know in order to use the dictionary. In such cases letting the user accept the license would not be sufficient because we'd need to implement the specific code to interpret the dictionary.
Right, but the accepted formats could be specified by Eclipse and documented, plain word list being the obvious one. My meta-point is that just as Eclipse currently allows the user to select a dictionary via local path, it could allow similar access to an URL-based path, with the legal caveat that the user should click through a license if this dictionary is to be cached locally.
This is in progress. Legal is currently investigating what we can do here given that we're under EPL.
CQ has been sent to the EMO: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=1415
Great to see this in motion. For users adding their own words I guess we'll rely on them editing a custom full-dictionary file directly rather than their having an additional user-specific dictionary file? The former is usable but in the long-run I think the latter would be preferred because it would allow storage of the custom dictionary with the workspace data while the main dictionary file comes from a plug-in. Let me know if I should file a separate bug for that.
The user can choose one of the installed dictionaries and have a list with his additions.
Fixed in HEAD. Available in builds > N20070423-0010.
Fantastic. Since this will make spell checking readily available to way more people, we can expect Javadoc comments and bug reports to become easier to read :) I assume that it isn't time yet to enable spell checking by default, since the list is English only. I wonder if it would be a good idea to give the preference page a hyperlink along the lines of "Browse for other dictionaries online" and have that point to a wiki page where people can link them.
Mik, actually I enabled spell checking. Ideally, the language packs would contain dictionaries too. Did you get legal clearance for the things your refernce in Mylar? If so, we could maybe also use that in the SDK.
(In reply to comment #19) > Mik, actually I enabled spell checking. Ideally, the language packs would > contain dictionaries too. Great. I definitely agree that having it enabled by default is better and if it is enabled and the language is wrong it is easy for the person to discover how to fix that. > Did you get legal clearance for the things your refernce in Mylar? If so, we > could maybe also use that in the SDK. I'm not sure what you mean... Mylar has no spelling requirements beyond having spelling in the SDK. We just have a big need for it to be readily available because users of Mylar spend considerable amount time writing natural language with Eclipse (e.g. bug reports). The only additional spelling words I could think of having shipped with the Eclipse SDK are programming-specific and an Eclipse-specific words. For example, it would be nice if every Eclipse project name and if words like Bugzilla and Eclipsepedia did not get underlined. But I guess if we go down that road we should probably add them to an additional SDK-specific dictionary and not the Platform one.
>I'm not sure what you mean... I thought you had a guide, wiki or help doc that referred to some dictionaries but I might be wrong here.
Removed README entry.
(In reply to comment #21) > I thought you had a guide, wiki or help doc that referred to some dictionaries > but I might be wrong here. We have the following FAQ entry: http://wiki.eclipse.org/index.php/Mylar_User_Guide#Spell_checking However, to include anything pointed to there we would likely need separate IP approval. Also, I'm not sure how much benefit there would be over the dictionary that we have now. If after using the new dictionary I find it lacking I'll post here.
I was rather thinking of those that like to install a dictionary for a non-English language. For those we probably add a link to http://wordlist.sourceforge.net/ to the doc.
That's a good idea. Since I'm somewhat disillusioned about users referring to the documentation, I still think it would be much more useful to put this link on the preference page itself (for stability it should point to an eclipse.org page with a link). I realize that the SDK does not have external preference page links of this sort and it could be good to indicate that it won't work unless connected to the Internet (e.g. with a browser icon). However, such links are now commonplace in OS's like Vista and they really are helpful. I just checked Thunderbird 2.0 and it does exactly that (attaching screenshot).
Created attachment 64835 [details] Thunderbird spelling preferences screenshot Resolves to: https://addons.mozilla.org/en-US/thunderbird/browse/type:3
Verified in I20070502-0010
.
