Proposed changes to spell check default configuration on MDN

[Eric Shepherd]

(While writing this email, I discovered https://bugzilla.mozilla.org/show_bug.cgi?id=1321154 <https://bugzilla.mozilla.org/show_bug.cgi?id=1321154> — the spell checker is not currently working at all on MDN). That obviously blocks any progress on the stuff below.

I’m working on bug 1318827 (https://bugzilla.mozilla.org/show_bug.cgi?id=1318827 <https://bugzilla.mozilla.org/show_bug.cgi?id=1318827>) about enabling spell checking by default. While I’m at it, I’m looking at tweaking the default configuration a bit. Currently, we are using the default settings, which I feel are poorly aligned with our needs. I’d like to propose the following changes:

Enable spell checking by default [scayt_autoStartup = true]. The trick is that this should only be done for English until we have support for checking other languages. This will be handled separately from the basic configuration changes.
Enable “ignore words with mixed cases” (CamelCase) by default. This will help avoid API terms from being flagged as misspellings [scayt_ignoreWordsWithMixedCases].
Enable “Ignore all-caps words” by default; this will let many constants and the like avoid being flagged as misspelled [scayt_IgnoreAllCapsWords].
Configure the spell checker to ignore content inside <pre> and <code> blocks. This will prevent most code from being checked, which will result in fewer unnecessary errors [scayt_elementsToIgnore].
Set scayt_inlineModeImmediateMarkup to true so that the spell check markup remains in place even when the editor isn’t focused. This will improve usability and performance, since currently the spell check system is torn down and rebuild every time you defocus and refocus the editor.

There are then some other more advanced changes I think we should make over time as we are able. These would be filed as separate bugs (some already have bugs, actually).

Consider setting scayt_userDictionaryName to something appropriate so that each user has their own custom dictionary. This would depend somewhat on our current license and whether these are stored locally or not, which I’ve not yet investigated.
Set up multi-language spell checking so we can check languages other than English. This depends on licensing, and that would have to be looked at.
Once multiple languages are supported, the spell checker offers a bilingual check, where a page can use two languages (such as a half-translated page), and still be successfully spell-checked. This would also be quite useful.
The spell check system supports a list of custom dictionaries that we can pre-define. This would let us, for example, build a dictionary of interface names and other common API terms so that they would pass spellcheck [scayt_customDictionaryIds]. This also depends on our license scenario.

Any thoughts about any of that? I’m primarily interested in objections to any of the items in the first set of bullet points — the more immediately and quickly changeable set of defaults.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy

[John Whitlock]

I'm not a regular content editor. My changes are often to fix funky HTML I
see in the diffs, so I think I've never used the spell checker. I have no
insight into the usefulness of the spellchecker.

I think it is worth spending some time on the website of the provider
of SpellCheckAsYouType (SKAYT):

http://www.webspellchecker.net

<http://www.webspellchecker.net/>They are moving toward a
free-with-advertising model, with a paid license for self-hosting without
ads:

https://www.webspellchecker.net/signup/licensed-signup.html#wsc-trial

If we continue to use this plugin, eventually we will need to commit to the
hosted version and the license.

Custom dictionaries are stored on their servers, and require identifying
yourself to their server:

http://www.webspellchecker.net/custom-dictionaries.html

This has been a relatively free feature for a few years, an easy win.
We'll have to decide to actively embrace this feature, in time and budget,
and probably in the next three months.

John


On Tue, Nov 29, 2016 at 9:50 PM, Eric Shepherd <eshe...@mozilla.com>
wrote:

> _______________________________________________
> dev-mdc mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-mdc
> MDN contributor guide: http://bit.ly/ContributorGuide
>

[Jean-Yves Perrier]

Hi Sheppy!

Does the default spellchecker of the browser work on editing pages?

If so, how will it collide with the SCAYT? (In English and other pages).

How is the detection of the language done? Does Kuma set an HTML
language attrribute for the edit box (or the whole document)?

--
Jean-Yves

--
Jean-Yves Perrier
Senior St. Project Manager, Developer Documentation / MDN

[Eric Shepherd]

So, this is in fact the SCAYT spell checker that I’m talking about, actually. I was avoiding that acronym since not everyone knows it. :)

The question about how or even if it detects langauges is an open one. There’s an editor option for what the default language should be; what I don’t know is if we already update that based on the user’s locale or not. If not, it shouldn’t be hard to fix.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>

Twitter: http://twitter.com/sheppy <http://twitter.com/sheppy>

[Eric Shepherd]

Yeah, I noticed that about the plugin while doing my research. What I don’t know is if CKEditor (which distributes it as part of the CKEditor system) includes the license for the spellchecker in the license for the editor or not. My guess is no, and that we’ll have to decide to license that ourselves.

One feature I believe they offer is that you can get a self-hosted license where the user dictionaries are stored locally instead of on their server, which I suspect would be better for us.

The next question that comes up is if there’s another spell checker we could use instead that would give a comparable experience but doesn’t have the same license terms, if those issues concern us.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy <http://twitter.com/sheppy>

[John Whitlock]

On Thu, Dec 1, 2016 at 10:16 AM, Jean-Yves Perrier <jype...@gmail.com>
wrote:

> Hi Sheppy!

>
> Does the default spellchecker of the browser work on editing pages?
>
> If so, how will it collide with the SCAYT? (In English and other pages).
>
>

The native spellchecker is disabled by default and in our deployment. It
probably should not be enabled at the same time as SCAYT.

Here's the CKEditor docs on the spellchecker, including the native and
SCAYT options:

http://docs.ckeditor.com/#!/guide/dev_spellcheck

[Eric Shepherd]

Ah yes, I misread that before. No, you can’t use both at the same time, and I’m not certain how well the built-in spell check works with CKEditor but that might be worth investigating as well.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy <http://twitter.com/sheppy>

[Makyen]

I routinely use the default Firefox spellcheck capability while editing
on MDN with the CKEditor in both WYSIWYG and source views. I use a user
script to enable the default Firefox spellcheck capability (add
spellcheck="true" to the appropriate elements), then use
Ctrl-Right-Click to get the standard Firefox context menu.
Shift-Right-Click would also work, but I have that mapped to other
functionality.

You can enable both the default Firefox spellcheck and SCAYT at the same
time. Words which are not recognized by both are double underlined.

Obviously, the largest issue with using the default Firefox spellcheck
is that CKEditor overrides the default right-click context menu.
Personally, I find this to be _very_ annoying. I find the CKEditor
supplied right-click context menu to be near-useless and significantly
negative in that it is much more limited than the default context menu
with very limited additional functionality in only specific
circumstances. All of the added functionality I have seen would be much
better integrated in the floating menubar (where users will naturally go
looking for it). Overriding the context menu is almost always a bad idea
from a user experience point of view. Personally, I would prefer that
the CKEditor context menu be disabled, which is possible to configure in
the options supplied to CKEditor.

Here is code to toggle on/off the default Firefox spellcheck for editing
MDN pages, written as a bookmarklet (so you can easily try it out):
javascript:(function(){let
bod=document.querySelector('.cke_wysiwyg_frame').contentDocument.body;let
setval='true';if(bod.getAttribute('spellcheck')==='true'){setval='false';}
bod.setAttribute('spellcheck',setval);document.getElementById('id_comment').setAttribute('spellcheck',setval);})();

Makyen

[Janet Swisher]

Thanks, Makyen! That's very useful info about how you're using
spellcheck features, as an active contributor.

And by the way, thanks for all your contributions to MDN over the past
year and more. You've done a ton of maintenance on pages related to
add-ons and web extensions (and other topics). That makes them more
correct and easy to read, which helps MDN's readers find the info they
need to accomplish their goals. You're a hero!

--Janet

--

Janet Swisher <mailto:jREMOVE...@mozilla.com>
Mozilla Developer Network <https://developer.mozilla.org>
Community Strategist

[Eric Shepherd]

Makyen,

This is great insight and incredibly useful. I’m going to experiment with entirely disabling the CKEditor SCAYT plugin and using the browser’s own spell checker on my local MDN dev system.

I also agree that the CKEditor context menu’s usefulness isn’t always very good. I think it would be interesting to see if we can get the parts that are useful to just go into the standard context menu instead.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy <http://twitter.com/sheppy>

[Eric Shepherd]

So, as I expected, the current versions of CKEditor don’t directly support using the standard HTML contextMenu since it didn’t exist when they created it. I hope that CKEditor 5 will use it but that’s some time away. What I don’t know is how many people use the context menu (or would use it if it were more helpful than it currently is). Personally, I use it quite often already, but I know I’m not a typical user.

We could conceivably create our own code that adds the options we want to the standard menu, but I don’t know how realistic that is. This leaves me torn on the best way to approach this. I’d like to have access to the context menu features for the editor, but I do agree that many spell checking issues are made much better using the browser’s spell check.

I suspect that sticking with the SCAYT plugin will be necessary for the short term at least, given the time available to make changes here and the complexity of making the transition to the built-in spell check. Unless we’re really open to getting rid of editor features provided through a right-click. I don’t think that’s a great idea, but again, that may just be me.

Eric Shepherd
Senior Technical Writer
Mozilla
https://developer.mozilla.org/ <https://developer.mozilla.org/>
Blog: http://www.bitstampede.com/ <http://www.bitstampede.com/>
Twitter: http://twitter.com/sheppy

[Sebastian Zartner]

On 9 December 2016 at 05:57, Eric Shepherd <eshe...@mozilla.com> wrote:
> So, as I expected, the current versions of CKEditor don’t directly support using the standard HTML contextMenu since it didn’t exist when they created it. I hope that CKEditor 5 will use it but that’s some time away.

I didn't see an issue filed for that on the GitHub repo[1]. So, I
guess we should file one for that. On the other hande, Firefox is the
only browser so far supporting this feature by default[2], so it may
get poor reception by the developers.

> What I don’t know is how many people use the context menu (or would use it if it were more helpful than it currently is). Personally, I use it quite often already, but I know I’m not a typical user.

That sounds like something that requires some data collection.
Personally, I use the CKEditor context menu mostly on tables, almost
never in other contexts (while I should do so more often).

> We could conceivably create our own code that adds the options we want to the standard menu, but I don’t know how realistic that is.

Presumably some bigger amount of work.

> I suspect that sticking with the SCAYT plugin will be necessary for the short term at least, given the time available to make changes here and the complexity of making the transition to the built-in spell check. Unless we’re really open to getting rid of editor features provided through a right-click. I don’t think that’s a great idea, but again, that may just be me.

Getting rid of the editor features context menu also doesn't sound good to me.

Sebastian

[1] https://github.com/ckeditor/ckeditor5/issues?utf8=%E2%9C%93&q=is%3Aissue%20context
[2] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contextmenu#Browser_compatibility