1032056 - MDN should use standard spellchecker

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Editing, enhancement, P3)

Description

[Jean-Yves Perrier [:teoli]]

Both in translating and in editing mode, MDN should activate the use of the _standard_ spellcheckers.

These spellcheckers are heavily configured by our die-hard editors and they lead to much more productivity than yet-another product.

Comment 1

[Luke Crouch [:groovecoder]]

PR proposed: https://github.com/mozilla/kuma/pull/2526

Comment 2

[Luke Crouch [:groovecoder]]

needinfo? :hoosteeno for more feature definition.

Comment 3

[Stephanie Hobson [:shobson]]

From the triage meeting:

- with the amount of tech language we have contributors don't like spell checker turned on
- contributors are used to seeing the spellchecker and are confused to not see it
- maybe it should be user configurable and a remembered preference
- this would benefit from a in person user test

Comment 4

[Eric Shepherd [:sheppy]]

I strongly disagree with enabling the spell checker by default. The enormous number of API terms and technical terms that would be underlined with red squiggles would be distracting and make the spellchecker essentially worthless.

Some ideas for making this more feasible:

* Remember the user's spell checker preference so they don't have to toggle it every time

* Provide a custom dictionary with as many as possible of the tech/API terms; this is not a likely proposal but if it were, it would help

* Don't spell-check content inside <code> and <pre> blocks. This would skip most of these terms.

Comment 5

[Stephanie Hobson [:shobson]]

I wonder if we can use the MDN itself to create the custom dictionary of terms. Also, there are code editors with spell checkers, it's possible there's an open source dictionary somewhere already in existence.

Comment 6

[Jean-Yves Perrier [:teoli]]

(In reply to Stephanie Hobson [:shobson] from comment #3)
> From the triage meeting:
> 
> - with the amount of tech language we have contributors don't like spell
> checker turned on
Who said this? It is a contributor request.

Comment 7

[Luke Crouch [:groovecoder]]

(In reply to Stephanie Hobson [:shobson] from comment #5)
> I wonder if we can use the MDN itself to create the custom dictionary of
> terms. Also, there are code editors with spell checkers, it's possible
> there's an open source dictionary somewhere already in existence.

We've put dictionary/textual data in MDN pages before, yeah:

https://developer.mozilla.org/en-US/docs/Template:Promote-MDN?raw=1

Comment 8

[Stephanie Hobson [:shobson]]

(In reply to Jean-Yves Perrier [:teoli] from comment #6)
> (In reply to Stephanie Hobson [:shobson] from comment #3)
> > From the triage meeting:
> > 
> > - with the amount of tech language we have contributors don't like spell
> > checker turned on
> Who said this? It is a contributor request.

Both Sheppy and Florian said they would go to lengths to disable it if we enabled it.

Please do not take my use of the word "contributors" in my hastily jotted notes to mean "all contributors", I meant it to mean "more than one" :)

Comment 9

[Florian Scholz (Open Web Docs)]

> Both Sheppy and Florian said they would go to lengths to disable it if we
> enabled it.

Just for the record and maybe I was not clear in the meeting: I am all for having the spell checker and I will write a user script to enable it for myself, if we are not going to enable it by default.

For me it feels like those sites which disable autocomplete in input fields. It is default behavior to let the native tools to do their job.

I started to use that from today on and I already spotted a few mistakes and my writing gets improved with it being enabled. For me there is no problem at all with too many technical terms highlighted.

I will not fight for this, but work around it ;-)

Comment 10

[Jean-Yves Perrier [:teoli]]

(In reply to Stephanie Hobson [:shobson] from comment #5)
> I wonder if we can use the MDN itself to create the custom dictionary of
> terms. Also, there are code editors with spell checkers, it's possible
> there's an open source dictionary somewhere already in existence.

We need to have these terms in the 31 locales of MDN, of course. Some technical terms are translated.

Comment 11

[Justin Crawford [:hoosteeno] [:jcrawford]]

This bug asks: Should we configure CKEditor to stop disabling on the default (i.e. client) spell checker when CKEditor loads? 

Here are some factors to consider:

1. We already have a PR for this in comment 1, so LOE to implement it is small. 

2. Doing this means the client's settings for spell checking will rule. In particular, client settings will apply to these questions:
a) Is the spell checker on? 
b) What language does it use? 
c) What dictionaries are available? 

3. As a result of 2a, above, for most people the spell checker will be on by default. 
a) For most people the spell checker that is on by default will not include a dictionary with a lot of technical terms (like API or WebSocket) that our articles are full of. So for most people the experience of editing an article will include a lot of words that are perfectly spelled but not recognized by the spell checker. This may be a bad experience and/or may limit the value of having a spell checker since everything (misspellings and technical terms) will be underlined.

4. As a result of 2b, above, our non-EN locales will finally be able to include a spell checker in their regular workflow, which is not the case with the current spell checker provided by CKEditor. This may improve the quality of articles since spelling errors may be caught.

5. As a result of 2c, above, users can include their own dictionaries, which means they could include dictionaries with technical terms in them, potentially mitigating 3a, above. But those dictionaries may not exist now and building them will need to be a collaborative effort since they may need to be built in every locale.

There are clear UX reasons to make form fields behave in a standard way across the web, and we are all acquainted with good arguments to let users control their experience of the web using powerful browser features. These both argue for using the default/native spell checker.

In order to resolve the uncertainties above, we'd like to answer these questions:
* Does turning on the default spell checker result in improved article quality? (We can answer this with a waffle test and monitoring)
* Do users prefer to have lots of misspellings (proposed state, because spellchecking is on by default) or none (current state, because spellchecking is off by default)? Do they like the outcome of enabling this feature? (We can answer this first by querying our networks, and perhaps second by user testing or surveys).

Any feedback you can provide to answer these questions is much appreciated.

Comment 12

[Justin Crawford [:hoosteeno] [:jcrawford]]

:teoli and I will work to get a survey built to ask about this.

Comment 13

[[github robot]]

Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/ed627ba94afa6a6cdfa46b07cc03f248bfa29943
[Bug 1032056] Add plugin for native spell checker

https://github.com/mozilla/kuma/commit/01e7a02e335e30e29f426d098912e2d1ce154d3d
Merge pull request #2575 from hoosteeno/1032056

[Bug 1032056] Add plugin for native spell checker

Comment 14

[Luke Crouch [:groovecoder]]

To clarify, we pushed this behind a waffle flag so it's not enabled for any users yet. We can enable it for individual users - e.g., the writing team - to test it first. If it's acceptable we can push it to beta testers too.

Comment 15

[Luke Crouch [:groovecoder]]

I enabled this for myself on stage and ran into one of the issues that (I think) Florian mentioned. Right-clicking on an underlined term brings up the CKEditor context menu - not the browser context menu to help auto-correct. :/

Comment 16

[David Walsh :davidwalsh]

I really, really don't know that there's a way around that.

Comment 17

[Justin Crawford [:hoosteeno] [:jcrawford]]

The contextmenu issue is known[0].

We can disable the contextmenu[1], but this will be a global change (it will apply to everyone, not only those using the native spell checker). I don't personally find much value in CKEditor's context menu; does anyone else? 

If nobody else gets much value from it, we can simply add three plugins to the removePlugins config setting as in [1] below.

However, I suggest doing so only after we know whether this spellchecker plugin is otherwise satisfactory. Does anyone have feedback about it besides the right-click functionality?

[0] https://github.com/mozilla/kuma/blob/master/media/js/libs/ckeditor/plugins/mdn-spell/plugin.js#L51
[1] http://stackoverflow.com/a/12216307/185319 (tested, works)

Comment 18

[Justin Crawford [:hoosteeno] [:jcrawford]]

Following up on comment 17: I don't think disabling CKEditor's context menu is a great idea, since it provides important functionality for tables and lists. 

The best bet is for people using the native spellchecker to hold CTRL or CMD (mac) to access browser native context menu for spellchecking.

Comment 19

[Luke Crouch [:groovecoder]]

FWIW, I fixed our GA custom dimension segments and now I see that we've had 974 sessions with wiki_spellcheck waffle flag enabled.

Is https://bugzilla.mozilla.org/show_bug.cgi?id=1047240 the biggest blocker to expanding the feature to more users?

Comment 20

[Justin Crawford [:hoosteeno] [:jcrawford]]

> Is https://bugzilla.mozilla.org/show_bug.cgi?id=1047240 the biggest blocker
> to expanding the feature to more users?

That is the sole blocker, as far as I know. Since :teoli filed both of these bugs, am interested in his opinion about whether that blocker is so critical that we should not launch this feature. I think the feature works as well as it can without a deep and ugly CKEditor hack. Does it work well enough?

Also asking :fscholz since he is a regular user of this feature.

Comment 21

[Jean-Yves Perrier [:teoli]]

It isn't a blocker anymore. I'm using the work-around given by :fscholz several times a day and I'm very happy.

The work-around is not very discoverable though. ;-(

Comment 22

[Florian Scholz (Open Web Docs)]

Not a blocker, right. I commented on the other bug, too.

Comment 23

[Eric Shepherd [:sheppy]]

Please try out the spell check function in CKEditor 4 on the staging server and let me know if it's satisfactory (other than the fact that it only supports English right now -- I've filed a bug for that: bug 1113109.