Merge pull request #151 from WordPress/feature/ghactions-add-spellcheck

GH Actions: add spellcheck + fix a few typos

Author: jrfnl

.github/workflows/qa.yml

@@ -0,0 +1,26 @@
+name: Basic QA checks
+
+on:
+  push:
+  pull_request:
+  # Allow manually triggering the workflow.
+  workflow_dispatch:
+
+# Cancels all previous workflow runs for the same branch that have not yet completed.
+concurrency:
+  # The concurrency group contains the workflow name and the branch name.
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  typos-spellcheck:
+    name: "Find typos"
+
+    runs-on: "ubuntu-latest"
+
+    steps:
+      - name: "Checkout"
+        uses: "actions/checkout@v4"
+
+      - name: "Search for misspellings"
+        uses: "crate-ci/typos@v1"

_typos.toml

@@ -0,0 +1,6 @@
+[files]
+ignore-hidden = true
+
+[default]
+locale = "en-us"
+check-filename = true

wordpress-coding-standards/css.md

@@ -36,7 +36,7 @@ Incorrect:
 
 ## Selectors
 
-With specificity, comes great responsibility. Broad selectors allow us to be efficient, yet can have adverse consequences if not tested. Location-specific selectors can save us time, but will quickly lead to a cluttered stylesheet. Exercise your best judgement to create selectors that find the right balance between contributing to the overall style and layout of the DOM.
+With specificity, comes great responsibility. Broad selectors allow us to be efficient, yet can have adverse consequences if not tested. Location-specific selectors can save us time, but will quickly lead to a cluttered stylesheet. Exercise your best judgment to create selectors that find the right balance between contributing to the overall style and layout of the DOM.
 
 - Similar to the [WordPress PHP Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#naming-conventions) for file names, use lowercase and separate words with hyphens when naming selectors. Avoid camelcase and underscores.
 - Use human readable selectors that describe what element(s) they style.

wordpress-coding-standards/javascript.md

@@ -337,7 +337,7 @@ All [`@wordpress/element`](https://www.npmjs.com/package/@wordpress/element) Com
 
 An exception to camel case is made for constant values which are never intended to be reassigned or mutated. Such variables must use the [SCREAMING_SNAKE_CASE convention](https://en.wikipedia.org/wiki/Snake_case#History).
 
-In almost all cases, a constant should be defined in the top-most scope of a file. It is important to note that [JavaScript’s `const` assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const) is conceptually more limited than what is implied here, where a value assigned by `const` in JavaScript can in-fact be mutated, and is only protected against reassignment. A constant as defined in these coding guidelines applies only to values which are expected to never change, and is a strategy for developers to communicate intent moreso than it is a technical restriction.
+In almost all cases, a constant should be defined in the top-most scope of a file. It is important to note that [JavaScript’s `const` assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const) is conceptually more limited than what is implied here, where a value assigned by `const` in JavaScript can in-fact be mutated, and is only protected against reassignment. A constant as defined in these coding guidelines applies only to values which are expected to never change, and is a strategy for developers to communicate intent, more than it is a technical restriction.
 
 ## Comments
 

wordpress-coding-standards/php.md

@@ -831,7 +831,7 @@ While this operator does exist in Core, it is often used lazily instead of doing
 
 ### Increment/decrement operators
 
-Pre-increment/decrement should be favoured over post-increment/decrement for stand-alone statements.
+Pre-increment/decrement should be favored over post-increment/decrement for stand-alone statements.
 
 Pre-increment/decrement will increment/decrement and then return, while post-increment/decrement will return and then increment/decrement.
 Using the "pre" version is slightly more performant and can prevent future bugs when code gets moved around.
@@ -934,7 +934,7 @@ if ( ! isset( $var ) ) {
 }
 ```
 
-Unless absolutely necessary, loose comparisons should not be used, as their behaviour can be misleading.
+Unless absolutely necessary, loose comparisons should not be used, as their behavior can be misleading.
 
 Correct: