From a139ff61e125c7bc43fc9fc13171281f6d4cfc12 Mon Sep 17 00:00:00 2001 From: jrfnl Date: Mon, 23 Jun 2025 20:47:07 +0200 Subject: [PATCH 1/2] GH Actions: add spellcheck I was having a play with adding a spellchecker to the WPCS repo and when doing so, realized that some of the flagged texts - particularly in the WPCS-Core `ruleset.xml` file - are coming from this repo, so should probably be fixed here first. So, this commit add a basic workflow with a spellcheck job. Notes: * The "Typos" tool is known for having a low false positive ratio and being aware of code contexts. However, this also means, it may at times miss some things. When selecting it, I deemed the low false positive ratio more important. * The language has been set to `en-US` as that's the language predominantly used for the WordPress documentation. This does mean that various phrases using `en-GB` spelling will need to be fixed/updated. * I've named the workflow file `qa.yml` with a workflow name of "Basic QA checks", even though there is only one check in the file at this time. The idea behind this is that we may potentially want to add some markdown check tooling at some point and this way, that could go into the same workflow. Ref: https://github.com/crate-ci/typos --- .github/workflows/qa.yml | 26 ++++++++++++++++++++++++++ _typos.toml | 6 ++++++ 2 files changed, 32 insertions(+) create mode 100644 .github/workflows/qa.yml create mode 100644 _typos.toml diff --git a/.github/workflows/qa.yml b/.github/workflows/qa.yml new file mode 100644 index 0000000..dc8f55c --- /dev/null +++ b/.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" diff --git a/_typos.toml b/_typos.toml new file mode 100644 index 0000000..200f429 --- /dev/null +++ b/_typos.toml @@ -0,0 +1,6 @@ +[files] +ignore-hidden = true + +[default] +locale = "en-us" +check-filename = true From d30321078a8bf7480d15e82d2f9796656cf585fd Mon Sep 17 00:00:00 2001 From: jrfnl Date: Mon, 23 Jun 2025 20:50:17 +0200 Subject: [PATCH 2/2] Fix typos Mostly UK spelling vs US spelling. --- wordpress-coding-standards/css.md | 2 +- wordpress-coding-standards/javascript.md | 2 +- wordpress-coding-standards/php.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/wordpress-coding-standards/css.md b/wordpress-coding-standards/css.md index 7ce2e2c..1d2a592 100644 --- a/wordpress-coding-standards/css.md +++ b/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. diff --git a/wordpress-coding-standards/javascript.md b/wordpress-coding-standards/javascript.md index 42b28fc..cf9aabc 100644 --- a/wordpress-coding-standards/javascript.md +++ b/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 diff --git a/wordpress-coding-standards/php.md b/wordpress-coding-standards/php.md index 5c821a9..9732440 100644 --- a/wordpress-coding-standards/php.md +++ b/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: