Wiki: various grammar and spelling fixes

Author: jrfnl

wiki/About-Standards-for-PHP_CodeSniffer.md

@@ -26,14 +26,14 @@ The typical differences between project-specific rulesets and standards are:
 | Will automatically be used when no standard is provided on the command line ? | Yes                      | No                             |
 | Can have custom sniffs ?                                                      | No                       | Yes                            |
 | Can be installed ?                                                            | No                       | Yes                            |
-| Reusability by other projects ?                                               | Limited                  | Yes                            |
+| Re-usability by other projects ?                                              | Limited                  | Yes                            |
 
-For optimal reusability, it is in most cases a good idea for a standard to be in its own repository and to be maintained as a separate project.
+For optimal re-usability, it is in most cases a good idea for a standard to be in its own repository and to be maintained as a separate project.
 
 A `[.]phpcs.xml[.dist]` file and a `ruleset.xml` file can largely contain the same type of directives.
 The [Annotated ruleset](https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki/Annotated-Ruleset) page contains information on all the directives you can use.
 
-Keep in mind that for a _standard_ to be optimally reusable, it should not contain project specific information, such as `<file>` directives or `<exclude-patterns>`, while a project specific `[.]phpcs.xml[.dist]` ruleset file _can_ contain that information.
+Keep in mind that for a _standard_ to be optimally re-usable, it should not contain project specific information, such as `<file>` directives or `<exclude-patterns>`, while a project specific `[.]phpcs.xml[.dist]` ruleset file _can_ contain that information.
 
 You may also find the [Customisable Sniff Properties](https://github.com/PHPCSStandards/PHP_CodeSniffer/wiki/Customisable-Sniff-Properties) page a handy reference for customisations which can be made to PHP_CodeSniffer native sniffs.
 
@@ -245,7 +245,7 @@ use PHP_CodeSniffer\Sniffs\Sniff;
 class OperatorSpacingSniff implements Sniff {...}
 ```
 
-:x: Not following the required directory structure (missing `[CategoryName]` subdirectory):
+:x: Not following the required directory structure (missing `[CategoryName]` sub-directory):
 ```php
 <?php
 // File: MyStandard/Sniffs/OperatorSpacingSniff.php

wiki/Advanced-Usage.md

@@ -242,10 +242,10 @@ $ phpcs --encoding=windows-1251 /path/to/code
 
 ## Using a Bootstrap File
 
-PHP_CodeSniffer can optionally include one or more custom bootstrap files before beginning the run. Bootstrap files are included after command line arguments and rulesets have been parsed, and right before files begin to process. These custom files may be used to perform such taks as manipulating the internal settings of PHP_CodeSniffer that are not exposed through command line arguments. Multiple bootstrap files are seperated by commas.
+PHP_CodeSniffer can optionally include one or more custom bootstrap files before beginning the run. Bootstrap files are included after command line arguments and rulesets have been parsed, and right before files begin to process. These custom files may be used to perform such tasks as manipulating the internal settings of PHP_CodeSniffer that are not exposed through command line arguments. Multiple bootstrap files are separated by commas.
 
 ```bash
-$ phpcs --bootstrap=/path/to/boostrap.1.inc,/path/to/bootstrap.2.inc /path/to/code
+$ phpcs --bootstrap=/path/to/bootstrap.1.inc,/path/to/bootstrap.2.inc /path/to/code
 ```
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
@@ -334,13 +334,13 @@ Array
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
 
-## Printing Verbose Tokeniser Output
+## Printing Verbose Tokenizer Output
 
 This feature is provided for debugging purposes only. Using this feature will dramatically increase screen output and script running time.
 
-PHP_CodeSniffer contains multiple verbosity levels. Level 2 (indicated by the command line argument `-vv`) will print all verbosity information for level 1 (file specific token and line counts with running times) as well as verbose tokeniser output.
+PHP_CodeSniffer contains multiple verbosity levels. Level 2 (indicated by the command line argument `-vv`) will print all verbosity information for level 1 (file specific token and line counts with running times) as well as verbose tokenizer output.
 
-The output of the PHP_CodeSniffer tokeniser shows the step-by-step creation of the scope map and the level map.
+The output of the PHP_CodeSniffer tokenizer shows the step-by-step creation of the scope map and the level map.
 
 ### The Scope Map
 
@@ -439,7 +439,7 @@ The level map is most commonly used to determine indentation rules (e.g., a toke
 
 This feature is provided for debugging purposes only. Using this feature will dramatically increase screen output and script running time.
 
-PHP_CodeSniffer contains multiple verbosity levels. Level 3 (indicated by the command line argument `-vvv`) will print all verbosity information for level 1 (file specific token and line counts with running times), level 2 (tokeniser output) as well as token processing output with sniff running times.
+PHP_CodeSniffer contains multiple verbosity levels. Level 3 (indicated by the command line argument `-vvv`) will print all verbosity information for level 1 (file specific token and line counts with running times), level 2 (tokenizer output) as well as token processing output with sniff running times.
 
 The token processing output is best explained with an example. For the following file:
 

wiki/Coding-Standard-Tutorial.md

@@ -128,7 +128,7 @@ final class DisallowHashCommentsSniff implements Sniff
 }
 ```
 
-By default, PHP_CodeSniffer assumes all sniffs are designed to check PHP code only. You can specify a list of tokenizers that your sniff supports, allowing it to be used wth PHP, JavaScript or CSS files, or any combination of the three. You do this by setting the `$supportedTokenizers` property in your sniff. Adding the following code to your sniff will tell PHP_CodeSniffer that it can be used to check both PHP and JavaScript code:
+By default, PHP_CodeSniffer assumes all sniffs are designed to check PHP code only. You can specify a list of tokenizers that your sniff supports, allowing it to be used with PHP, JavaScript or CSS files, or any combination of the three. You do this by setting the `$supportedTokenizers` property in your sniff. Adding the following code to your sniff will tell PHP_CodeSniffer that it can be used to check both PHP and JavaScript code:
 
 ```php
 /**

wiki/Configuration-Options.md

@@ -218,8 +218,8 @@ $ phpcs --config-set ignore_warnings_on_exit 1
 
 ## Ignoring non-auto-fixable issues when generating the exit code (PHP_CodeSniffer >= 4.0.0)
 
-By default, PHP_CodeSniffer will exit with a non-zero code if any errors or warnings are found, whethere these are auto-fixable or not.
-If you want to display non-autofixable errors and warnings to the user, but still return with a zero exit code if non-auto-fixable issues are found, you can set the `ignore_non_auto_fixable_on_exit` configuration option.
+By default, PHP_CodeSniffer will exit with a non-zero code if any errors or warnings are found, whether these are auto-fixable or not.
+If you want to display non-auto-fixable errors and warnings to the user, but still return with a zero exit code if non-auto-fixable issues are found, you can set the `ignore_non_auto_fixable_on_exit` configuration option.
 This option is typically used by automated build tools so that a `phpcbf` run can exit with `0` if it fixed all fixable issues, but there are still some non-auto-fixable issues remaining.
 
 ```bash

wiki/Customisable-Sniff-Properties.md

@@ -911,7 +911,7 @@ $rootNode
         ->end()
     ->end();
 ```
-If you want to allow mutli-level indenting, set the `multilevel` property to `true`. This will allow each line to be indented 1 more or 1 less level than the previous line, while still ensuring that all lines are indented at least once.
+If you want to allow multi-level indenting, set the `multilevel` property to `true`. This will allow each line to be indented 1 more or 1 less level than the previous line, while still ensuring that all lines are indented at least once.
 
 ```xml
 <rule ref="PEAR.WhiteSpace.ObjectOperatorIndent">

wiki/Reporting.md

@@ -333,14 +333,14 @@ patching file /path/to/code/file.php
 ```
 
 > [!NOTE]
-> The `*nix` `diff` command is required for generating reports in `diff` format. Windows users may need to ensure that the `diff` command is available by either installing [DiffUtils](http://gnuwin32.sourceforge.net/packages/diffutils.htm) or, if available, adding the Git `/usr/bin/` subdirectory to the Windows system `PATH`.
+> The `*nix` `diff` command is required for generating reports in `diff` format. Windows users may need to ensure that the `diff` command is available by either installing [DiffUtils](http://gnuwin32.sourceforge.net/packages/diffutils.htm) or, if available, adding the Git `/usr/bin/` sub-directory to the Windows system `PATH`.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
 
 ## Printing an Emacs Report
 
-PHP_CodeSniffer can output a report in a format the compiler built into the GNU Emacs text editor can understand. This lets you use the built-in complier to run PHP_CodeSniffer on a file you are editing and navigate between errors and warnings within the file. To print an Emacs report, use the `--report=emacs` command line argument. The output will look like this:
+PHP_CodeSniffer can output a report in a format the compiler built into the GNU Emacs text editor can understand. This lets you use the built-in compiler to run PHP_CodeSniffer on a file you are editing and navigate between errors and warnings within the file. To print an Emacs report, use the `--report=emacs` command line argument. The output will look like this:
 
 ```bash
 $ phpcs --report=emacs /path/to/code
@@ -368,7 +368,7 @@ Now you can use the compile command and associated shortcuts to move between err
 
 ## Printing a Git Blame Report
 
-PHP_CodeSniffer can make use of the `git blame` command to try and determine who committed each error and warning to a Git respository. To print a Git Blame report, use the `--report=gitblame` command line argument. The output will look like this:
+PHP_CodeSniffer can make use of the `git blame` command to try and determine who committed each error and warning to a Git repository. To print a Git Blame report, use the `--report=gitblame` command line argument. The output will look like this:
 
 ```bash
 $ phpcs --report=gitblame /path/to/code
@@ -556,7 +556,7 @@ PHP_CodeSniffer can output a sniff performance report showing you which sniffs i
 When the `--colors` option is enabled, sniffs which take more than twice the average run time per sniff will be displayed in orange and sniffs with a cumulative listener run time of more than three times the average run time per sniff will display in red.
 
 > [!NOTE]
-> The Performance report will only be useful when run without using the cache as otherwise the cache functionality will interfer with accurately measuring the runtime of sniffs.
+> The Performance report will only be useful when run without using the cache as otherwise the cache functionality will interfere with accurately measuring the runtime of sniffs.
 > So make sure to always use the `--no-cache` feature when running Performance reports.
 
 > [!NOTE]

wiki/Version-3.0-Upgrade-Guide.md

@@ -280,7 +280,7 @@ public function generate(
 
 ### Supporting Concurrency
 
-PHP_CodeSniffer version 3 supports processing multiple files concurrently, so reports can no longer rely on getting file results one at a time. Reports that used to write to local member vars can no longer do so as multiple forks of the PHP_CodeSniffer process will all be writing to a different instance of the report class at the same time and these cache values will never be merged. Instead, reports need to output their cached data directly. They will later be given a chance to read in the entire cached output and generate a final clean report.
+PHP_CodeSniffer version 3 supports processing multiple files concurrently, so reports can no longer rely on getting file results one at a time. Reports that used to write to local member variables can no longer do so as multiple forks of the PHP_CodeSniffer process will all be writing to a different instance of the report class at the same time and these cache values will never be merged. Instead, reports need to output their cached data directly. They will later be given a chance to read in the entire cached output and generate a final clean report.
 
 > [!NOTE]
 > Reports that output content in a way where the order or formatting is not important do not need to worry about caching data and can continue to produce reports they way they do now. Examples of these reports include the CSV report and the XML report.

wiki/Version-4.0-Developer-Upgrade-Guide.md

@@ -24,7 +24,7 @@ There is a separate [[Upgrade Guide for Ruleset Maintainers and End-Users|Versio
 It is highly recommended to upgrade external standards and integrations as soon as you are able.
 
 Once PHP_CodeSniffer 4.0 has been released, the PHP_CodeSniffer 3.x branch will no longer receive updates, with the exception of security fixes and runtime compatibility fixes for new PHP versions.
-This "limited support" will last a maximum of one year from the date of the PHP_Codesniffer 4.0.0 release.
+This "limited support" will last a maximum of one year from the date of the PHP_CodeSniffer 4.0.0 release.
 
 > [!IMPORTANT]
 > This also means that support for new PHP syntaxes will only land in PHP_CodeSniffer 4.x and will **NOT** be backported to the 3.x branch.
@@ -36,9 +36,9 @@ There are basically two upgrade strategies:
 1. Drop support for PHP_CodeSniffer 3.x completely and adopt support for PHP_CodeSniffer 4.x.
 2. Make your package cross-version compatible with both PHP_CodeSniffer 3.x as well as 4.x.
 
-Which strategy is best suited for your project will depend on your userbase.
+Which strategy is best suited for your project will depend on your user-base.
 
-If your userbase is known to often combine multiple external standards, making the package PHPCS cross-version compatible may be preferred to allow users to upgrade as soon as possible, while still benefitting from updates to your package if they can't upgrade to PHPCS 4.x yet.
+If your user-base is known to often combine multiple external standards, making the package PHPCS cross-version compatible may be preferred to allow users to upgrade as soon as possible, while still benefiting from updates to your package if they can't upgrade to PHPCS 4.x yet.
 
 The vast majority of the below upgrade tasks will need to be executed in both cases, but there are some upgrade tasks which can only be executed once support for PHP_CodeSniffer 3.x is being dropped.
 
@@ -276,7 +276,7 @@ The following tokens have been removed:
 
 If these tokens are used in PHP-only sniffs, they can be safely removed.
 If these tokens are used in JS/CSS only sniffs, as mentioned in ["Support for JS/CSS has been removed"](#support-for-jscss-has-been-removed): deprecate or remove the sniff.
-If these tokens are used in mixed sniffs, which also scan PHP files, remove the CSS/JS specific code or, for cross-version compatibility, check for the existance of the tokens before using them.
+If these tokens are used in mixed sniffs, which also scan PHP files, remove the CSS/JS specific code or, for cross-version compatibility, check for the existence of the tokens before using them.
 
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 

wiki/Version-4.0-User-Upgrade-Guide.md

@@ -20,7 +20,7 @@ There is a separate [[Upgrade Guide for Sniff Developers and Integrators|Version
 It is highly recommended to upgrade as soon as you are able.
 
 The PHP_CodeSniffer 3.x branch will no longer receive updates, with the exception of security fixes and runtime compatibility fixes for new PHP versions.
-This "limited support" will last a maximum of one year from the date of the PHP_Codesniffer 4.0.0 release.
+This "limited support" will last a maximum of one year from the date of the PHP_CodeSniffer 4.0.0 release.
 
 ### External Standards
 
@@ -284,7 +284,7 @@ CI scripts or git pre-commit hooks may be checking explicitly for specific exit
 <p align="right"><a href="#table-of-contents">back to top</a></p>
 
 
-### [Upcoming] Branch rename in the PHP_CodeSniffer repo
+### [Upcoming] Branch rename in the PHP_CodeSniffer repository
 
 Just before the final 4.0.0 release, the PHP_CodeSniffer `master` branch will be renamed to `3.x` and the default branch will change to `4.x`.
 
@@ -306,7 +306,7 @@ Example changeset:
 
 Relative file references like `xsi:noNamespaceSchemaLocation="./vendor/squizlabs/php_codesniffer/phpcs.xsd"` will continue to be valid.
 
-##### Referencing the main branches in the repo
+##### Referencing the main branches in the repository
 
 If you reference a development version of PHP_CodeSniffer in your `composer.json` file or in CI scripts, those references will need to be updated.
 What to update these to, depends on your use-case.