Browser's built-in spell-checker has *lots* of false positives in the flat text editor

Bug #1760940 reported by Jane Sandberg
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Won't Fix
Undecided
Unassigned

Bug Description

When I open the flat text editor of a MARC record, my browser underlines a bunch of stuff in red, including lots of things that aren't concerning (e.g. codes in the 33x$b, the first word of any subfield, etc.). For example, in Firefox, the following 264:

=264 \1$aWashington ;$aCovelo ;$aLondon :$bIsland Press,$c[2013]

"$aWashington", "$aCovelo", "$aLondon", and "$bIsland" all get underlined in red.

It looks like there's an HTML5 attribute called spellcheck that could be used to turn off spellchecking in Firefox, Chrome, and Safari: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/spellcheck

However, I don't know if we should turn it off, since it could be potentially useful to catalogers. What do other folks think?

Revision history for this message
Jane Sandberg (sandbergja) wrote :
Revision history for this message
Elaine Hardy (ehardy) wrote :

Personally, I only use the flat text editor if I am copying and pasting into a record and not when I am checking a record for errors. I see problems better in the default editor. So it doesn't matter either way to me.

Revision history for this message
Jane Sandberg (sandbergja) wrote :

I spoke with a colleague who uses the flat text editor extensively while cataloging. Her strong preference is to turn off spellchecking for that box.

In case we decide to go without spellcheck, I created a branch that does this (user/sandbergja/lp1760940_turn_of_spellcheck_for_flat_text_editor), link is here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp1760940_turn_off_spellcheck_for_flat_text_editor

Revision history for this message
Kathy Lussier (klussier) wrote :

It might be a good idea to send a message to the cataloging list to see if we can get more feedback from catalogers.

Revision history for this message
Galen Charlton (gmc) wrote :

This may be ultimately better spun off into a separate bug, but the browser spellchecker is active in the non-flat-text editor. Do folks have a preference about that as well? I could also envision more granularity, as it would be possible in the default editor to do things like that:

- turn off the spellcheck for fixed fields
- turn it off for fields that are linked to an authority record

And for both the flat text editor and the default editor, would it be useful to have a checkbox to toggle spellcheck?

Revision history for this message
Sarah Childs (sarahc) wrote :

If it would only be turned off for the flat text editor, I see no reason not to turn it off, since it's so annoying and almost worthless for that function.

If turning it off would also affect other functions (OG MARC editor), then I vote no.

Revision history for this message
Elaine Hardy (ehardy) wrote :

I would like the granularity of default off for the FF and for linked fields. The ability to toggle it on and off would also be helpful.

Revision history for this message
Jordan Woodard (jwoodard) wrote :

I have no issue with it being turned off, that being said it is easy for me to ignore when modifying records. My coworker made the comment that it is useful for catching spelling errors when typing descriptions in records. I am seeking opinions from other catalogers in my consortium and will pass along their comments.

Revision history for this message
Jane Sandberg (sandbergja) wrote :

From our Technical Services Coordinator: Having it turn off for specific MARC fields would be nice, there are some that would always look misspelled. The fields I'm mostly interested in spellchecking are 245, 500, 520, and 650's. Names are so hard, I don't know if spellchecking that would be helpful. The regular MARC editor would easier to spot misspellings in.

Revision history for this message
Janet Schrader (jschrader) wrote :

If the MARC workform had spell-check I'd find it useful. I also prefer the workform to the flat-text editor as it's easier to read. If it has to be available in both then I'd like a toggle for off/on and the granularity of turning it off for the fixed fields and linked fields.

Revision history for this message
Linh Uong (linhuong) wrote :

I don’t use the text editor very often since I do most of my editing in OCLC and overlay into EG. The few times I do use text (and flat) is when it’s punctuation or typo, and it takes longer to overlay into my ILS, so I’ll just fix it in OCLC and then fix it in the text editor. The only time it would be helpful is if I was scanning for typos, but then again, it is a lot of red if it’s catching all the delimiters & etc. I like the toggle option.

Revision history for this message
Bill Erickson (berick) wrote :

Sign-off for Jane's branch pushed:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1760940-marc-edit-spellcheck

As a reminder, this only addresses the flat-text editor.

I tried adding a toggle to enable and disable spellcheck in the flat-text editor, but the behavior was problematic. Enabling spellcheck would not do anything until the user interacted with the text in some way. Then turning it back off again did nothing, even with user action and even though the attribute value was correctly set on the textarea. It only really seems to work when the attribute is set on page load.

Because of this, I suggest we maintain consistency with the XUL client and simply disable it, at least until a better option is implemented.

Bill Erickson (berick)
Changed in evergreen:
status: New → Confirmed
tags: added: signedoff
Michele Morgan (mmorgan)
Changed in evergreen:
milestone: none → 3.6.2
Changed in evergreen:
milestone: 3.6.2 → 3.6.3
tags: added: pullrequest
Revision history for this message
Jane Sandberg (sandbergja) wrote :

This bug was for the AngularJS flat text editor. We're using the Angular one now (which does not use the browser's built-in spellchecking), so marking this one as Won't Fix.

Changed in evergreen:
status: Confirmed → Won't Fix
Changed in evergreen:
milestone: 3.6.3 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.