-
Notifications
You must be signed in to change notification settings - Fork 22.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add US English spell checker/linter for markdown #12522
Comments
FYI, here are the config files I've been using with cspell to look at the diffs on the custom dictionary to find new misspellings https://gist.github.com/nschonni/4d271853c2af1612bcf9f5c739620ce5 |
We may consider checking in a project dictionary under In my experience, content is looking okay (not overwhelmed with errors) with config dictionaries like this when working on PRs that edit a few markdown files only: {
"$schema": "https://raw.githubusercontent.com/streetsidesoftware/cspell/main/cspell.schema.json",
"version": "0.2",
"language": "en-US",
"languageId": "*",
"dictionaries": [
"bash",
"css",
"cpp",
"django",
"filetypes",
"fonts",
"fullstack",
"html",
"latex",
"lorem-ipsum",
"markdown",
"node",
"npm",
"project-words",
"python",
"softwareTerms",
"svelte",
"typescript"
],
"ignorePaths": [
".vscode/cspell.json",
".vscode/extensions.json",
".markdownlint-cli2.jsonc"
],
"allowCompoundWords": true,
"dictionaryDefinitions": [
{
"name": "project-words",
"path": "./project-words.txt",
"addWords": true
}
]
} If we extend using the ignorelist from @nschonni, I think we're in a good place. |
I believe there is/was a performance difference with a large custom dictionary inside the config file vs the external TXT |
I normally use |
I see, so having a large external text file ( |
No, I believe the external txt is more performant, as it gets compiled once, where the JSON file gets repeatedly parsed, so smaller is better for that file |
Very good, I'm all for trying this out in parallel with our usual day-to-day and evaluating how it fits into our workflow after some time. |
Minor update that the config is checked for local use: |
I've gathered 5424 word list for this repo so far. If you wish we can merge this or use personally in local environment. Here is the config I used: https://github.com/OnkarRuikar/temp/blob/main/cspell.json. I think we can start using cspell in our automations. |
Is everyone onboard with doing this in CI? Do we need a discussion? |
We can't fail a PR if someone adds a new acronym(like HDCP) or uses a word like unzoomed. We can make it a nightly/weekly check and file an issue if new/wrong words are found. |
Sure, that also sounds fine to me, like how you are regularly sending typo-fix PRs. |
I can simply move the automation from my temp repo to |
I've been using this action on different repositories and it's been quite good, something to consider: jobs:
spellcheck:
name: "Check spelling"
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: streetsidesoftware/cspell-action@v6
with:
inline: error
config: ".vscode/cspell.json"
verbose: true
# Limit the files checked to the ones in the pull request or push.
incremental_files_only: true |
Could you share an example of it catching errors? How does it handle new words? |
It leaves annotations for spelling errors on the job, like:
All of the failure logs from this workflow are expired, so I don't have an example available, but I can recommend trying it out as there's a lot of configuration possible that we won't have to re-roll: https://github.com/streetsidesoftware/cspell-action |
We should have a US English spell checker.
#373 changed all know UK English spellings to US English, as per MDN policy. However this is likely to rot. As discussed in #10787 we should also have an automated spell checker system in place for English content.
The text was updated successfully, but these errors were encountered: