129704 - SpellChecker API Redesign

Status: RESOLVED INACTIVE

(Core :: Spelling checker, task, P3)

Description

[kinmoz]

This bug is intended for tracking and discussing issues related to a possible 
rewrite of Mozilla's Spellchecker interfaces.

I'll be updating this bug with some of my ideas to start off the discussion. I 
know that David Einstein ([e-mail]) has some ideas too.

Comment 1

[kinmoz]

I've been thinking I should've implemented things at 2 different levels so that 
plugging in different spellcheckers would be easier.

At the lowest level, I think there should be a spellchecker interface that knows 
nothing about document structure, selection etc. The aim of this interface is to 
be as simple as possible and allow people to write glue code to their favorite 
spellchecker in under a day's time. This interface would be pretty basic and 
provide methods that allow us to query the dictionaries/languages it supported 
(so we could pass that back to the UI) and allow us to select which ones we 
wanted to use to check words. It would also have a checkWord or lookup method 
that just takes a word (string), the language used in the word's surrounding 
context, and perhaps the charset used in the word. This method would then give 
you back a bool telling you if the dictionaries used thought the word was 
misspelled, and something that allowed us to iterate over the replacement 
suggestions for the word.

At a higher level (spellchecker driver), we would have some interface that knew 
how to operate on DOM nodes ... but the interface itself would take a set of DOM 
ranges, similar to what the new find code uses, which would tell it the bounds 
in which it can operate and where to start/end it's checking. This would allow 
us do things like check the entire document, check specific portions of the 
document, or just what's inside the current selection. Note that this 
implementation would also be able to do checking inside mozilla text widgets 
since it also uses DOM nodes internally.

This higher level interface, would know nothing about selection or the document 
structure either. I'd really like to push that back on the app using this 
"driver". The implementation of this interface would be responsible for 
iterating over the nodes in the "check range" breaking the text into words based 
on the current language of the block and calling the low level interface to 
check the words. If it ran across a word that the low-level interface thought 
was misspelled and perhaps had some suggestions, it would then return a DOM 
range back to the app that represented the location of the word as well as the 
suggested info. The app would then use whatever means it had to select and even 
replace the word. Note that the app could use the new Find/Replace interfaces to 
implement the spellcheckers "change all words" feature.

Note that this driver level implementation could also be given a list of 
low-level spellcheckers to call when checking a word. (Use multiple 
spellcheckers)

We could also have this driver level maintain the user dictionary so that we 
have one list for all the spellcheckers.

We also need to think about a filtering mechanism that will allow us to skip 
over content that is not visible, for example text nodes that between <script> 
tags, etc.

Comment 2

[David Einstein]

See spellchecker.mozdev.org

I had made a mozISpellchecking engine interface that somewhat implements a low
level interface to a spell checker.  I have not paid as much attention to it as
I could have, but it pretty much does all that I want it to.  I probably want to
add a property setting function so that mozilla can turn on and off special
features of spell checkers.  I think that this will be necessary for system
spellcheckers, like those provided by OSX or KDE and probably others (does XP or
.net provide a system spellchecker?), and I think that it is crucial that we
support these.

I agree with the higher level interface, and was kind of thinking along the
lines of the new nsFind.  I also think that this makes it much easier to skip
unwanted text such as javascript, quoted mail, or signatures.  

The personal dictionary is somewhat tricky in the face of multiple languages, as
the system wide personal dictionary may be monolingual, and a multilingual user
may want to use a mozilla PD for some languages, and the system PD for others.

Comment 3

[rods (gone)]

taking

Comment 4

[Ben Bucksch (:BenB)]

See bug 180346

Comment 5

[rods (gone)]

reassigning

Comment 6

[Gérard Talbot]

According to this file
http://www.mozilla.org/quality/browser/front-end/testcases/composer/composer-spellcheck.html
there should be a clickable Help (button or link?) which would open an "About
the Edit Dictionary Box". Are there any plans to implement help, documentation
of some sort regarding Spell Checking?

For now, I'll make bug 256260 dependent of this bug. You may redirect bug 256260
to Documentation and Mozilla Developer (to update that composer-spellcheck.html
file) if there are no plans to implement a Help Button or Documentation of some
sort.

Comment 7

[Michiel van Leeuwen (email: mvl+moz@)]

This bug is about the code interfaces, not the user interface

Comment 8

[Adrian Needham]

(In reply to comment #0)
> This bug is intended for tracking and discussing issues related to a possible 
> rewrite of Mozilla's Spellchecker interfaces.
> 
> I'll be updating this bug with some of my ideas to start off the discussion. I 
> know that David Einstein ([e-mail]) has some ideas too.

Hi, not shore if this is the right place for this request. I am not good at
spelling so I would love a "nearest" field in the Mozilla spell cheacker that I
can scroll through. Keep up the great work BTW! ~Mozfan.

Comment 9

[Ian Pottinger]

Is this bug still relevant or should be be closed?  

Comment 10

[Brett Wilson]

(In reply to comment #9)
> Is this bug still relevant

Very much so.

Comment 11

[Kagami Rosylight [:saschanaz] (they/them)]

I guess this is not relevant anymore, but please reopen if it is.