Editor: Proofreading

[aduth]

Closes #306

This pull request seeks to enable a user to proofread their writing via the AfterTheDeadline service.

Implementation notes:

The plugin is largely a port of the atd.core.js and editor_plugin.js modules, adapted for use in Calypso.

Main points of divergence include:

• Revised code styling to conform to Calypso lint rules
• Communicate with AfterTheDeadline via CORS, not proxy endpoint [1]
• Persist "Always Ignore Suggestion" options to user preferences [1] [2]
• Use Calypso lib/mixins/i18n for string translation [1]
• Add proper default browser spellcheck disabling [1]
• Use supported localized AfterTheDeadline service hostname if can be determined [1]

Because this is a port of large preexisting files, it's recommended that you focus review on the items listed above. It is not the intention at this time to convert existing files to ES6 standards.

Testing instructions:

Verify that proofreading behaves as expected, particularly with regard to the items listed above in Implementation Notes.

1. Navigate to the Calypso post editor
2. Select a site, if prompted
3. Note that a "Proofread Writing" button is included in the editor toolbar
4. Enter content in the editor content area, intentionally including a proofreading mistake
5. Note that your browser built-in spellcheck may flag the spelling mistake
6. Click the "Proofread Writing" button in the editor toolbar
7. Note that the spelling mistake is flagged with a solid red underline
8. Note that if browser built-in spellcheck was flagged in Step 5, it is no longer flagged
9. Click the spelling mistake
10. Note that the mistake reason is noted, including substitutions
11. Click a substitution, Ignore Suggestion, or Ignore Always
12. Note that...
    • If a substitution is clicked, the text is replaced
    • If Ignore Suggestion is clicked, the text is unflagged as being mistaken
    • If Ignore Always is clicked, the text is unflagged as being mistaken, and upon saving and reloading the page, the error is not flagged on subsequent Proofread Writing checks

Open questions:

• Should we add a feature flag, restricting this to particular environments pending further testing?

[ryanboren]

https://test.wordpress.com/2016/02/22/editor-atd-spellchecking-correcting-a-word-with-atd-editor-iphone-6/

[aduth]

I've spent a considerable part of my morning trying to debug why Safari iOS appears to be ignoring spellcheck attributes. Even in the following minimally reproducible page, I'm still encountering spelling suggestions upon tapping words, despite having all of the standard supported spellcheck disabling attributes present:

http://output.jsbin.com/tosebedofa

Currently downloading iOS 9.3 SDK beta in hopes that this may be resolved in the upcoming release.

[timmyc]

This URL is invalid - I think it should be http://www.afterthedeadline.com/development.slp

[aduth]

This URL is invalid

Good eyes! Fixed in rebased c312168

[aduth]

I've pushed some changes which should be a slight improvement of behavior on mobile. Unfortunately, this does not include any fix for the default browser spellcheck in iOS, and the browser spellcheck appears to interfere with the plugin suggestions menu.

Improvements include:

• Suggestions menu should reposition when editor is scrolled (b0efb4b)
• Suggestions menu should be dismissed when tapping other words in the editor, and when dismissing the mobile flyup keyboard (699d6aa)
• Suggestions menu should be dismissed when cancelling proofreading mode (61b872c)

With regards to iOS Safari default browser spellcheck, the workaround I've found is dismissing the keyboard via "Done", then tapping on the next highlighted term.

[timmyc]

Not knowing much about this service at all, should the button only be shown it the user's locale is available here?

[aduth]

Not knowing much about this service at all, should the button only be shown it the user's locale is available here?

Admittedly I'm following the precedent here, as the Jetpack implementation falls back to the non-localized subdomain when it cannot determine a supported locale.

There's also the question of whether we detect based on the user's locale, or the site's locale? I might imagine that we'd still want to show the option even if the user's specific locale is not supported, as they may be still be writing for an English site.

[aduth]

Currently downloading iOS 9.3 SDK beta in hopes that this may be resolved in the upcoming release.

The same issue remains present for me in iOS 9.3 Safari.

[timmyc]

I took this for a spin on the windows touch device, and it worked well. I'd say we get this in if you are ready to roll with it @aduth