Improve our spell checker offering on Mac

Ehsan Akhgari ehsan.akhgari at
Fri Dec 30 00:29:42 UTC 2016

On Thu, Dec 29, 2016 at 5:39 AM, Tim Guan-tin Chien <timdream at>

> On Thu, Dec 29, 2016 at 7:58 AM, Ehsan Akhgari <ehsan.akhgari at>
> wrote:
>> On Sat, Dec 24, 2016 at 10:57 AM, Tim Guan-tin Chien <
>> timdream at> wrote:
>>> On Sat, Dec 24, 2016 at 9:33 PM, Ehsan Akhgari <ehsan.akhgari at>
>>> wrote:
>>> > The spelling suggestions between different spelling engines will almost
>>> > definitely always differ. However with the example below it is unclear
>>> to me
>>> > which suggestion is better, since the typed word barely resembles
>>> either of
>>> > the two suggestions. It also depends on the words you include in the
>>> > dictionary. For example we exclude rare English words from the
>>> dictionary
>>> > because they're much less likely to be used in real text and it would
>>> serve
>>> > as a bad suggestion for a misspelled word.
>>> I would agree it's a hard problem. That's why I am asking for better
>>> user insight into this (instead of rely my guy feeling, or yours).
>> Can you please an example of what you would like to see?  I still don't
>> understand what you're proposing.  It looks like we both agree we shouldn't
>> make decisions on the spell checker *engine* based on the quality of
>> suggestions for one word in the English dictionary.
> I don't have more examples than keep populating my list as I encounter
> them. Should I come back after I have enough words in the list, or are you
> asking for something else?

I think what I'm trying to understand is how one should compare the quality
of spell checking suggestions between two different products.  Are you
familiar with any useful metrics?

I can believe that using vastly different techniques than a word list + a
set of rules, we may be able to achieve substantially better spell checking
suggestions.  For example, it's probably possible to train a model to
suggest correct spellings for a language where a large corpus of typo +
corrections is available.  But naively it appears to me that expecting
substantially better results from a very similar system to what we ship
isn't reasonable.

FWIW OS X *also* uses Hunspell, albeit with a proprietary word list, which
explains why you're seeing different spelling suggestions from it.  We
currently use an en-US dictionary based on SCOWL <> with some Mozilla added words.  It would
probably be interesting to measure how well our current dictionary performs
against the different pristine SCOWL variants.

> In the context of product offering, my proposal is, instead of us decide
> what's *better*, we should make the product team aware of the feature and
> maybe make a quicker decision based on the great-or-dead notion. I don't
> know if this is a list they are reading.

I don't know if they are either.

About the "great or dead" mention, I never fully understood how serious the
title is, but even if Apple's spell checking suggestions proves to be
better than ours, that's no argument for removing the spell checking
feature completely (which is not something that's realistically going to
happen!)  Spell checking is part of the modern feature set of every browser
these days, so let's limit the conversation to realistic options.  :-)

> > Another point to consider is the breadth of different languages
>>> supported. I
>>> > don't know how many languages OSX supports for spell checking but I
>>> wouldn't
>>> > be surprised if that's a subset of the languages we support.
>>> That's indeed being mentioned on the original bug.
>>> I would argue that we should at least offer OSX spell as a pref-able
>>> user choice, given how hard it would be to build that as an add-on.
>> The current spell checker module doesn't do a great job at abstracting
>> away the spell checking backend details, although we try to a bit (see
>> mozISpellCheckingEngine for the current backend abstraction.)  We also
>> don't support more than one engine, so supporting the Apple spell checking
>> backend is probably going to be a significant amount of work (I don't know
>> anything about the programmatic API that Apple provides and how hard that
>> is to use for us, I'm assuming that part is sufficiently straightforward
>> with a quick look at
>> ference/appkit/nsspellchecker).
>> I'm still unconvinced that supporting this for the purpose of spell
>> checking is meaningfully better or worse than what we currently have,
>> ignoring the issue of the languages that Apple doesn't support.  However I
>> think this would be interesting if we wanted to use the grammar checking
>> features.
>> This all being said, the current spell checking module is almost
>> unmaintained, so realistically I don't expect any work to be done here for
>> the lack of human power if not anything else.  :(
> Yeah, I understand given the effort needed this need more justification.
> Thank you very much for the response BTW.

My pleasure!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list