Use US English

docs/10-introduction.md

@@ -6,7 +6,7 @@
 
 ![image](img/architecture.png)
 
-The core of the OpenRemote system is the [Manager](https://github.com/openremote/core/tree/main/manager), a headless Java application that forms an IoT context broker which captures the current asset state of the system. You can create a dynamic schema of your assets and their attributes in the manager, modelling the problem domain. For example, you would create Building, Vehicle, Battery, Streetlight, and Sensor assets to model an IoT system for a smart city, an energy management system, or fleet telematics.
+The core of the OpenRemote system is the [Manager](https://github.com/openremote/core/tree/main/manager), a headless Java application that forms an IoT context broker which captures the current asset state of the system. You can create a dynamic schema of your assets and their attributes in the manager, modeling the problem domain. For example, you would create Building, Vehicle, Battery, Streetlight, and Sensor assets to model an IoT system for a smart city, an energy management system, or fleet telematics.
 
 Rules can be written in Groovy, a Rules JSON, or Flow model, and dynamically deployed. Rules execute actions when matching asset state or sequence of events are detected. For example, when a mobile asset enters a geographic fence, or when your sensor is not updating anymore, you can notify a group of users via email and on their mobile devices.
 
@@ -26,7 +26,7 @@ The OpenRemote [Frontend](./developer-guide/110-working-on-ui-and-apps.md) simpl
 * Home automation control panel
 * Smart city monitoring dashboard
 
-We support the latest HTML standards and provide [web components](https://github.com/openremote/core/tree/main/ui/component) to build applications quickly, utilising the OpenRemote asset model and APIs: you can easily show all your assets on a map, for example. [Full web applications](https://github.com/openremote/core/tree/main/ui/app) are also bundled with OpenRemote, these can be used as templates for building custom web applications.
+We support the latest HTML standards and provide [web components](https://github.com/openremote/core/tree/main/ui/component) to build applications quickly, utilizing the OpenRemote asset model and APIs: you can easily show all your assets on a map, for example. [Full web applications](https://github.com/openremote/core/tree/main/ui/app) are also bundled with OpenRemote, these can be used as templates for building custom web applications.
 
 
 The OpenRemote [Android](https://github.com/openremote/console-android) and [iOS](https://github.com/openremote/console-ios) Consoles are native mobile applications that act as a shell for web applications built with the OpenRemote web components; a web browser is also considered to be a console and we automatically integrate native console features like push notifications and geofencing on each platform. If you have an existing website, add OpenRemote web components and wrap it in the OpenRemote console to connect your mobile users to your IoT network.

docs/20-quick-start.md

@@ -1,6 +1,6 @@
 # Quick Start
 
-Welcome to OpenRemote; an intuitive user-friendly 100% open source IoT platform. You can build a complete IoT device management solution including: device management and auto provisioning, customisation of asset types, automation via When-Then, Flow and Groovy rules, data analytics, connectivity via several protocol agents and manager APIs (e.g. MQTT broker, HTTP/REST, WS), Multi-tenancy (realms), Users and roles management, Edge gateway, Front-end UI web components and consoles, and an Insights dashboard builder. 
+Welcome to OpenRemote; an intuitive user-friendly 100% open source IoT platform. You can build a complete IoT device management solution including: device management and auto provisioning, customization of asset types, automation via When-Then, Flow and Groovy rules, data analytics, connectivity via several protocol agents and manager APIs (e.g. MQTT broker, HTTP/REST, WS), Multi-tenancy (realms), Users and roles management, Edge gateway, Front-end UI web components and consoles, and an Insights dashboard builder.
 
 As the code base is 100% open source, applications are limitless. Here's an architecture overview:
 

docs/architecture/20-manager-endpoints-and-file-paths.md

@@ -13,7 +13,7 @@ The OpenRemote Manager exposes the following endpoints:
 * `/auth` - Keycloak reverse proxy endpoint
 * `/websocket` - WebSocket endpoint
 * `/*` - Any other path is resolved against `$CUSTOM_APP_DOCROOT` (see paths below)
-* `/manager_config.json` - File that is loaded by the Manager UI to apply custom configuration to the Manager UI (white labelling, menu config, etc.)  (loaded from `$CUSTOM_APP_DOCROOT`) (see [here](../user-guide/010-deploying/20-configuring-the-manager-ui.md) for more details)
+* `/manager_config.json` - File that is loaded by the Manager UI to apply custom configuration to the Manager UI (white labeling, menu config, etc.)  (loaded from `$CUSTOM_APP_DOCROOT`) (see [here](../user-guide/010-deploying/20-configuring-the-manager-ui.md) for more details)
 * `/locales` - Path used by Manager UI to find custom `i18n` locale files, each locale should be in it's own directory with a file named `app.json` (e.g. `/locales/en/app.json`) (loaded from `$CUSTOM_APP_DOCROOT`)
 
 ### App Realm
@@ -23,7 +23,7 @@ e.g.  `/manager/?realm=smartcity`
 
 ## File paths
 
-The following list shows the file paths used by our Docker containers; these can be customised by changing environment variable values (where a file path is controlled by an environment variable) and/or by using volume mapping, this is how we provide customised instances of our system for specific projects. The default values shown below are the defaults as used by our Docker containers.
+The following list shows the file paths used by our Docker containers; these can be customized by changing environment variable values (where a file path is controlled by an environment variable) and/or by using volume mapping, this is how we provide customized instances of our system for specific projects. The default values shown below are the defaults as used by our Docker containers.
 
 ### Manager
 

docs/architecture/40-asset-validation.md

@@ -1,6 +1,6 @@
 # Asset Validation
 
-This document summarises how asset validation is performed and how it relates to the asset type model.
+This document summarizes how asset validation is performed and how it relates to the asset type model.
 
 ## AssetTypeInfo Model Structure
 

docs/architecture/50-asset-location-tracking.md

@@ -51,10 +51,10 @@ How geofences are 'pushed' to assets is handled by GeofenceAdapters that are loa
 ### Unsupported assets/rules
 If there are rules with location predicates but they cannot be implemented using geofence APIs on the asset and/or the asset doesn't support geofence APIs then the location attribute is expected to be updated using some other mechanism (asset pushes location, protocol polling, manual, etc.)
 
-### Geofence trigger behaviour
+### Geofence trigger behavior
 When a geofence is triggered on an asset then the asset should update its own location by posting to the public endpoint `asset/public/{assetId}/updateLocation`, the location value sent should be as follows:
 
-* Geofence Enter - Send geofence centre point as location (centre point should have been provided in the geofence definition retrieved from the backend)
+* Geofence Enter - Send geofence center point as location (center point should have been provided in the geofence definition retrieved from the backend)
 * Geofence Exit - Send null (this will clear the devices location and indicate that the asset has left the geofence)
 
 **By using geofence triggers in this way the handling of all location tracked assets can be processed in the same way i.e. the manager rules can compare location asset state changes irrespective of how the asset provides the location data.**

docs/architecture/60-apps-and-consoles.md

@@ -22,12 +22,12 @@ openremote.init(...).then(()=> {
 Apps should be built and deployed within the OR manager web server using the standard tooling e.g. `gradle clean installDist` (refer to the developer guide).
 Console build and deployment will depend on the specific tools and platform used but where possible the standard tooling and deployment process should be used.
 
-## Runtime behaviour
+## Runtime behavior
 1. Console is 'launched' (e.g. typing URL in browser or opening the app)
 1. Console then displays a splash screen indicating that the client is loading
 1. App is loaded and the URL should include query parameters to instruct the `@openremote/core` component what functionality they wish to provide to the client (see the Console/app API below)
-1. The app will initialise the console and the console must reply to the app as required by the API (see the Console/app API below)
-1. If the app has set `consoleAutoEnable: false` when initialising the `@openremote/core` component then the console must listen for the `OREvent.CONSOLE_INIT` event and then it can enable each `provider` that it is providing to the app; once all `providers` are enabled (excluding those that have been explicitly `disabled` by the user or some other mechanism) then the `OREvent.CONSOLE_READY` event is raised
+1. The app will initialize the console and the console must reply to the app as required by the API (see the Console/app API below)
+1. If the app has set `consoleAutoEnable: false` when initializing the `@openremote/core` component then the console must listen for the `OREvent.CONSOLE_INIT` event and then it can enable each `provider` that it is providing to the app; once all `providers` are enabled (excluding those that have been explicitly `disabled` by the user or some other mechanism) then the `OREvent.CONSOLE_READY` event is raised
 
 Once the console is ready it is automatically registered with the manager backend by sending a `ConsoleRegistration` object, for example:
 ```json
@@ -73,15 +73,15 @@ Console loads app with the following query parameters in the URL to override des
 * consoleProviders [string] - Space delimited list of providers that this console supports (see below for currently supported/standard providers)
 * consoleAutoEnable [boolean] - Whether `@openremote/core` should try and auto enable each provider (note that auto enabling cannot send any custom data to each provider during enabling and it also cannot do any processing on the responses received), for this reason it only really works on providers that don't require data during enabling.
 
-#### Initialise
-For each provider the `@openremote/core` component sends a message asking the console to initialise the provider:
+#### Initialize
+For each provider the `@openremote/core` component sends a message asking the console to initialize the provider:
 ```json
 {
    action: "PROVIDER_INIT",
    provider: "PROVIDER_NAME"
 }
 ```
-The console then does any required initialisation and sends a message back to the app:
+The console then does any required initialization and sends a message back to the app:
 ```json
 {
    action: "PROVIDER_INIT",
@@ -94,10 +94,10 @@ The console then does any required initialisation and sends a message back to th
    success: true|false [true=init success; false=init failure]
 }
 ```
-If a provider initialisation call returns `success: false` then it is automatically marked as `disabled`, once all `providers` are initialised the `OREvent.CONSOLE_INIT` event is raised. The app can retrieve the `console` instance as described above and it can check the status of each `provider` and take appropriate action if desired.
+If a provider initialization call returns `success: false` then it is automatically marked as `disabled`, once all `providers` are initialized the `OREvent.CONSOLE_INIT` event is raised. The app can retrieve the `console` instance as described above and it can check the status of each `provider` and take appropriate action if desired.
 
 #### Enable
-Once all providers are initialised then the app is free to decide when to enable each provider (if `consoleAutoEnable: false` otherwise they will be auto enabled); where a provider returned `requiresPermission=true && hasPermission=false` then the client is best placed to decide when and how to ask for permissions and should use good UX principles to avoid users denying such permission requests (see [permission-ux](https://developers.google.com/web/fundamentals/push-notifications/permission-ux)). Providers that don't require permissions or already have permissions could be enabled immediately. The enable message structure is:
+Once all providers are initialized then the app is free to decide when to enable each provider (if `consoleAutoEnable: false` otherwise they will be auto enabled); where a provider returned `requiresPermission=true && hasPermission=false` then the client is best placed to decide when and how to ask for permissions and should use good UX principles to avoid users denying such permission requests (see [permission-ux](https://developers.google.com/web/fundamentals/push-notifications/permission-ux)). Providers that don't require permissions or already have permissions could be enabled immediately. The enable message structure is:
 ```json
 {
    action: "PROVIDER_ENABLE",
@@ -196,7 +196,7 @@ Called for both types when a push notification is received:
 ```
 
 ### Geofence Provider (provider: "geofence")
-Use platform geofence APIs (Android and iOS); the provider expects a public endpoint on the OR manager at `rules/geofences/{consoleId}` which it can call to get the geofences for this console. The geofence definitions returned by this endpoint and the behaviour of this provider should match the definitions in the asset location tracking documentation.
+Use platform geofence APIs (Android and iOS); the provider expects a public endpoint on the OR manager at `rules/geofences/{consoleId}` which it can call to get the geofences for this console. The geofence definitions returned by this endpoint and the behavior of this provider should match the definitions in the asset location tracking documentation.
 
 #### Enabled message request data (App-> Console)
 ```

docs/developer-guide/020-setting-up-an-ide.md

@@ -41,7 +41,7 @@ For formatter plugins and IDE settings, see [Code formatting with Spotless](./02
 
 ##### Grep Console Styling
 
-The log messages of the running application can be colour-highlighted with the [GrepConsole plugin](https://plugins.jetbrains.com/plugin/7125-grep-console) and our [configuration](https://github.com/openremote/core/tree/main/tools/intellij).
+The log messages of the running application can be color-highlighted with the [GrepConsole plugin](https://plugins.jetbrains.com/plugin/7125-grep-console) and our [configuration](https://github.com/openremote/core/tree/main/tools/intellij).
 
 - Locate XML style config for Grep Console in openremote/tools/intellij
 - Choice the default or dark styling config
@@ -114,7 +114,7 @@ If you are using the custom project repository as starting point the run configu
 - Module/Classpath: `custom-project.setup.main` for custom projects
 - Working directory: *Must be set to OpenRemote main project directory!*
 - Main class: `org.openremote.manager.Main`
-- Any environment variables that customise deployment (usually custom projects have some)
+- Any environment variables that customize deployment (usually custom projects have some)
 
 ### Accessing the Manager UI
 

docs/developer-guide/025-code-formatting.md

@@ -623,7 +623,7 @@ Projects that still use the previous `ci_cd.yml` workflow commonly reference it
 uses: openremote/core/.github/workflows/ci_cd.yml@main
 ```
 
-Because this follows `main`, new workflow behaviour is inherited automatically. This includes the Spotless formatting checks, which `ci_cd.yml` runs from release 1.29.0 onwards.
+Because this follows `main`, new workflow behavior is inherited automatically. This includes the Spotless formatting checks, which `ci_cd.yml` runs from release 1.29.0 onwards.
 
 #### Temporarily pinning the workflow
 

docs/developer-guide/040-creating-a-custom-project.md

@@ -23,7 +23,7 @@ The guide consists of the following sections and you will need to have a working
 
 ## Project Structure
 
-It is recommended to put custom project code in directory/module called `deployment` this can then be built as a Docker image and used as a Docker volume to map into our `manager` and `keycloak` containers to override/enhance their behaviour; if there is a large amount of code then multiple directories/modules might be desired to logically separate the code, in this case it is advised to follow the same naming convention as the main OpenRemote repo and to ensure the `gradle` build `installDist` task is configured in order to copy the compiled code into the `deployment` `build` directory in preparation for building the `deployment` Docker image.
+It is recommended to put custom project code in directory/module called `deployment` this can then be built as a Docker image and used as a Docker volume to map into our `manager` and `keycloak` containers to override/enhance their behavior; if there is a large amount of code then multiple directories/modules might be desired to logically separate the code, in this case it is advised to follow the same naming convention as the main OpenRemote repo and to ensure the `gradle` build `installDist` task is configured in order to copy the compiled code into the `deployment` `build` directory in preparation for building the `deployment` Docker image.
 
 ## OpenRemote Dependencies
 
@@ -52,7 +52,7 @@ The [custom-project](https://github.com/openremote/custom-project) repo acts as
 
 ### Deployment directory/module
 
-This module is used to generate a `deployment` Docker image which can be volume mapped into the manager and/or Keycloak containers to customize their behaviour. The `installDist` Gradle task of this module will generate output in the `/deployment/build` directory in particular:
+This module is used to generate a `deployment` Docker image which can be volume mapped into the manager and/or Keycloak containers to customize their behavior. The `installDist` Gradle task of this module will generate output in the `/deployment/build` directory in particular:
 
 * `/deployment/build/image` - Content to be added to the deployment Docker image at `/deployment`
 * `/deployment/build/Dockerfile` - Docker build file used to build `deployment` Docker image (copied from `/deployment` during `installDist`)