Intended Way to Deal with Spellchecking

[p0fi]

Description

I find it very confusing to deal with the spellchecking customization. It's hard to understand the difference between vocabularies and dictionaries and ignores.

When should what be used?
What's the recommended approach when vale finds that any word is misspelled but it's really not.

Should I add it to a vocabulary? Create a Dictionary? Or should I use an ignore file? Would there be a different approach intended for different types of misspellings?

Examples

Physical Units

Vale flags some physical units as spelling errors:

• mAh (milliamp hours)
• MPa (mega pascal)
• GPa (giga pascal)

Computer Science Terms

• enum
• boolean
• hostname

General Words

• replaceability
• conformant

[jdkato]

Dictionaries are the recommended means of customizing spell checking. Ignore files are a less powerful option that predate support for dictionaries.

Vocabularies are terminology lists that apply to all extension points (not just spelling). They allow you to:

• Control usage of multi-word terms.
• Enforce capitalization (such as in "JavaScript").
• Disallow correctly spelled terms.
• Use regex in your entries.

---

I would say that all of your example words should go in a dictionary.

On the other hand, something like "Vale Studio" (a product name) belongs in a vocabulary.

[p0fi]

So what I should do is create a Hunspell dictionary for the missing words? Like some .dic and .aff in dicpath?

[p0fi]

Are there any compatible dictionaries out there which at least cover all the computer science words as well as the physical units? Those should be pretty standard use cases 🤔

[eskwayrd]

I found one here: https://github.com/smoeding/hunspell-jargon

Folks using Hunspell dictionaries often have to create their own for the domain-specific terminology they are using.

One of the most powerful features of Hunspell dictionaries is affix processing. But you don't have to create one from scratch. Find an existing Hunspell dictionary for your language and copy the existing .aff file for your new dictionary. For example, copy the en_US.aff to mydict.aff. Then, you can make the mydict.dic file with one term per line; the first line is a count of the terms in the dictionary. That makes it easy to maintain, and you can use the "standard" affix features as needed.