Traditionally, rare spellings were included in unabridged or specialized print dictionaries but not in online spell-check dictionaries, because if the spelling was in a word-processed document then it was probably wrong. I'd like a more advanced feature: the ability to mark a spelling in a dictionary (including a presupplied dictionary) as rare and thus, perhaps by a tooltip if not by a different underlining, as one for the writer to confirm where it's being used. It's possible to do this now by placing rarities into a separate spell-check dictionary, for example a new one created only for specialized writing, and running two spell-checks, one with and one without the rarities dictionary, but that's cumbersome.
Meant to be with my original post: I'm told this version of LibreOffice is at the end of its life (EOL) but I've since gotten an automatic update to it with Fedora 20 Linux. However, if a newer version of LibreOfice has this, that's good enough. I don't want to parallel-install it if Fedora is not sending it. I've guessed my hardware.
Thanks for filing your enhancement request. CCing the UX-Advise team.
We're replacing our use of the 'ux-advise' component with a keyword: Component -> LibreOffice Add Keyword: needsUXEval [NinjaEdit]
The use case is to have project depending terms like 'Abble' where you normally want to write Apple. We do have a solution for that. You can create as many dictionaries you want. Go to Tools > Spelling and Grammar (F7) > Options... click New next to the list of user-defined dictionaries and add 'Project' and 'Private'. Now enter the 'Abble', right-click the underlined word and select 'Project.dic' in the submenu of 'Add to Dictionary'. The term will be accepted now as long the checkbox in the list of user-defined dictionaries is set. If your request goes beyond that inbuilt functionality, e.g. some kind of automatism, it's likely an extension.
No, that's the wrong use case. I'm not talking about erroneous spellings but about correct-but-rare spellings that probably don't belong in current contexts. In those cases, users should be asked to confirm that they intend to use the spelling that's present. Most of the time, they'll see it as an error and correct it, but, because the spelling is sometimes (rarely) correct, they'll sometimes want to leave it as is. I think this can be done by adding a Boolean (true/false) field to every entry in every dictionary. The default entry would be false (as in 'false spelling'). But if a user could supply a file of rare-but-correct spellings or could edit a single entry, the status of true would mean 'true spelling albeit rare'. That leaves how the UI should inform users of likely-misapplied rare spellings. An extension would seem appropriate for the UI once the rarities are recognizable but probably not to the necessary hooks in LibreOffice, especially the additional field. Since the hooks would need something in LO itself, I'm restoring this report's status.
(In reply to Nick Levinson from comment #5) > > I think this can be done by adding a Boolean (true/false) field to every > entry in every dictionary. The default entry would be false (as in 'false > spelling'). But if a user could supply a file of rare-but-correct spellings > or could edit a single entry, the status of true would mean 'true spelling > albeit rare'. > > That leaves how the UI should inform users of likely-misapplied rare > spellings. > > An extension would seem appropriate for the UI once the rarities are > recognizable but probably not to the necessary hooks in LibreOffice, > especially the additional field. Since the hooks would need something in LO > itself, I'm restoring this report's status. Way out of scope for the way our bundled dictionaries/thesaurus are produced and maintained. Have a look at the Hunspell, and Lightproof projects and restrictions on how word lists can be altered. The "User-defined dictionaries" model Heiko described provides framework for customized (individually or by some collaborative work group) lexical aids without imposing a non-maintainable data structure of alternates. Presently the LanguageTool.org project provided extension supports rules based checking--one can write their own for their custom dictionary needs. If the Grammarly project ever spins up an extension for AOO/LO that would be a treat for using its "context-optimized word choice" but again these are extensions and not something applicable to LibreOffice core, and hooks extension authors need for GUI interface are provided in the SDK.
(In reply to Nick Levinson from comment #5) > No, that's the wrong use case. 'Abble' in my example is a company and correct while I work on their products. Just give the user-defined dictionaries a try.
Thank you, both. @Heiko Tietze: No, but I think I see the problem. My use case is about rarities across general language, not rarities that become common within one specialty, such as a project. Consider that unabridged dictionaries (like Oxford Eng. Dict.) have more entries than a spell checker has, like floccinaucinihilipilification, because if someone types a rare word they're probably typing it by mistake and it's a misspelling in context, and users want misspellings flagged, so spell checkers usually omit rare words so they'll get flagged as misspellings. The specialty dictionaries, once a word is added, would always approve a spelling, so they're no help. Instead, what I'm proposing is for LO to notice that the spelling is rare in general writing and therefore unlikely because normally it would be an error but maybe it's not this time, so it asks the user. Maybe the given spelling is correct only one time out of forty times that it's used but is wrong all the other 39 times. That word in someone's essay should not be marked as wrong or left unmarked as right but instead should be announced as doubtful. (Example: A legal writer gave an essay to an assistant, who corrected "justiciable" to "justifiable" when the original was right and the correction was wrong. The original is rarely used even in law, which is why the assistant didn't recognize it.) This would help a secretary who is supposed to fix their boss's mistakes and would run mass replacement but should be stopped by LO when a rarity is encountered, with LO treating the encountered string as rare and questionable, not as right or wrong. If Abble is a computer term or name apart from Apple, I didn't find it in Google. If it's a misspelling, I'm not talking about pure misspellings. @V Stuart Foote: For Hunspell or Lightproof, this feature was not listed (<http://hunspell.github.io/>, <https://extensions.openoffice.org/en/project/lightproof-grammar-checker-development-framework>, or https://extensions.openoffice.org/project/lightproof). If grammar means syntax, Lightproof wouldn't be the vehicle for this feature. I tested https://languagetool.org/ with floccinaucinihilipilification (with the spelling confirmed in Google and which is in the Oxford English Dictionary (1st ed.)) but the word was simply marked as wrong whether American or British was selected. I also tested the sentence "I practice floccinaucinihilipilification once in a while." The result was the same. That's not what I propose, because "floccinaucinihilipilification" is a real but rare word and is not misspelled. If LanguageTool had the feature I propose, it would have asked me about the rarity in context. It didn't, so it doesn't. I couldn't try https://www.grammarly.com/ Native Apps option, which is only for Win or Apple (I have only Linux and *BSD), and, from what it says about the free version, this feature is not included, although it might be in the paid-for version. The Boolean field I proposed was not "a non-maintainable data structure of alternates". Entries can be maintained by users and others. Alternatives, if they're what you meant, do not have to be provided; if the user believes that a flagged word is an error in context, the user would replace it with whatever word they like, but this feature need not suggest alternative words. I wasn't thinking of a GUI (a hook would be needed for a CLI, too), but was assuming that a field would be a hook that an extension couldn't add by itself. If I'm wrong about that, so be it. You seem to know the internals better than I do, so I won't change the status.