Bug 1475575 - Create global spelling checker for use by all GLS authors
Create global spelling checker for use by all GLS authors
Status: CLOSED CURRENTRELEASE
Product: GLS Content Services
Classification: Internal
Component: Tools & Processes (Show other bugs)
unspecified
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: David O'Brien
David Sacco
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-26 19:32 EDT by David O'Brien
Modified: 2018-01-02 18:22 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-01-02 18:22:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David O'Brien 2017-07-26 19:32:50 EDT
Description of problem:

Getting authors to consistently run spelling checkers using an accepted dictionary is difficult. Different tools, different skills, different focus, etc. Needs to be easy and relatively fool-proof. Needs to use a standard, readily available tool, with a standard dictionary as a back end.

aspell has limitations, as does hunspell. Customization is a possibility.

Need to investigate possibilities, prototype, and roll out something that works, and make it part of the standard workflow.



Expected results:

There should be very few spelling mistakes in material received by technical editors. Currently, a lot of material has very basic errors, things that a simple scan or check would have found.

Additional info:
Comment 1 David O'Brien 2017-07-26 19:35:18 EDT
Latest update:

(See also http://etherpad.corp.redhat.com/GLS-global-spelling-checker for background information.)

On 07/26/2017 11:40 PM, Morgan Weetman wrote:
> Howdy,
>
> Apologies for the lateness of the update
>
> - Process to generate custom dictionaries in aspell working
yay
> - hyphen can be added as a valid word character, however, *all* hyphenated
> words would need to be added to the dictionary as aspell will no longer treat
> the individual parts on either side of the hyphen as whole words.
This is probably not an issue? Hyphenation is difficult, and people get
it wrong all the time. The rules are vague and hard to find. I'd be
happier adding known accepted hyphenation than letting incorrect
hyphenations live in the dictionary.

> - Couldn't get aspell to accept words with numbers like SHA-1

No suggestions atm... Ask google? 
>
> So progress but not perfection as yet
>
cool. I'm starting right now to look at words that don't belong in the
dictionary, etc. Will get back to you.

David
Comment 2 David O'Brien 2017-07-26 21:35:49 EDT
A few example words to not include. These are surprisingly hard to find.

plugin
datatype
e.g.
i.e.
Comment 3 David O'Brien 2017-07-27 02:44:23 EDT
Currently testing process to d/l default dictionary files, import, and configure.
Comment 4 David O'Brien 2017-09-06 23:28:33 EDT
d/l, configure, etc., works ok.

More testing "live" to weed out words that don't belong and ensure only valid suggestions are made.
Comment 5 David O'Brien 2017-10-31 18:22:40 EDT
Currently in testing with curric-devel.

Dave, I've assigned you QA because you're pretty new to this sort of thing. Please yell about any issues.

Production repo now established:
https://github.com/RedHatTraining/spellr
Comment 6 David O'Brien 2017-11-15 18:04:26 EST
Configuration updated to allow for words with numbers (e.g., 3scale).

Personal dictionaries disabled (set to /dev/null).

Process for adding words = raise PR or email David or Morgan.
Comment 7 David O'Brien 2018-01-02 18:22:51 EST
This has been tested, is classified as "works", and is in production. Being brand new, it's bound to have a few wrinkles but for the most part, it's fine.

Note You need to log in before you can comment on or make changes to this bug.