doc: fix spelling mistakes

doc/decisions/change_tracking.md

@@ -67,7 +67,7 @@ When change tracking is enabled, this one will have the most memory overhead, as
 Do the per-parent-key tracking within `libelektra-kdb`, but with meta keys.
 
 Essentially the same approach as above, but instead of deep-duping, we add the original value
-as a meta-key to every key. Not yet clear how we handle changes to meta-data then.
+as a metakey to every key. Not yet clear how we handle changes to metadata then.
 
 ### Alternative 3 - Change tracking within a separate plugin
 
@@ -104,7 +104,7 @@ We need to extend `Key` with the following info:
 - Whether tracking is enabled for this key
 
 The tracking itself would be done within the `ks*` and `key*` methods, after checking if it is enabled.
-It would also transparently work for meta-data, as meta-data itself is implemented as a keyset with keys.
+It would also transparently work for metadata, as metadata itself is implemented as a keyset with keys.
 
 Downsides of this approach:
 
@@ -125,11 +125,11 @@ Use the `backendData->keys` for change tracking
 
 We already store which keys have been returned by `kdbGet` for each backend within KDB.
 Currently, however, this is not a deep duplication, as we are returning the keys from `backendData->keys` directly.
-This means we can not detect changes to the values or meta-data of keys right now.
+This means we can not detect changes to the values or metadata of keys right now.
 We can, however, rely on this for detecting removed and added keys in its current form.
 
 If we don't want to deep-dup it, we'd need to do something different to detect which keys have been modified.
-One possibility would be to add meta-data within the `key` functions (e.g. `meta:/elektra/original`), but that would violate the `libelektra-core` must be minimal constraint.
+One possibility would be to add metadata within the `key` functions (e.g. `meta:/elektra/original`), but that would violate the `libelektra-core` must be minimal constraint.
 
 There is already [another decision](internal_cache.md) which discusses adding general copy-on-write semantics to Elektra.
 We could use this together with `backendData->keys` deep-duped to do memory efficient change tracking.

doc/decisions/operation_sequences.md

@@ -17,13 +17,13 @@ In applications, `kdbGet` and `kdbSet` of different parent keys might be interwo
 This is problematic, as plugins may store the result of `kdbGet` and use the stored data in the following `kdbSet` to calculate a changeset.
 Plugins have to do this, as there isn't any other Elektra-provided mechanism currently to do change tracking for them.
 
-Note, that erroneous behaviour only occurs if plugins are used globally, i.e. as `notification-send` hook plugins.
-If they are mounted for specific backends (via `kdb mount`), this behaviour will not occur as plugins from different backends are isolated.
+Note, that erroneous behavior only occurs if plugins are used globally, i.e. as `notification-send` hook plugins.
+If they are mounted for specific backends (via `kdb mount`), this behavior will not occur as plugins from different backends are isolated.
 
 ### Reproducible Example
 
 The following example will demonstrate the problematic sequence as real, runnable code.
-This example will show the erroneous behaviour for the `dbus` and `logchange` plugins, if used as `notification-send` hooks.
+This example will show the erroneous behavior for the `dbus` and `logchange` plugins, if used as `notification-send` hooks.
 These both plugins just serve as a general demonstration, and there may be more plugins that do change tracking this way.
 
 First, run some setup steps:
@@ -119,7 +119,7 @@ So the correct changeset should look like:
 | -------------- | ------------ | ------------- |
 | `user:/a/test` |              |               |
 
-The erroneous behaviour can be noticed by the output of `dbus-monitor`:
+The erroneous behavior can be noticed by the output of `dbus-monitor`:
 
 ```
 signal time=1666993066.749997 sender=:1.364 -> destination=(null destination) serial=2 path=/org/libelektra/configuration; interface=org.libelektra; member=KeyAdded
@@ -134,7 +134,7 @@ signal time=1666993066.750866 sender=:1.364 -> destination=(null destination) se
    string "user:/b/foreground"
 ```
 
-The same behaviour is present in the `logchange` plugin. Notice its output onto `stdout`:
+The same behavior is present in the `logchange` plugin. Notice its output onto `stdout`:
 
 ```
 added key: user:/a/brightness

doc/news/2014-09-02_0.8.8.md

@@ -7,7 +7,7 @@
 
 In this release we changed 578 files in 473 commits
 (68596 insertions(+), 59260 deletions(-) compared to Elektra 0.8.7).
-We assume thats the largest change set for any of Elektra’s releases
+We assume thats the largest changeset for any of Elektra’s releases
 up to now. It happened only within a bit more than a month up
 (0.8.7 was released 28.07.2014).
 

doc/news/2022-10-05_0.9.11.md

@@ -32,7 +32,7 @@ docker run -it elektra/elektra
 
 In a separated branch we rewrote the whole backend system.
 With this new backend system, backends are now also plugins, allowing backends also to be non-file-based, e.g., using databases.
-The main purpose of this release is to give a last stable release before master gets disrupted with a huge change set.
+The main purpose of this release is to give a last stable release before master gets disrupted with a huge changeset.
 The next release is not to be expected in this year.
 
 A huge thanks to _(Klemens Böswirth @kodebach)_, _(Maximilian Irlinger @atmaxinger)_ for the many changes in the branch.