Docs: Fix typos (#46912)

docs/contributors/accessibility-testing.md

@@ -34,7 +34,7 @@ According to the [WebAIM: Screen Reader User Survey #8 Results](https://webaim.o
 | NVDA with Internet Explorer | 14               | 1.2%             |
 | Other combinations          | 126              | 10.4%            |
 
-When testing with screen readers, try to use some of the combinations at the top of this list. For example, when testing with VoiceOver, it's preferrable to use Safari.
+When testing with screen readers, try to use some of the combinations at the top of this list. For example, when testing with VoiceOver, it's preferable to use Safari.
 
 ### NVDA with Firefox
 

docs/getting-started/create-block/finishing.md

@@ -10,7 +10,7 @@ You can visually browse the components and what their implementation looks like
 
 ## Additional Tutorials
 
-The **RichText component** allows for creating a richer input besides plain text, allowing for bold, italic, links, and other inline formating. See the [RichText Reference](/docs/reference-guides/richtext.md) for documentation using this component.
+The **RichText component** allows for creating a richer input besides plain text, allowing for bold, italic, links, and other inline formatting. See the [RichText Reference](/docs/reference-guides/richtext.md) for documentation using this component.
 
 The InspectorPanel (the settings on the right for a block) and Block Controls (toolbar controls) have a standard way to be implemented. See the [Block controls tutorial](/docs/how-to-guides/block-tutorial/block-controls-toolbar-and-sidebar.md) for additional information.
 

docs/getting-started/create-block/submitting-to-block-directory.md

@@ -71,7 +71,7 @@ Wondering where to input all this information? Read the next section :)
 
 Each block in your plugin should have a corresponding `block.json` file with the [block metadata](/docs/reference-guides/block-api/block-metadata.md). This file provides the Block Directory important information about your block. Along with being the place to store contextual information about your block like the: `name`, `description`, `keywords` and `category`, the `block.json` file stores the location of your block’s files.
 
-Block plugins submitted to the Block Directory can contain mutliple blocks only if they are children of a single parent/ancestor. There should only be one main block. For example, a list block can contain list-item blocks. Children blocks must set the `parent` property in their `block.json` file.
+Block plugins submitted to the Block Directory can contain multiple blocks only if they are children of a single parent/ancestor. There should only be one main block. For example, a list block can contain list-item blocks. Children blocks must set the `parent` property in their `block.json` file.
 
 Double check that the following is true for your block:
 

docs/getting-started/devenv/README.md

@@ -69,7 +69,7 @@ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
 
 Note: On macOS, the required developer tools are not installed by default, if not already installed you may be prompted to download the install.
 
-<img src="https://developer.wordpress.org/files/2020/07/git-install-prompt.png" alt="Mac git command requies command line developer tools" width="400" height="195"/>
+<img src="https://developer.wordpress.org/files/2020/07/git-install-prompt.png" alt="Mac git command requires command line developer tools" width="400" height="195"/>
 
 After installing nvm, you need to use it to install Node.js, to install v14, run:
 

docs/getting-started/full-site-editing.md

@@ -1,21 +1,21 @@
 # Full Site Editing
 
-At the highest level, the vision of Full Site Editing is to provide a collection of features that bring the familiar experience and extendability of blocks to all parts of your site rather than just post and pages. You can think of Full Site Editing as the umbrella project name for various sub-projects within Gutenberg that make this vision possible. Projects under Full Site Editing (FSE) include everything from the Site Editor, Global Styles, numerous Site/Post/Page specific blocks, Query block, Navigation block, Templates, and block themes. What follows are brief descriptions of the major pieces with more details found [here](https://github.com/WordPress/gutenberg/issues/24551): 
+At the highest level, the vision of Full Site Editing is to provide a collection of features that bring the familiar experience and extendability of blocks to all parts of your site rather than just post and pages. You can think of Full Site Editing as the umbrella project name for various sub-projects within Gutenberg that make this vision possible. Projects under Full Site Editing (FSE) include everything from the Site Editor, Global Styles, numerous Site/Post/Page specific blocks, Query block, Navigation block, Templates, and block themes. What follows are brief descriptions of the major pieces with more details found [here](https://github.com/WordPress/gutenberg/issues/24551):
 
-- Site Editor: the cohesive experience that allows you to directly edit and navigate between various templates, template parts, styling options, and more. 
-- Template Editing: a scaled down direct editing experience allowing you to edit/change/create the template a post/page uses. 
-- Block Theme: work to allow for a theme that's built using templates composed using blocks that works with full site editing. More below. 
+- Site Editor: the cohesive experience that allows you to directly edit and navigate between various templates, template parts, styling options, and more.
+- Template Editing: a scaled down direct editing experience allowing you to edit/change/create the template a post/page uses.
+- Block Theme: work to allow for a theme that's built using templates composed using blocks that works with full site editing. More below.
 - Styling: the feature that enables styling modifications across three levels (local blocks, theme defaults, and global modifications).
-- Theme Blocks: new blocks that accomplish everything possible in traditional templates using template tags (ex: Post Author Block). 
-- Browsing: the feature that unlocks the ability to navigate between various entities in the site editing experience including templates, pages, etc. 
+- Theme Blocks: new blocks that accomplish everything possible in traditional templates using template tags (ex: Post Author Block).
+- Browsing: the feature that unlocks the ability to navigate between various entities in the site editing experience including templates, pages, etc.
 - Navigation Block: a new block that allows you to edit a site's navigation menu, both in terms of structure and design.
-- Query Block: a new block that replicates the classic WP_Query and allows for further customization with additional functionality. 
+- Query Block: a new block that replicates the classic WP_Query and allows for further customization with additional functionality.
 
 There are other projects, like the Navigation Editor and Widget Editor, that are meant to specifically help classic themes begin adapting more to the block framework and to act as a stepping stone of sorts to Full Site Editing. These are separate projects from Full Site Editing though but are worth being aware of as they ultimately help the cause of getting more people adjusted to using blocks in more places.
 
 **Jump in:**
 
-The best way to learn something is start playing with it. So jump in by installing the Gutenberg plugin from the plugins directory and activating a block theme on a test site. We recommend the [TT1 Blocks theme](https://wordpress.org/themes/tt1-blocks/), it is listed in the theme diretory and our development reference theme. You can find other themes in the directory using the [full-site-editing feature tag](https://wordpress.org/themes/tags/full-site-editing/).
+The best way to learn something is start playing with it. So jump in by installing the Gutenberg plugin from the plugins directory and activating a block theme on a test site. We recommend the [TT1 Blocks theme](https://wordpress.org/themes/tt1-blocks/), it is listed in the theme directory and our development reference theme. You can find other themes in the directory using the [full-site-editing feature tag](https://wordpress.org/themes/tags/full-site-editing/).
 
 ## Get Involved
 

docs/how-to-guides/block-tutorial/applying-styles-with-stylesheets.md

@@ -162,7 +162,7 @@ registerBlockType( 'gutenberg-examples/example-02-stylesheets', {
 
 ### Build or add dependency
 
-In order to include the blockEditor as a dependancy, make sure to run the build step, or update the asset php file.
+In order to include the blockEditor as a dependency, make sure to run the build step, or update the asset php file.
 
 {% codetabs %}
 {% JSX %}
@@ -174,7 +174,7 @@ npm run build
 
 {% Plain %}
 
-Edit the asset file to include the block-editor dependancy for the scripts.
+Edit the asset file to include the block-editor dependency for the scripts.
 
 ```php
 <?php return

docs/how-to-guides/data-basics/2-building-a-list-of-pages.md

@@ -262,7 +262,7 @@ function MyFirstApp() {
 
 Working outside of core-data, we would need to solve two problems here.
 
-Firstly, out-of-order updates. Searching for „About” would trigger five API requests filtering for `A`, `Ab`, `Abo`, `Abou`, and `About`. Theese requests could finish in a different order than they started. It is possible that _search=A_ would resolve after _ search=About_ and thus we’d display the wrong data.
+Firstly, out-of-order updates. Searching for „About” would trigger five API requests filtering for `A`, `Ab`, `Abo`, `Abou`, and `About`. These requests could finish in a different order than they started. It is possible that _search=A_ would resolve after _ search=About_ and thus we’d display the wrong data.
 
 Gutenberg data helps by handling the asynchronous part behind the scenes. `useSelect` remembers the most recent call and returns only the data we expect.
 

docs/how-to-guides/propagating-updates.md

@@ -22,7 +22,7 @@ How to manage block updates depends on the nature of the block itself. If the bl
 
 ### Patterns
 
-**For content that you want updated later on, do not use patterns and instead rely on reusable blocks or template parts.** Patterns cannot be updated after you insert one into your site. For context, you can think of Patterns as more like sample/example/starter content. While Patterns exposed in the Inserter might evolve over time, those changes won't be automatically applied to any current useage of the pattern. Once inserted, patterns become completely detached from the original pattern unlike Reusable block or Template Part block.
+**For content that you want updated later on, do not use patterns and instead rely on reusable blocks or template parts.** Patterns cannot be updated after you insert one into your site. For context, you can think of Patterns as more like sample/example/starter content. While Patterns exposed in the Inserter might evolve over time, those changes won't be automatically applied to any current usage of the pattern. Once inserted, patterns become completely detached from the original pattern unlike Reusable block or Template Part block.
 
 If needed, one potential workaround for patterns with custom styles is to add a class name to the wrapping block for a pattern. For example, the following adds a themeslug-special class to a Group block:
 

lib/compat/wordpress-6.2/get-global-styles-and-settings.php

@@ -66,7 +66,7 @@ function wp_theme_has_theme_json_clean_cache() {
  *                     It accepts as values: 'variables', 'presets', 'styles', 'base-layout-styles, and 'custom-css'.
  *                     If empty, it'll load the following:
  *                     - for themes without theme.json: 'variables', 'presets', 'base-layout-styles'.
- *                     - for temes with theme.json: 'variables', 'presets', 'styles', 'custom-css'.
+ *                     - for themes with theme.json: 'variables', 'presets', 'styles', 'custom-css'.
  *
  * @return string Stylesheet.
  */