Updated Several Typos

docs/contributors/code/react-native/integration-test-guide.md

@@ -12,7 +12,7 @@ A test can be structured with the following parts:
 -   [Rendering](#rendering)
 -   [Query elements](#query-elements)
 -   [Fire events](#fire-events)
--   [Expect correct element behaviour](#expect-correct-element-behaviour)
+-   [Expect correct element behavior](#expect-correct-element-behavior)
 -   [Cleanup](#cleanup)
 
 We also include examples of common tasks as well as tips in the following sections:
@@ -170,7 +170,7 @@ We can also trigger any type of event, including custom events, in the following
 fireEvent( heightSlider, 'valueChange', '50' );
 ```
 
-## Expect correct element behaviour
+## Expect correct element behavior
 
 After querying elements and firing events, we must verify that the logic works as expected. For this purpose we can use the same `expect` function from Jest that we use in unit tests. It is recommended to use the custom `toBeVisible` matcher to ensure the element is defined, is a valid React element, and visible.
 
@@ -331,7 +331,7 @@ If you have trouble locating an element’s identifier, you may wish to use Xcod
 
 ### False positives when omitting `await` before `waitFor` function
 
-Omitting the `await` before a `waitFor` can lead to scenarios where tests pass but are not testing the intended behaviour. For example, if `toBeDefined` is used to assert the result of a call to `waitFor`, the assertion will pass because `waitFor` returns a value, even though it is not the `ReactTestInstance` we meant to check for. For this reason, it is recommended to use the custom matcher `toBeVisible` which guards against this type of false positive.
+Omitting the `await` before a `waitFor` can lead to scenarios where tests pass but are not testing the intended behavior. For example, if `toBeDefined` is used to assert the result of a call to `waitFor`, the assertion will pass because `waitFor` returns a value, even though it is not the `ReactTestInstance` we meant to check for. For this reason, it is recommended to use the custom matcher `toBeVisible` which guards against this type of false positive.
 
 ### `waitFor` timeout
 
@@ -345,7 +345,7 @@ In case we want to keep both, we’ll add the word "integration" to the integrat
 
 ### Platform selection
 
-By default, all tests run in Jest use the Android platform, so in case we need to test a specific behaviour related to a different platform, we would need to support platform test files.
+By default, all tests run in Jest use the Android platform, so in case we need to test a specific behavior related to a different platform, we would need to support platform test files.
 
 In case we only need to test logic controlled by the Platform object, we can mock the module with the following code (in this case it’s changing the platform to iOS):
 

docs/contributors/code/testing-overview.md

@@ -8,11 +8,11 @@ Aside from the joy testing will bring to your life, tests are important not only
 
 Tests are also part of our code base, which means we apply to them the same standards we apply to all our application code.
 
-As with all code, tests have to be maintained. Writing tests for the sake of having a test isn't the goal – rather we should try to strike the right balance between covering expected and unexpected behaviours, speedy execution and code maintenance.
+As with all code, tests have to be maintained. Writing tests for the sake of having a test isn't the goal – rather we should try to strike the right balance between covering expected and unexpected behaviors, speedy execution and code maintenance.
 
 When writing tests consider the following:
 
--   What behaviour(s) are we testing?
+-   What behavior(s) are we testing?
 -   What errors are likely to occur when we run this code?
 -   Does the test test what we think it is testing? Or are we introducing false positives/negatives?
 -   Is it readable? Will other contributors be able to understand how our code behaves by looking at its corresponding test?
@@ -66,9 +66,9 @@ It will make your life easier should you decide to relocate your code to another
 
 ### Describing tests
 
-Use a `describe` block to group test cases. Each test case should ideally describe one behaviour only.
+Use a `describe` block to group test cases. Each test case should ideally describe one behavior only.
 
-In test cases, try to describe in plain words the expected behaviour. For UI components, this might entail describing expected behaviour from a user perspective rather than explaining code internals.
+In test cases, try to describe in plain words the expected behavior. For UI components, this might entail describing expected behavior from a user perspective rather than explaining code internals.
 
 **Good**
 
@@ -134,7 +134,7 @@ Here we'd have to import and use a value from `VALID_VALUES_LIST` in order to pa
 
 `expect( isValueValid( VALID_VALUES_LIST[ 0 ] ) ).toBe( true );`
 
-The above assertion is testing two behaviours: 1) that the function can detect an item in a list, and 2) that it can detect an item in `VALID_VALUES_LIST`.
+The above assertion is testing two behaviors: 1) that the function can detect an item in a list, and 2) that it can detect an item in `VALID_VALUES_LIST`.
 
 But what if we don't care what's stored in `VALID_VALUES_LIST`, or if the list is fetched via an HTTP request, and we only want to test whether `isValueValid` can detect an item in a list?
 
@@ -169,7 +169,7 @@ export const isBilboVisible = () =>
 	config.isEnabled( 'the-ring' ) ? false : true;
 ```
 
-To test the behaviour under each condition, we stub the config object and use a jest mocking function to control the return value of `isEnabled`.
+To test the behavior under each condition, we stub the config object and use a jest mocking function to control the return value of `isEnabled`.
 
 ```javascript
 // test/bilbo.js

docs/contributors/triage.md

@@ -9,7 +9,7 @@ To keep the repository healthy, it needs to be triaged regularly. **Triage is th
 The triage team is an open group of people with a particular role of making sure triage is done consistently across the Gutenberg repo. There are various types of triage which happen:
 
 -   Regular self triage sessions done by members on their own time.
--   Organised triage sessions done as a group at a set time. You can [review the meetings page](https://make.wordpress.org/meetings/) to find these triage sessions and appropriate slack channels.
+-   Organized triage sessions done as a group at a set time. You can [review the meetings page](https://make.wordpress.org/meetings/) to find these triage sessions and appropriate slack channels.
 -   Focused triage sessions on a specific board, label or feature.
 
 These are the expectations of being a triage team member:

docs/how-to-guides/themes/global-settings-and-styles.md

@@ -907,7 +907,7 @@ By default, the block selector is generated based on its name such as `.wp-block
 body {
 	color: var( --wp--preset--color--primary );
 }
-p { /* The core/paragraph opts out from the default behaviour and uses p as a selector. */
+p { /* The core/paragraph opts out from the default behavior and uses p as a selector. */
 	color: var( --wp--preset--color--secondary );
 }
 .wp-block-group {

packages/block-editor/README.md

@@ -66,7 +66,7 @@ registerCoreBlocks();
 
 Any components in this package that have a counterpart in [@wordpress/components](/packages/components/README.md) are an extension of those components.
 
-Unless you're [creating an editor](/docs/how-to-guides/platform/custom-block-editor.md), it is recommended that the components in @wordpress/components should be used rather than the ones in this package as these components have been customized for use in an editor and may result in unexpected behaviour if used outside of this context.
+Unless you're [creating an editor](/docs/how-to-guides/platform/custom-block-editor.md), it is recommended that the components in @wordpress/components should be used rather than the ones in this package as these components have been customized for use in an editor and may result in unexpected behavior if used outside of this context.
 
 <!-- START TOKEN(Autogenerated API docs) -->
 

packages/block-editor/src/components/background-image-control/index.js

@@ -336,7 +336,7 @@ function BackgroundImageControls( {
 			replaceContainerRef.current
 		);
 		// Focus the toggle button and close the dropdown menu.
-		// This ensures similar behaviour as to selecting an image, where the dropdown is
+		// This ensures similar behavior as to selecting an image, where the dropdown is
 		// closed and focus is redirected to the dropdown toggle button.
 		toggleButton?.focus();
 		toggleButton?.click();

packages/block-editor/src/components/block-list/use-block-props/use-selected-block-event-handlers.js

@@ -16,7 +16,7 @@ import { unlock } from '../../../lock-unlock';
 import BlockDraggableChip from '../../../components/block-draggable/draggable-chip';
 
 /**
- * Adds block behaviour:
+ * Adds block behavior:
  *   - Removes the block on BACKSPACE.
  *   - Inserts a default block on ENTER.
  *   - Disables dragging of block contents.
@@ -120,7 +120,7 @@ export function useEventHandlers( { clientId, isSelected } ) {
 				domNode.style.pointerEvents = 'none';
 
 				// Setting the drag chip as the drag image actually works, but
-				// the behaviour is slightly different in every browser. In
+				// the behavior is slightly different in every browser. In
 				// Safari, it animates, in Firefox it's slightly transparent...
 				// So we set a fake drag image and have to reposition it
 				// ourselves.

packages/block-editor/src/components/block-list/use-in-between-inserter.js

@@ -172,7 +172,7 @@ export function useInBetweenInserter() {
 				const index = getBlockIndex( clientId );
 
 				// Don't show the in-between inserter before the first block in
-				// the list (preserves the original behaviour).
+				// the list (preserves the original behavior).
 				if ( index === 0 ) {
 					hideInsertionPoint();
 					return;

packages/block-editor/src/components/border-radius-control/index.js

@@ -53,7 +53,7 @@ export default function BorderRadiusControl( { onChange, values } ) {
 
 	// Tracking selected units via internal state allows filtering of CSS unit
 	// only values from being saved while maintaining preexisting unit selection
-	// behaviour. Filtering CSS unit only values prevents invalid style values.
+	// behavior. Filtering CSS unit only values prevents invalid style values.
 	const [ selectedUnits, setSelectedUnits ] = useState( {
 		flat:
 			typeof values === 'string'

packages/block-editor/src/components/button-block-appender/README.md

@@ -2,7 +2,7 @@
 
 `ButtonBlockAppender` provides button with a `+` (plus) icon which when clicked will trigger the default Block `Inserter` UI to allow a Block to be inserted.
 
-This is typically used as an alternative to the `<DefaultBlockAppender />` component to determine the initial placeholder behaviour for a Block when displayed in the editor UI.
+This is typically used as an alternative to the `<DefaultBlockAppender />` component to determine the initial placeholder behavior for a Block when displayed in the editor UI.
 
 ## Usage
 
@@ -40,4 +40,4 @@ A CSS `class` to be _prepended_ to the default class of `"button-block-appender"
 
 ## Examples
 
-The [`<InnerBlocks>` component](../inner-blocks/) exposes an enhanced version of `ButtonBlockAppender` to allow consumers to choose it as an alternative to the standard behaviour of auto-inserting the default Block (typically `core/paragraph`).
+The [`<InnerBlocks>` component](../inner-blocks/) exposes an enhanced version of `ButtonBlockAppender` to allow consumers to choose it as an alternative to the standard behavior of auto-inserting the default Block (typically `core/paragraph`).

packages/block-editor/src/components/caption/README.md

@@ -2,7 +2,7 @@
 
 The `Caption` component renders the [caption part](https://wordpress.org/documentation/article/gallery-block/#caption) of some blocks (image, gallery...).
 
-This component encapsulates the "caption" behaviour and styles over a `<RichText>` so it can be used in other components such as the `BlockCaption` component.
+This component encapsulates the "caption" behavior and styles over a `<RichText>` so it can be used in other components such as the `BlockCaption` component.
 
 ## Development guidelines
 

packages/edit-site/src/components/style-book/constants.ts

@@ -168,7 +168,7 @@ export const STYLE_BOOK_ALL_BLOCKS_SUBCATEGORIES: StyleBookCategory[] = [
 	},
 ];
 
-// Style book preview categories are organised slightly differently to the editor ones.
+// Style book preview categories are organized slightly differently to the editor ones.
 export const STYLE_BOOK_PREVIEW_CATEGORIES: StyleBookCategory[] = [
 	{
 		slug: 'overview',