docs: Fix typos and inconsistent spellings (#1079)

docs/docs/development/build-flash.md

@@ -26,7 +26,7 @@ From here on, building and flashing ZMK should all be done from the `app/` subdi
 cd app
 ```
 
-To build for your particular keyboard, the behaviour varies slightly depending on if you are building for a keyboard with
+To build for your particular keyboard, the behavior varies slightly depending on if you are building for a keyboard with
 an onboard MCU, or one that uses an MCU board addon.
 
 ### Keyboard (Shield) + MCU Board

docs/docs/development/hardware-metadata-files.md

@@ -100,7 +100,7 @@ Boards and shields should document the sets of hardware features found on them u
 
 The `siblings` array is used to identify multiple hardware items designed to be used together as one logical device. Right now, that primarily is used to identify the two halves of a split keyboard, but future enhancements will include more complicated and flexible combinations.
 
-The array should contrain the complete harware IDs of the siblings that combine in the logical device, e.g. with the `corne.zmk.yml` file:
+The array should contain the complete hardware IDs of the siblings that combine in the logical device, e.g. with the `corne.zmk.yml` file:
 
 ```yaml
 id: corne

docs/docs/development/new-shield.md

@@ -360,7 +360,7 @@ The two `#include` lines at the top of the keymap are required in order to bring
 Further documentation on behaviors and bindings is forthcoming, but a summary of the current behaviors you can bind to key positions is as follows:
 
 - `kp` is the "key press" behavior, and takes a single binding argument of the key code from the 'keyboard/keypad" HID usage table.
-- `mo` is the "momentary layer" behaviour, and takes a single binding argument of the numeric ID of the layer to momentarily enable when that key is held.
+- `mo` is the "momentary layer" behavior, and takes a single binding argument of the numeric ID of the layer to momentarily enable when that key is held.
 - `trans` is the "transparent" behavior, useful to be place in higher layers above `mo` bindings to be sure the key release is handled by the lower layer. No binding arguments are required.
 - `mt` is the "mod-tap" behavior, and takes two binding arguments, the modifier to use if held, and the keycode to send if tapped.
 

docs/docs/faq.md

@@ -12,7 +12,7 @@ As a best-in-class RTOS, Zephyr™ brings many [benefits](https://www.zephyrproj
 - Powerful hardware abstraction and configuration using [DeviceTree](https://docs.zephyrproject.org/latest/guides/dts/index.html) and [Kconfig](https://docs.zephyrproject.org/latest/guides/kconfig/index.html).
 - A BLE stack that periodically obtains [qualification](https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-qual.html) listings, making it easier for final products to obtain qualification from the Bluetooth® SIG.
 - Multi-processor support, which is critical for power efficiency in upcoming MCUs.
-- Permissive licencing with its Apache 2.0 open source [license](https://www.apache.org/licenses/LICENSE-2.0).
+- Permissive licensing with its Apache 2.0 open source [license](https://www.apache.org/licenses/LICENSE-2.0).
 - A buzzing developer [community](https://github.com/zephyrproject-rtos/zephyr) including many leading [embedded technology](https://www.zephyrproject.org/project-members) companies.
 - Long term support (LTS) with security updates.
 
@@ -23,7 +23,7 @@ That’s an excellent question! There are already great keyboard firmwares avail
 - Zephyr™
   - See [Why Zephyr™?](#why-zephyr)
 - Licensing
-  - Just like other open source firmware, ZMK is all about the free and the sharing. However, some other projects use the GPL licence which prevents integration of libraries and drivers whose licenses are not GPL-compatible (such as some embedded BLE drivers). ZMK uses the permissive [MIT](https://github.com/zmkfirmware/zmk/blob/main/LICENSE) license which doesn’t have this limitation.
+  - Just like other open source firmware, ZMK is all about the free and the sharing. However, some other projects use the GPL license which prevents integration of libraries and drivers whose licenses are not GPL-compatible (such as some embedded BLE drivers). ZMK uses the permissive [MIT](https://github.com/zmkfirmware/zmk/blob/main/LICENSE) license which doesn’t have this limitation.
 - Wireless First
   - ZMK is designed for the future, and we believe the future is wireless. So power efficiency plays a critical role in every design decision, just like in Zephyr™.
 

docs/docs/features/keymaps.md

@@ -128,7 +128,7 @@ that defines just one layer for this keymap:
 
 Each layer should have:
 
-1. A `bindings` property this will be a list of behaviour bindings, one for each key position for the keyboard.
+1. A `bindings` property this will be a list of behavior bindings, one for each key position for the keyboard.
 1. (Optional) A `sensor-bindings` property that will be a list of behavior bindings for each sensor on the keyboard. (Currently, only encoders are supported as sensor hardware, but in the future devices like trackpoints would be supported the same way)
 
 For the full set of possible behaviors, start at the [Key Press](../behaviors/key-press.md) behavior.