Can spell checked words be stored in the document so they are not rechecked by other users?

English
,
#1

I have a document with a lot of custom entries, such as email addresses, and technical words. I can do a spell check, and add them all to my dictionary, so they are not underlined in red and making the text hard to read. I keep this underline in red functionality always on, as do most of my colleagues, and want to keep it on.

However, when I share the document with others to get their edits and additions, they will all have to do the spell check all again, doing a laborious recheck of the spelling and adding the same words to their dictionaries, to avoid the red lines making the document quite hard to read.

Is there some way to store any words I add to my dictionary attached to the document, kind of a document level dictionary, so everyone I share it with will not have to take the considerable time to respell check it and add all these words to their dictionaries on their computers?

1 Like
#2

Marking those words as with language ‘none’, I think, could do the trick. But it needs to be done for every word, even when repeated.

3 Likes
#3

Or you can add those words in the spell check extension.

  1. Download the extension file and unzip.

Make sure that you can see en_GB.txt file

  1. If you right click and add the words to the dictionary, they are collected in a text file.

If you are using Windows:
a) Goto start – run and type %APPDATA%
b) Navigate to \LibreOffice\4\user\wordbook and copy words from standard.txt

If you are using Ubuntu:
a) cd /home/ubuntu/.config/libreoffice/4/user/wordbook/
b) copy words from standard.dic

  1. You can paste those words in en_GB.txt file. You will need to sort and update the line number count mentioned in the first line. (for e.g. 97277)

  2. zip the file and make it available as an extension. Your users can remove all those red underlines just by changing the language from english_US to english_UK

#4

Thanks @shantanuo . That solves it for me. But my main problem is sharing with other users, so they don’t have to deal with the same thing.

I will mark the words with “no language” as @mariosv suggests. Not a great solution, but the best available. It would be nice if each document contained it’s own “document level dictionary”, with words that could be added just for that document, and then carried with the document when you email it to others. But I understand that would require a feature update.

#5

If a font can be “embedded” within a document, why not a dictionary? This seems like a valuable feature request. I encourage you to submit it on bugs.documentfoundation.org

1 Like
#7

See tdf#157981

#8

This is a path to infinite flexibility.
Why? Because these are two completely different things.

  • Embedding fonts aims at the document looking exactly as it was authored. For the software that is about creation of documents, anything helping to keep the resulting document look is reasonable.

  • Spell check (and its marks) is not the part of the document (or anything affecting its look / layout). It is just an aid for the author to catch some mistakes. Embedding a dictionary means embedding a tool. This is like asking to embed the whole LibreOffice inside the document.

By the way, what could really be reasonable, is embedding the hyphenation dictionary. Why? Because the hyphenation dictionary plays role in the layout of the document; so missing (or different) hyphenation dictionary can change the look of the document on the destination system - just like missing font.

That is about exporting dictionaries for profile migration, not as part of the document; and I agree with @cwolan, that that would be the reasonable way of solving a task of a group working on the same document(s), using some non-standard set of words. Share the dictionary as a separate file, and use it wherever needed…

#9

Hi,
.
It could be interesting to have an extension able to create an extension from any dictionary on the workstation. This could help sharing with others.
.
My 2 (euro-)cents.

#10

Hi @mikekaganski , you say “infinite flexibility” like it’s a bad thing :wink:
.
I think this is very appropriate functionality. The use case is when there are many words used in a document that are not in any typical dictionary. For example, in my case, there are two classes of words that are marked in red as being misspelled: (a) many technical words such as database fields like “RenewalEligibilityDate”, and (b) many people’s names, like “Kaganski” and “Wolański” and “Shantanuo”.
.
None of these are actually misspelled. When I share the document with others, they open it up, and it is in some places almost unreadable, because of all the red underlines. Every single person either has to put them all in their local dictionary. Or I have to mark them, one by one and repeated use by repeated use, as having language “none”.
.
A better approach would be during the spell check, the first time a word is found, to click a button “Add to local document dictionary”. Then that dictionary, usually less than 1KB in size, travels with the document. And then none of the many people I send it to will have to deal with “misspelled” words that are actually not really misspelled at all.

#11

It definitely is. Not only this is a burden for developers and QA; not only it makes it progressively impossible to test ever increasing state of options; it also creates problems for users. And not even in the increasing complexity of features.

and what you propose is an example of what I’m talking about. People getting your document, where you mistakenly mis-clicked “Add to local document dictionary” on, say, “missspelled”, would be very surprised seeing their spell check broken. Generally, trusting someone’s judgements on what is a spelling error, and what is not, is rather risky. A managed dictionary, which you can update, file a bug report, disable - is one thing. Getting infinite number of “helper” dictionaries from unexpected people in unexpected places is not so nice.

If users open your document, and see many underlined words, they would just turn off the automatic spell check. If they co-edit it, they would just mark what they need, once, themselves.

#12

Well, I guess it depends on the work you do. If you worked, as I do, with documents with many technical words, and content with many names in them, you would be more likely to see how the current mode of operation is very frustrating, and the functionality I propose would be a god send.

#13

:slight_smile: Having an experience in participating in creation of a national standard in an area of heating systems, I guess I know what you are talking about. That doesn’t change my PoV.

#14

Currently, for each ignored word, redundant code such as fo:language=“none” and fo:country=“none” is added. An alternative approach could involve declaring at the beginning of the source code that the words listed in an attached text file are exempt from spell checking for the entire document. This would provide a more efficient solution.

Novice users can continue using the method suggested by mariosv (marking those words with the language set to ‘none’), while power users would have the additional option to edit the source code directly for more advanced customization. For e.g. to solve the USA / UK dictionary mismatch. Dictionary is very limited

#15

“Dictionary is very limited” is a reason for users to contribute to improving it, not to create workarounds.

#16

Hi Mike, opposing this idea because you don’t want the developers to have the complication is a legitimate point of view. But so the pov of the users, for whom the software exists.
.
Many times over the years I have had documents with many words not in the dictionary, such as technical words and international people names, and the readability was very difficult. Turning off real time spell check is of course a bad solution. And adding all these to my global dictionary, usually not needed for other documents, is also not a good solution. Adding these to the default Writer dictionaries is a terrible idea.
.
And the key insight I am trying to share is that the difficulty is compounded many times over when you work with these kinds of documents in a collaborative fashion with other people. Now they have a dozen, several dozen, a hundred, maybe two hundred words that show up as misspelled, making the document, in places, almost unreadable. But these words are not misspelled at all.
.
The workaround of me marking each of these words individually as language none is the best available workaround. But it is more work that it needs to be, because I have to do it for every single occurrence of the word, which could multiply the work several times over. And I’m always worried that during editing I extended the area of the document marked language none to include text that I do want spell checked.
.
As a former programmer that has written ~80K lines of code, I believe the suggestion I suggest is not only of great user value, it is elegant and easy to code. Every document has a document level dictionary. Another button on the Spell check dialogue like “Add to local dictionary”. Each spell check checks both the currently selected dictionary, and the local dictionary. At the top level, we are talking a very small number of lines of code. For really large value for any Writer user that works with many technical words, or people’s names, in a collaborative fashion with others.
.
Anyway, imho, fwiw.

#17

I never oppose ideas “because I don’t want the developers to have the complication”, if that’s the only reason. I provided the rationale behind my position, from user PoV. So please don’t put words into my mouth, that I didn’t say.

The last piece that I mentioned, about “contributing to dictionary improvement”, was also driven by that. Increasing workarounds is not a good UX. Fixing a small bit in a dictionary used by millions is much better than creating a workaround for its deficiencies.

And again: having something like this in the software is basically a way for some people to disguise something in the written text, by adding those things to the document-local dictionaries, a bit resembling CVE-2021-42694. Basically, this is a nice-looking idea proposed with best intentions, without really thinking about implications.

#18

Getting users to contribute could take years (if not decades). A workaround sounds like a good idea if it’s technically possible.

#6

Maybe check also the following thread on user-defined dictionaries. They are not shared with the document, you would need to do this as an additional task (and your colleagues have to know where to find them):

If you prefer to have the words in the usual dictionaries, you may create a list of words to be added to the dictionary directly, as described here:

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.