Docs: Fix typos

docs/contributors/release.md

@@ -188,17 +188,17 @@ If you don't have access to [make.wordpress.org/core](https://make.wordpress.org
 The Gutenberg repository mirrors the [WordPress SVN repository](https://make.wordpress.org/core/handbook/about/release-cycle/) in terms of branching for each SVN branch, a corresponding Gutenberg `wp/*` branch is created:
 
  - The `wp/trunk` branch contains all the packages that are published and used in the `trunk` branch of WordPress.
- - A Gutenberg branch targetting a specific WordPress major release (including its further minor increments) is created (example `wp/5.2`) based on the `wp/trunk` Gutenberg branch when the WordPress `trunk` branch is marked as "feature-freezed". (This usually happens when the first `beta` of the next WordPress major version is released).
+ - A Gutenberg branch targeting a specific WordPress major release (including its further minor increments) is created (example `wp/5.2`) based on the `wp/trunk` Gutenberg branch when the WordPress `trunk` branch is marked as "feature-freezed". (This usually happens when the first `beta` of the next WordPress major version is released).
 
 ### Synchronizing WordPress Trunk
 
 For each Gutenberg plugin release, WordPress trunk should be synchronized with this release. This involves the following steps:
 
 **Note:** The WordPress `trunk` branch can be closed or in "feature-freeze" mode. Usually, this happens between the first `beta` and the first `RC` of the WordPress release cycle. During this period, the Gutenberg plugin releases should not be synchronized with WordPress Core.
 
-1. Ensure the WordPress `trunk` branch is open for enhancements. 
+1. Ensure the WordPress `trunk` branch is open for enhancements.
 2. Check out the last published Gutenberg release branch `git checkout release/x.x`
-3. Create a Pull Request from this branch targetting `wp/trunk`.
+3. Create a Pull Request from this branch targeting `wp/trunk`.
 4. Merge the Pull Request using the "Rebase and Merge" button to keep the history of the commits.
 
 Now, the branch is ready to be used to publish the npm packages.
@@ -208,7 +208,7 @@ Now, the branch is ready to be used to publish the npm packages.
 3. Update the `CHANGELOG.md` files of the published packages with the new released versions and commit to the `wp/trunk` branch.
 4. Cherry-pick the "Publish" (created by Lerna) and the CHANGELOG update commits into the `master` branch of Gutenberg.
 
-Now, the npm packages should be ready and a patch can be created and commited into WordPress `trunk`.
+Now, the npm packages should be ready and a patch can be created and committed into WordPress `trunk`.
 
 
 ### Minor WordPress Releases
@@ -220,20 +220,20 @@ The following workflow is needed when bug fixes or security releases need to be
 
 1. Cherry-pick
 2. Check out the last published Gutenberg release branch `git checkout release/x.x`
-3. Create a Pull Request from this branch targetting the WordPress related major branch (Example `wp/5.2`).
+3. Create a Pull Request from this branch targeting the WordPress related major branch (Example `wp/5.2`).
 4. Merge the Pull Request using the "Rebase and Merge" button to keep the history of the commits.
 
 Now, the branch is ready to be used to publish the npm packages.
 
 1. Check out the WordPress branch used before (Example `wp/5.2`).
 2. Run the [package release process] but when asked for the version numbers to choose for each package, (assuming the package versions are written using this format `major.minor.patch`) make sure to bump only the `patch` version number. For example, if the last published package version for this WordPress branch was `5.6.0`, choose `5.6.1` as a version.
 
-**Note:** For WordPress `5.0` and WordPress `5.1`, a different release process was used. This means that when choosing npm package versions targetting these two releases, you won't be able to use the next `patch` version number as it may have been already used. You should use the "metadata" modifier for these. For example, if the last published package version for this WordPress branch was `5.6.1`, choose `5.6.1+patch.1` as a version.
+**Note:** For WordPress `5.0` and WordPress `5.1`, a different release process was used. This means that when choosing npm package versions targeting these two releases, you won't be able to use the next `patch` version number as it may have been already used. You should use the "metadata" modifier for these. For example, if the last published package version for this WordPress branch was `5.6.1`, choose `5.6.1+patch.1` as a version.
 
 3. Update the `CHANGELOG.md` files of the published packages with the new released versions and commit to the corresponding branch (Example `wp/5.2`).
 4. Cherry-pick the CHANGELOG update commits into the `master` branch of Gutenberg.
 
-Now, the npm packages should be ready and a patch can be created and commited into the corresponding WordPress SVN branch.
+Now, the npm packages should be ready and a patch can be created and committed into the corresponding WordPress SVN branch.
 
 ---------
 

docs/designers-developers/developers/tutorials/format-api/1-register-format.md

@@ -39,9 +39,9 @@ Then add a new file named `my-custom-format.js` with the following contents:
 } )( window.wp );
 ```
 
-Make that plugin available in your WordPress setup and activate it. Then, load a new page/post. 
+Make that plugin available in your WordPress setup and activate it. Then, load a new page/post.
 
-The list of available format types is maintained in the `core/rich-text` store. You can query the store to check that your custom format is now avaliable. To do so, run this code in your browser's console:
+The list of available format types is maintained in the `core/rich-text` store. You can query the store to check that your custom format is now available. To do so, run this code in your browser's console:
 
 	wp.data.select( 'core/rich-text' ).getFormatTypes();
 

docs/designers-developers/developers/tutorials/format-api/2-toolbar-button.md

@@ -1,6 +1,6 @@
 # Add a Button to the Toolbar
 
-Now that the format is avaible, the next step is to surface it to the UI. You can make use of the [`RichTextToolbarButton`](/packages/editor/src/components/rich-text/README.md#RichTextToolbarButton) component to extend the format toolbar.
+Now that the format is available, the next step is to surface it to the UI. You can make use of the [`RichTextToolbarButton`](/packages/editor/src/components/rich-text/README.md#RichTextToolbarButton) component to extend the format toolbar.
 
 Paste this code in `my-custom-format.js`:
 
@@ -68,7 +68,7 @@ The following sample code renders the previously shown button only on paragraph
 			return (
 				props.selectedBlock &&
 				props.selectedBlock.name === 'core/paragraph'
-			); 
+			);
 		} )
 	)( MyCustomButton );
 

docs/designers-developers/developers/tutorials/javascript/loading-javascript.md

@@ -30,7 +30,7 @@ If your code is registered and enqueued correctly, you should see a message in y
 
 ![Console Log Message Success](https://raw.githubusercontent.com/WordPress/gutenberg/master/docs/designers-developers/assets/js-tutorial-console-log-success.png)
 
-**Note for Theme Developers:**  The above method of enqueing is used for plugins. If you are extending the block editor for your theme there is a minor difference, you will use the `get_template_directory_uri()` function instead of `plugins_url()`. So for a theme, the enqueue example is:
+**Note for Theme Developers:**  The above method of enqueuing is used for plugins. If you are extending the block editor for your theme there is a minor difference, you will use the `get_template_directory_uri()` function instead of `plugins_url()`. So for a theme, the enqueue example is:
 
 ```php
 function myguten_enqueue() {

docs/designers-developers/developers/tutorials/javascript/scope-your-code.md

@@ -28,7 +28,7 @@ This behavior can be problematic, and is the reason we need to scope the code. B
 
 ## Scoping Code Within a Function
 
-In JavaScript, you can scope your code by writing it within a function. Functions have "local scope", or a scope that is specific only to that function. Aditionally, in JavaScript you can write anonymous functions, functions without a name, which will also prevent your function name from being overridden in the global scope.
+In JavaScript, you can scope your code by writing it within a function. Functions have "local scope", or a scope that is specific only to that function. Additionally, in JavaScript you can write anonymous functions, functions without a name, which will also prevent your function name from being overridden in the global scope.
 
 Taking advantage of these two JavaScript features, `first.js` could be scoped as: