diff --git a/docs/contributors/code/react-native/integration-test-guide.md b/docs/contributors/code/react-native/integration-test-guide.md
index d4da7bbd1d201c..890575cbce8efa 100644
--- a/docs/contributors/code/react-native/integration-test-guide.md
+++ b/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):
 
diff --git a/docs/contributors/code/testing-overview.md b/docs/contributors/code/testing-overview.md
index 6afa5aed865b7d..2065860e714e8f 100644
--- a/docs/contributors/code/testing-overview.md
+++ b/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
diff --git a/docs/contributors/triage.md b/docs/contributors/triage.md
index 33275b8d3df014..5c4cf7c161f03d 100644
--- a/docs/contributors/triage.md
+++ b/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:
diff --git a/docs/how-to-guides/themes/global-settings-and-styles.md b/docs/how-to-guides/themes/global-settings-and-styles.md
index 205a3ee862ce6b..87d1c2dfc9edac 100644
--- a/docs/how-to-guides/themes/global-settings-and-styles.md
+++ b/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 {
diff --git a/packages/block-editor/README.md b/packages/block-editor/README.md
index 8fe2c5f1179dcd..dacc502c6d7095 100644
--- a/packages/block-editor/README.md
+++ b/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) -->
 
diff --git a/packages/block-editor/src/components/background-image-control/index.js b/packages/block-editor/src/components/background-image-control/index.js
index 6c703ad2eadb4d..825f07427ed406 100644
--- a/packages/block-editor/src/components/background-image-control/index.js
+++ b/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();
diff --git a/packages/block-editor/src/components/block-list/use-block-props/use-selected-block-event-handlers.js b/packages/block-editor/src/components/block-list/use-block-props/use-selected-block-event-handlers.js
index 0a13ce6700b8e8..2acf1d4f65a98b 100644
--- a/packages/block-editor/src/components/block-list/use-block-props/use-selected-block-event-handlers.js
+++ b/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.
diff --git a/packages/block-editor/src/components/block-list/use-in-between-inserter.js b/packages/block-editor/src/components/block-list/use-in-between-inserter.js
index 71eda2558f7930..f2dfcd4ea81253 100644
--- a/packages/block-editor/src/components/block-list/use-in-between-inserter.js
+++ b/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;
diff --git a/packages/block-editor/src/components/border-radius-control/index.js b/packages/block-editor/src/components/border-radius-control/index.js
index cab9b87b3b29c0..043ace44b1d115 100644
--- a/packages/block-editor/src/components/border-radius-control/index.js
+++ b/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'
diff --git a/packages/block-editor/src/components/button-block-appender/README.md b/packages/block-editor/src/components/button-block-appender/README.md
index bb09bcb7eac11d..4d785f8b308abe 100644
--- a/packages/block-editor/src/components/button-block-appender/README.md
+++ b/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`).
diff --git a/packages/block-editor/src/components/caption/README.md b/packages/block-editor/src/components/caption/README.md
index c8cf4ebe8701dd..274a41d8a16ae7 100644
--- a/packages/block-editor/src/components/caption/README.md
+++ b/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
 
diff --git a/packages/edit-site/src/components/style-book/constants.ts b/packages/edit-site/src/components/style-book/constants.ts
index dcd41287fa239d..284816a55da907 100644
--- a/packages/edit-site/src/components/style-book/constants.ts
+++ b/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',