diff --git a/web/content/docs/devguide/advanced/compiler-cache/index.md b/web/content/docs/devguide/advanced/compiler-cache/index.md
index aa00e7eb532e77f3a9baf6b1578089fe9356cd85..b4bf91043b4a1e56867bde8ad6d3e4b0f76fd957 100644
--- a/web/content/docs/devguide/advanced/compiler-cache/index.md
+++ b/web/content/docs/devguide/advanced/compiler-cache/index.md
@@ -13,7 +13,7 @@ aliases = ["/docs/devguide/advanced/using-ccache"]
 
 ## Introduction
 
-A compiler cache speeds up compilation times by caching object files and reusing them on subsequent builds. This even works for complete rebuilds (i.e. deleting the full build-directory). The compiler cache [ccache](https://ccache.samba.org) is automatically used when it is found by CMake.
+A compiler cache speeds up compilation times by caching object files and reusing them on subsequent builds. This even works for complete rebuilds (i.e. deleting the full build-directory). The compiler cache [Ccache](https://ccache.samba.org) is automatically used when it is found by CMake.
 
 <div class='linux'>
 
diff --git a/web/content/docs/devguide/advanced/configuration-options/index.md b/web/content/docs/devguide/advanced/configuration-options/index.md
index 6903f10db8207057028b0c0f42acd03591419a92..2772e1b1b2bb147e481daa2dd20ddeb048c455a7 100644
--- a/web/content/docs/devguide/advanced/configuration-options/index.md
+++ b/web/content/docs/devguide/advanced/configuration-options/index.md
@@ -22,12 +22,12 @@ CMake switches to enable / disable parts of OGS.
 - `OGS_BUILD_TESTING` - Builds the test executables. *Defaults* to *ON*.
 - `OGS_BUILD_UTILS` - Builds several utilities.
 - `OGS_BUILD_PROCESS_X` - For enabling/disabling compilation of process `X`.
-  Run the CMake-Gui / ccmake to see a list of processes.
+  Run the CMake-GUI / `ccmake` to see a list of processes.
 - `OGS_BUILD_PROCESSES` - A `;`-separated list specifying processes to build, e.g. `-DOGS_BUILD_PROCESSES="HT;LIE"`. Can be set to *ON* which means all processes are built or can be set to *OFF* to disable all processes. **Attention:** Setting this variable overrides individual `OGS_BUILD_PROCESS_X`-variables! This option is mainly used for CI and automation. Also the value of this variable is not cached.
 
 ### Debugging
 
-- `CMAKE_BUILD_TYPE` - Defaults to `Debug` which builds with debugging infos, set to `Release` for an optimized build.
+- `CMAKE_BUILD_TYPE` - Defaults to `Debug` which builds with debugging information, set to `Release` for an optimized build.
 - `OGS_PROFILE` - Builds with profiling flags (`-pg`).
 - `OGS_CMAKE_DEBUG` - Prints out the values of all defined CMake variables at CMake configuration time.
 
@@ -37,7 +37,7 @@ CMake switches to enable / disable parts of OGS.
 
 ### Testing
 
-- `OGS_COVERAGE` - Enables code coverage measurements with gcov/lcov. TODO
+- `OGS_COVERAGE` - Enables code coverage measurements with `gcov` / `lcov`. TODO
 
 ### Advanced options
 
@@ -46,7 +46,7 @@ CMake switches to enable / disable parts of OGS.
 - `OGS_CPU_ARCHITECTURE` - Optimizes for the given CPU architecture see [-march](https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)-flag. Defaults to `native`. For redistributable binaries set to `generic` on Linux and `core2` on Mac OS. Can be disabled when set to `OFF`.
 - `CMAKE_LIBRARY_SEARCH_PATH` - Additional library installation path, e.g. `/opt/local` or `C:/libs`
 - `OGS_DEPENDENCY_VERSIONS` - Overwrite individual entries in `web/data/versions.json`. Should be quoted and `;`-separated, e.g.: `-DOGS_DEPENDENCY_VERSIONS="minimum_version.petsc=3.16.2;ctest.large_runtime=120"`.
-- `OGS_USE_MKL` - Enables MKL support. Requires MKL to be installed on the system.[^mkl] A CMake or environment variable `MKLROOT` or `MKL_DIR` has to point to the MKL installation directory. To enable 64-bit array indices in MKL add `-DMKL_USE_interface=ilp64` on the first CMake run (with a clean CMake cache) but this seems [not supported by Eigen](https://eigen.tuxfamily.org/dox/TopicUsingIntelMKL.html).
+- `OGS_USE_MKL` - Enables MKL support. Requires MKL to be installed on the system.[^MKL] A CMake or environment variable `MKLROOT` or `MKL_DIR` has to point to the MKL installation directory. To enable 64-bit array indices in MKL add `-DMKL_USE_interface=ilp64` on the first CMake run (with a clean CMake cache) but this seems [not supported by Eigen](https://eigen.tuxfamily.org/dox/TopicUsingIntelMKL.html).
 - `OGS_USE_PETSC_MKL_EIGEN_OPENMP` - Also enables OpenMP multithreading when PETSc and MKL is used. This pulls in another OpenMP implementation besides the Intel MKL OpenMP. **Experimental feature!**
 
-[^mkl]: The `mkl_link_tool` (part of the MKL installation) is used for setting up necessary compiler flags. It is a 32-bit executable. On Arch Linux you need to enable the [multilib-repository](https://wiki.archlinux.org/title/official_repositories#Enabling_multilib) and then install the package `lib32-gcc-libs` (otherwise you may get this error when trying to run it: `mkl_link_tool: No such file or directory`) On other Linux distributions you have to install the package `lib32stdc++6` (Ubuntu / Debian) or `lib32stdc++6` (yum-based)! On Windows please also install the *Intel oneAPI Threading Building Blocks* during installation!
+[^MKL]: The `mkl_link_tool` (part of the MKL installation) is used for setting up necessary compiler flags. It is a 32-bit executable. On Arch Linux you need to enable the [multilib-repository](https://wiki.archlinux.org/title/official_repositories#Enabling_multilib) and then install the package `lib32-gcc-libs` (otherwise you may get this error when trying to run it: `mkl_link_tool: No such file or directory`) On other Linux distributions you have to install the package `lib32stdc++6` (Ubuntu / Debian) or `lib32stdc++6` (yum-based)! On Windows please also install the *Intel oneAPI Threading Building Blocks* during installation!
diff --git a/web/content/docs/devguide/advanced/gitlab-migration/index.md b/web/content/docs/devguide/advanced/gitlab-migration/index.md
index 5a5909a2b1cda76b13a156b0b3d21fd537b715c3..136a8935a2d5020a1f75b568707999fe31606c15 100644
--- a/web/content/docs/devguide/advanced/gitlab-migration/index.md
+++ b/web/content/docs/devguide/advanced/gitlab-migration/index.md
@@ -29,7 +29,7 @@ git commit -m "Converted LFS files to plain git."
 Now you have to squash this conversion commit into your original commit which added the files as Git LFS files. In result your branch history should and **must not** have any Git LFS files! Otherwise GitLab will reject the push!
 </div>
 
-When you are done migrating your branches you need to disable Git LFS in your local repo:
+When you are done migrating your branches you need to disable Git LFS in your local repository:
 
 ```bash
 git lfs uninstall --local
@@ -41,9 +41,9 @@ git lfs uninstall --local
 
 This creates a new fork under your account with the URL `https://gitlab.opengeosys.org/YOUR-USERNAME/ogs`.
 
-## Migrate your local repos to point to GitLab
+## Migrate your local repositories to point to GitLab
 
-You have to modify your git remotes to point to the new GitLab repos. Assuming the former official git repo remote is called `upstream`:
+You have to modify your git remotes to point to the new GitLab repositories. Assuming the former official git repository remote is called `upstream`:
 
 ```bash
 git remote set-url upstream https://gitlab.opengeosys.org/ogs/ogs.git
@@ -57,4 +57,4 @@ git remote set-url origin git@gitlab.opengeosys.org:YOUR-USERNAME/ogs.git
 
 ----
 
-Or you can clone a fresh repo by following the steps in [Get the source code]({{< ref "get-the-source-code.md" >}}).
+Or you can clone a fresh repository by following the steps in [Get the source code]({{< ref "get-the-source-code.md" >}}).
diff --git a/web/content/docs/devguide/advanced/log-and-debug-output/index.md b/web/content/docs/devguide/advanced/log-and-debug-output/index.md
index 1ee5f2fe22559164f1c03a5c43ea1b88e1e048d1..bc9c0e8b463c7a4e0258efd1fed9da32af235c9c 100644
--- a/web/content/docs/devguide/advanced/log-and-debug-output/index.md
+++ b/web/content/docs/devguide/advanced/log-and-debug-output/index.md
@@ -22,7 +22,7 @@ INFO("An information message...");
 DBUG("A debug message.");
 ```
 
-As arguments you can use the same functionality as in [fmt](https://fmt.dev)---a
+As arguments you can use the same functionality as in [{fmt}](https://fmt.dev)---a
 modern formatting library:
 
 ```cpp
diff --git a/web/content/docs/devguide/advanced/offline-build/index.md b/web/content/docs/devguide/advanced/offline-build/index.md
index 4ca870a953fced6ba42eeccd7ad00c2f65235719..a4cdcb8f197e70b7548b1fd1f3d4622cf478ca9c 100644
--- a/web/content/docs/devguide/advanced/offline-build/index.md
+++ b/web/content/docs/devguide/advanced/offline-build/index.md
@@ -11,13 +11,13 @@ weight = 1068
 
 OGS can be built on systems without internet connection when the following files can be made available on the system:
 
-- The ogs source code. Just archive the full ogs source code directory (also containing the git repository in `.git`) and unarchive on the target system.
+- The OGS source code. Just archive the full OGS source code directory (also containing the git repository in `.git`) and un-archive on the target system.
 - The [CPM]({{< ref "cpm.md" >}}) source cache. It can be obtained via the [OGS package registry](https://gitlab.opengeosys.org/ogs/ogs/-/packages/) (see below).
 - Optional: The external dependencies (for MFront, PETSc or LIS) source cache. It can be obtained via the [OGS package registry](https://gitlab.opengeosys.org/ogs/ogs/-/packages/)
 
 ## CPM
 
-The cpm source cache may change over time. To get the required file id check the `package_file_id` field in `web/data/versions.json`, e.g. with:
+The CPM source cache may change over time. To get the required file id check the `package_file_id` field in `web/data/versions.json`, e.g. with:
 
 ```bash
 $ jq -r '.cpm.package_file_id' web/data/versions.json
@@ -30,7 +30,7 @@ Now simply download the file with:
 curl https://gitlab.opengeosys.org/ogs/ogs/-/package_files/[insert ID here]/download --output cpm.tar.gz
 ```
 
-Unarchive the cpm cache into a directory. Configure OGS as usual but point to the extracted cpm cache:
+Un-archive the CPM cache into a directory. Configure OGS as usual but point to the extracted CPM cache:
 
 ```bash
 cmake --preset release -DCPM_SOURCE_DIR=./path/to/cpm
@@ -49,7 +49,7 @@ $ jq -r '.ext.cache_hash' web/data/versions.json
 
 On the [external dependencies package page](https://gitlab.opengeosys.org/ogs/ogs/-/packages/14) download the file `ext.tar.gz` with the specified version.
 
-Unarchive the external dependencies cache into a directory. Configure OGS as usual but point to the extracted external dependencies cache:
+Extract the external dependencies cache into a directory. Configure OGS as usual but point to the extracted external dependencies cache:
 
 ```bash
 cmake --preset release -DOGS_EXTERNAL_DEPENDENCIES_CACHE=./path/to/ext
diff --git a/web/content/docs/devguide/advanced/wsl/index.md b/web/content/docs/devguide/advanced/wsl/index.md
index 4b2596cc3681b389eaab03de184f7db1d72765d1..5c31f9de22eee1a3f644163ad0a67c89f88c9fc3 100644
--- a/web/content/docs/devguide/advanced/wsl/index.md
+++ b/web/content/docs/devguide/advanced/wsl/index.md
@@ -13,7 +13,7 @@ The [Windows Subsystem for Linux](https://en.wikipedia.org/wiki/Windows_Subsyste
 
 ## Setup
 
-- Install WSL2 by following [this guide](https://docs.microsoft.com/en-us/windows/wsl/install-win10). **Important:** Choose **Ubuntu 20.04 LTS** as the Linux distribution. Other distros may not have a sufficient compiler.
+- Install WSL2 by following [this guide](https://docs.microsoft.com/en-us/windows/wsl/install-win10). **Important:** Choose **Ubuntu 20.04 LTS** as the Linux distribution. Other distributions may not have a sufficient compiler.
 - Optional but recommended: Install the new [Windows Terminal](https://docs.microsoft.com/en-us/windows/terminal/get-started)
 - Follow the [developer guide for Linux]({{< ref "prerequisites.md" >}}) from now on.
 
diff --git a/web/content/docs/devguide/development-workflows/code-format/index.md b/web/content/docs/devguide/development-workflows/code-format/index.md
index 18f1edf82532ce82a4d2b8233afa6c90b8d89c55..056b904232e893c76d4f2b9efce2e03e1afe11bd 100644
--- a/web/content/docs/devguide/development-workflows/code-format/index.md
+++ b/web/content/docs/devguide/development-workflows/code-format/index.md
@@ -41,9 +41,9 @@ Use [cmake-format](https://cmake-format.readthedocs.io/en/latest/cmake-format.ht
 
 - [Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=cheshirekow.cmake-format)
 
-The current style is defined in [.cmake-format.yaml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/.cmake-format.yaml).
+The current style is defined in [`.cmake-format.yaml`](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/.cmake-format.yaml).
 
-On installation make sure to install with the yaml option:
+On installation make sure to install with the YAML option:
 
 ```bash
 pip install cmakelang[YAML]
diff --git a/web/content/docs/devguide/development-workflows/continuous-integration/index.md b/web/content/docs/devguide/development-workflows/continuous-integration/index.md
index 1c0535c97282f122c01ce7c86b0852fb4eae3d63..882bd260ba3417988347811f845a469f48713716 100644
--- a/web/content/docs/devguide/development-workflows/continuous-integration/index.md
+++ b/web/content/docs/devguide/development-workflows/continuous-integration/index.md
@@ -13,7 +13,7 @@ weight = 1016
 
 > [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration) (short **CI**) is the practice of merging all developer working copies to a shared mainline several times a day.
 
-So for every proposed change to the source code the following is done automatically:
+For every proposed change to the source code the following is done automatically:
 
 - Compilation of the changed code merged with the official source code is tested on a variety of platforms (Windows, Linux, Mac OS, different compilers)
 - A comprehensive [test suite]({{< ref "unit-testing.md" >}}) checks validity of the proposed changes
diff --git a/web/content/docs/devguide/development-workflows/development-ides/index.md b/web/content/docs/devguide/development-workflows/development-ides/index.md
index 6dabf8565080f72bff22f7793650fc17c054b063..fc3710f7082d1b57b8ea6ed43fa2224393fbb99f 100644
--- a/web/content/docs/devguide/development-workflows/development-ides/index.md
+++ b/web/content/docs/devguide/development-workflows/development-ides/index.md
@@ -24,7 +24,7 @@ Here is a **link list** without specific order:
 
 The steps to get things started with an IDE basically include **generating** the project files, **importing** them in the IDE and know where to **provide arguments** to the debugging binary.
 
-I will assume, that you have the sources (eg. checked out from github) and that they lie in the **source directory**
+I will assume, that you have the sources (e.g. checked out from GitHub) and that they lie in the **source directory**
 
 ```bash
 /home/user/ogs6/sources
@@ -53,7 +53,7 @@ __________
     cmake ../sources/
     ```
 
-3. Start gdb in graphical mode, without license info (quiet) and with arguments:
+3. Start GDB in graphical mode, without license info (quiet) and with arguments:
 
     ```bash
     gdb -tui -q --args ./bin/ogs ./path/to/BenchmarkName.prj
@@ -74,7 +74,7 @@ Choose "Eclipse IDE for C/C++ Developers"
 ![Eclipse screenshot](eclipse.png)
 
 ### Import Code
-
+<!-- vale off -->
 1. CD to the build directory
 2. Generate project files with CMake:
 
@@ -92,7 +92,7 @@ Choose "Eclipse IDE for C/C++ Developers"
     ```
 
 7. Start debugging...
-
+<!-- vale on -->
 Documentation: <https://wiki.eclipse.org/Main_Page>
 
 __________
@@ -116,7 +116,7 @@ The latter includes already plugins for Fortran, in case you want to cross-compi
     cmake -G "CodeBlocks - Unix Makefiles" ../sources/
     ```
 
-3. *Open an existing project* and choose before created .cbp file
+3. *Open an existing project* and choose before created `.cbp` file
 4. Choose your compilation target
 5. Give arguments: *Project - Set Programs' Arguments*, select correct target and add *Program arguments* in the bottom
 
@@ -163,7 +163,7 @@ __________
 
 Download: <https://www.jetbrains.com/clion/>
 
-![Clion screenshot](clion.png)
+![CLion screenshot](clion.png)
 
 ### Import project
 
diff --git a/web/content/docs/devguide/development-workflows/gitlab/index.md b/web/content/docs/devguide/development-workflows/gitlab/index.md
index cb02160474a9e465d059c8e8ce7e06ba7be0054b..4ec46fbe7d783508b422cf415389deb337a78fd0 100644
--- a/web/content/docs/devguide/development-workflows/gitlab/index.md
+++ b/web/content/docs/devguide/development-workflows/gitlab/index.md
@@ -11,16 +11,16 @@ weight = 1012
 
 ## Introduction
 
-[GitLab](https://gitlab.com) is a web-based development and collaboration tool similar to [GitHub](https://github.com). We self-host GitLab at <https://gitlab.opengeosys.org> and migrated our development workflows from GitHub in June 2020. Development takes place in the [ogs-group](https://gitlab.opengeosys.org/ogs) and the authoritative repository is at [ogs/ogs](https://gitlab.opengeosys.org/ogs/ogs).
+[GitLab](https://gitlab.com) is a web-based development and collaboration tool similar to [GitHub](https://github.com). We self-host GitLab at <https://gitlab.opengeosys.org> and migrated our development workflows from GitHub in June 2020. Development takes place in the [`ogs`-group](https://gitlab.opengeosys.org/ogs) and the authoritative repository is at [`ogs/ogs`](https://gitlab.opengeosys.org/ogs/ogs).
 
 ## Setup an account
 
-- Creating a GitLab account can be done by simply using your existing GitHub account: click the GitHub logo (octocat) on the [Gitlab sign-in page](https://gitlab.opengeosys.org/users/sign_in)
+- Creating a GitLab account can be done by simply using your existing GitHub account: click the GitHub logo on the [GitLab sign-in page](https://gitlab.opengeosys.org/users/sign_in)
   ![GitLab login page](gitlab-login.png)
   - You will be redirected to GitHub (please login there) and asked for authorization.
   - Your new user account will be blocked at first, please let us know we will unblock it
 
-## Setup a password for cloning over https
+## Setup a password for cloning over HTTPS
 
 To clone a repository via `https://`-protocol you need to [set up an account password](https://gitlab.opengeosys.org/-/profile/password/edit) and use this during `git clone https://...`.
 
diff --git a/web/content/docs/devguide/development-workflows/setup-fork/index.md b/web/content/docs/devguide/development-workflows/setup-fork/index.md
index 8c700957c7de371124bb96cb99b0bbba598ba473..e66c8a8d9dfc0d991c7e53d72b2d5f65734917b5 100644
--- a/web/content/docs/devguide/development-workflows/setup-fork/index.md
+++ b/web/content/docs/devguide/development-workflows/setup-fork/index.md
@@ -22,15 +22,19 @@ Git is very flexible in organizing a distributed development team. We use a so c
 
 The following explanation is taken from an [in-depth article](https://www.atlassian.com/git/tutorials/comparing-workflows#!workflow-forking) on that model:
 
+<!-- vale off -->
+
 > Instead of using a single server-side repository to act as the *central* codebase, it gives every developer a server-side repository. This means that each contributor has not one, but two Git repositories: a private local one and a public server-side one.
 >
 > The main advantage of the Forking Workflow is that contributions can be integrated without the need for everybody to push to a single central repository. Developers push to their own server-side repositories, and only the project maintainer can push to the official repository. This allows the maintainer to accept commits from any developer without giving them write access to the official codebase.
 >
-> The result is a distributed workflow that provides a flexible way for large, organic teams (including untrusted third-parties) to collaborate securely. This also makes it an ideal workflow for open source projects.
+> The result is a distributed workflow that provides a flexible way for large, organic teams (including not trusted third-parties) to collaborate securely. This also makes it an ideal workflow for open source projects.
 >
 > <cite><a href="https://www.atlassian.com/git/tutorials/comparing-workflows#!workflow-forking">www.atlassian.com/git/tutorials/comparing-workflows#!workflow-forking</a> </cite>
 >
 
+<!-- vale on -->
+
 The workflow is summarized in the following image from the [GitHub blog](https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows):
 ![Git workflow](https://cloud.githubusercontent.com/assets/1319791/8943755/5dcdcae4-354a-11e5-9f82-915914fad4f7.png)
 
@@ -71,7 +75,7 @@ This creates a new folder `ogs` in your current working directory with the OGS s
 
 <div class='note'>
 
-The `--filter=blob:limit=100k`-parameter instructs git to only fetch files which are smaller than 100 Kbyte. Larger files (e.g. benchmark files, images, PDFs) are fetched on-demand only. This happens automatically and [is a replacement for the previous Git LFS tracked files](https://github.com/ufz/ogs/issues/2961). Requires at least **git 2.22**!
+The `--filter=blob:limit=100k`-parameter instructs git to only fetch files which are smaller than 100 Kilobyte. Larger files (e.g. benchmark files, images, PDFs) are fetched on-demand only. This happens automatically and [is a replacement for the previous Git LFS tracked files](https://github.com/ufz/ogs/issues/2961). Requires at least **git 2.22**!
 
 </div>
 
@@ -188,6 +192,10 @@ If your work is done submit a [merge request](https://gitlab.opengeosys.org/ogs/
 Again this triangular workflow is summarized with this picture:
 ![Workflow visualization](https://cloud.githubusercontent.com/assets/1319791/8943755/5dcdcae4-354a-11e5-9f82-915914fad4f7.png)
 
+<!-- vale off -->
+
 > […] the Forking Workflow requires two remotes—one for the official repository, and one for the developer’s personal server-side repository. While you can call these remotes anything you want, a common convention is to use origin as the remote for your forked repository […] and upstream for the official repository.
 >
 > <cite><a href="https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow">www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow</a> </cite>
+
+<!-- vale on -->
diff --git a/web/content/docs/devguide/development-workflows/web-docs/index.md b/web/content/docs/devguide/development-workflows/web-docs/index.md
index 5ff55ebba18cc24511e0212e45ad2b6ccf087ca1..8f969fd5b505f282d0232b8a87e656bac2e1994a 100644
--- a/web/content/docs/devguide/development-workflows/web-docs/index.md
+++ b/web/content/docs/devguide/development-workflows/web-docs/index.md
@@ -24,7 +24,7 @@ aliases = ["/docs/devguide/documentation/introduction/"]
 ## Getting started
 
 - Inside the source-directory `ogs/web`:
-  - Run `yarn` **and** `yarn build` once (this will install required css and js packages)
+  - Run `yarn` **and** `yarn build` once (this will install required CSS and JavaScript packages)
   - Run `hugo server`
   - Open [http://localhost:1313](http://localhost:1313)
 
@@ -57,7 +57,7 @@ content/
 │   │   └── index.md
 ```
 
-This page will be available at the url `/docs/my-post/` and the content of the page is in `index.md`.
+This page will be available at the URL `/docs/my-post/` and the content of the page is in `index.md`.
 
 </div>
 
diff --git a/web/content/docs/devguide/environments/docker/index.md b/web/content/docs/devguide/environments/docker/index.md
index 70d7f85e3087668fec51a11887cedfd5fe083620..091d5ade6c9478741c7a1ece9ab3b10a877207d0 100644
--- a/web/content/docs/devguide/environments/docker/index.md
+++ b/web/content/docs/devguide/environments/docker/index.md
@@ -13,15 +13,17 @@ aliases = ["/docs/devguide/advanced/docker"]
 
 ## Introduction
 
+<!-- vale off -->
 > Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in.
 >
 > <cite>[www.docker.com/whatisdocker](https://www.docker.com/whatisdocker)</cite>
+<!-- vale on -->
 
 See the [docs](https://docs.docker.com) for installation instructions (if you are on Windows we highly recommend the [Docker Desktop WSL 2 backend](https://docs.docker.com/docker-for-windows/wsl/)).
 
 ## Images
 
-Docker images can be created by [Dockerfiles](https://docs.docker.com/reference/builder/) which can be stacked and thus form a directed graph. OGS-6 image definitions are created with [ufz/ogs-container-maker](https://github.com/ufz/ogs-container-maker). Built images can be found at the [GitLab Container Registry](https://gitlab.opengeosys.org/ogs/ogs/container_registry). You can also [create images from your local source code](https://github.com/ufz/ogs-container-maker#build-ogs-from-local-git-repo).
+Docker images can be created by [Dockerfiles](https://docs.docker.com/reference/builder/) which can be stacked and thus form a directed graph. OGS-6 image definitions are created with [`ufz/ogs-container-maker`](https://github.com/ufz/ogs-container-maker). Built images can be found at the [GitLab Container Registry](https://gitlab.opengeosys.org/ogs/ogs/container_registry). You can also [create images from your local source code](https://github.com/ufz/ogs-container-maker#build-ogs-from-local-git-repo).
 
 To build an image by yourself create a Dockerfile:
 
diff --git a/web/content/docs/devguide/environments/redistributable-builds/index.md b/web/content/docs/devguide/environments/redistributable-builds/index.md
index 01580b7e3a9e273c2140fe99bf4928a969ea3837..019c25ac39f26e540d3a5d42ced33b9ddb4ccc39 100644
--- a/web/content/docs/devguide/environments/redistributable-builds/index.md
+++ b/web/content/docs/devguide/environments/redistributable-builds/index.md
@@ -34,17 +34,17 @@ If a binary runs on a different machine depends on a lot of factors. The followi
 
 ### Default compiler flags
 
-- `-march=native`: Optimizes for current cpu
+- `-march=native`: Optimizes for current CPU
 
 ### CMake options
 
 #### For redistribution
 
-- `OGS_CPU_ARCHITECTURE`: set to `generic` for good balance between optimization and portability; set to `core2` for maximum portability, more info on [gcc docs](https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mtune-15)
+- `OGS_CPU_ARCHITECTURE`: set to `generic` for good balance between optimization and portability; set to `core2` for maximum portability, more info on [GCC docs](https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mtune-15)
 
 #### For optimization
 
-- `OGS_CPU_ARCHITECTURE`: tot to `native` for best optimization for your current cpu, possible values are [listed here](https://stackoverflow.com/a/25095818/80480), more info on [gcc docs](https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mtune-15)
+- `OGS_CPU_ARCHITECTURE`: tot to `native` for best optimization for your current CPU, possible values are [listed here](https://stackoverflow.com/a/25095818/80480), more info on [GCC docs](https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mtune-15)
 
 </div>
 
@@ -56,7 +56,7 @@ See Linux-tab!
 
 Try to use static libraries as much as possible. For OGS itself use `BUILD_SHARED_LIBS=OFF`, which already defaults to `OFF`.
 
-Third-party libraries installed via the systems package package manager are often provided as shared libraries. You may want to use [Conan]({{< ref "conan-package-manager.md" >}}) which provides lots of libraries (e.g. VTK) as static libs.
+ package manager are often provided as shared libraries. You may want to use [Conan]({{< ref "conan-package-manager.md" >}}) which provides lots of libraries (e.g. VTK) as static libraries.
 
 ## Package the build
 
diff --git a/web/content/docs/devguide/environments/singularity/index.md b/web/content/docs/devguide/environments/singularity/index.md
index b61f30d039bebbaeaf929e4c1e87b5dcc974bfe6..5dd0eb1fbe0cc9d4726999735b3e0c8532a94e81 100644
--- a/web/content/docs/devguide/environments/singularity/index.md
+++ b/web/content/docs/devguide/environments/singularity/index.md
@@ -66,13 +66,13 @@ ninja
 
 ### Run OGS inside a Container (called from outside)
 
-Once ogs executable is built it can be called from **outside** the container:
+Once OGS executable is built it can be called from **outside** the container:
 
 ```bash
 singularity exec gcc_latest.sif build/bin/ogs some/path/project.prj
 ```
 
-This starts the container, mounts your home directory inside the container, passes the current working directory and runs the ogs executable (which is in your home directory which is mounted inside the container) with the passed project file. Everything works as expected and is transparent to the user. When ogs finishes the container stops and you returns to the host system.
+This starts the container, mounts your home directory inside the container, passes the current working directory and runs the OGS executable (which is in your home directory which is mounted inside the container) with the passed project file. Everything works as expected and is transparent to the user. When OGS finishes the container stops and you returns to the host system.
 
 ## Container generator
 
diff --git a/web/content/docs/devguide/environments/working-on-eve/index.md b/web/content/docs/devguide/environments/working-on-eve/index.md
index 117454c723e594158720d08880568f43deda4468..eaa01b0f2d51536e44fc1e1d4dafa3be43abd3c6 100644
--- a/web/content/docs/devguide/environments/working-on-eve/index.md
+++ b/web/content/docs/devguide/environments/working-on-eve/index.md
@@ -33,7 +33,7 @@ ml git/2.20.1
 
 ## Run OGS within a container
 
-Eve has [Singularity](https://www.sylabs.io/singularity) container runtime installed so you can simply download a prebuilt container and run OGS inside it. See the [user guide]({{< ref "container" >}}) for more infos.
+Eve has [Singularity](https://www.sylabs.io/singularity) container runtime installed so you can simply download a prebuilt container and run OGS inside it. See the [user guide]({{< ref "container" >}}) for more information.
 
 ## Build OGS-6
 
diff --git a/web/content/docs/devguide/getting-started/build-configuration/index.md b/web/content/docs/devguide/getting-started/build-configuration/index.md
index b2f672cebd472d0b7ea5a978a5d8ae39ccb74fe3..44679b30b9aec34f9d74a6ed045077da813e0112 100644
--- a/web/content/docs/devguide/getting-started/build-configuration/index.md
+++ b/web/content/docs/devguide/getting-started/build-configuration/index.md
@@ -28,6 +28,8 @@ We provide CMake configuration presets defined in [CMakePresets.json](https://gi
 
 ### Available CMake presets
 
+<!-- vale off -->
+
 |               | Ninja[^1]     | Visual Studio    |
 | ------------- | ------------- | ---------------- |
 | CLI Release   | release       | msvc-release     |
@@ -37,6 +39,8 @@ We provide CMake configuration presets defined in [CMakePresets.json](https://gi
 | PETSc Release | release-petsc | -                |
 | PETSc Debug   | debug-petsc   | -                |
 
+<!-- vale on -->
+
 [^1]: Requires the `ninja`-tool. See [install instructions]({{< ref "prerequisites.md#optional-install-ninja" >}}).
 
 ### Configure with a preset
@@ -98,7 +102,7 @@ cmake --preset=release
 
 #### <i class="far fa-exclamation-triangle"></i> Multi-configuration with Conan and Visual Studio
 
-With Conan one build directory corresponds to one configuration. If you want to have e.g. a release and a debug build you need to create two build directories. This is nothing new to Linux / GCC user but differs to Visual Studios default behavior having just one build-folder / project with different configurations. A typical Visual Studio setup with both Release and Debug configs would be initialized as follows:
+With Conan one build directory corresponds to one configuration. If you want to have e.g. a release and a debug build you need to create two build directories. This is nothing new to Linux / GCC user but differs to Visual Studios default behavior having just one build-folder / project with different configurations. A typical Visual Studio setup with both Release and Debug configurations would be initialized as follows:
 
 ```bash
 cmake --preset=msvc-release
@@ -148,7 +152,7 @@ CMake comes with a graphical tool called **cmake-gui**. You can find it in the *
 
 <div class='linux'>
 
-A more convenient way of running cmake on the command line is to use the `ccmake` tool. This is a shell tool but with some graphical user interface. To use it just run `ccmake` instead of `cmake`:
+A more convenient way of running CMake on the command line is to use the `ccmake` tool. This is a shell tool but with some graphical user interface. To use it just run `ccmake` instead of `cmake`:
 
 ```bash
 ccmake --preset=release
diff --git a/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md b/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md
index 8f207d64dbcde1244813043f11a404e152f52153..2d4e2f23f5ff44ffffc6e5d2f50f0632aaa3d57b 100644
--- a/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md
+++ b/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md
@@ -75,13 +75,13 @@ is the default compiler. For such platforms, C/C++ compiler is better to
 when `OGS_USE_PETSC` is switched on, the compilation will fail with missed
 library error.
 
-For simplicity, you can first run cmake with MPI C/C++ compiler specified. For example:
+For simplicity, you can first run CMake with MPI C/C++ compiler specified. For example:
 
 ```bash
 cmake [path to source code] [-GNinja] -DOGS_USE_PETSC=ON -DCMAKE_C_COMPILER=/usr/bin/mpicc -DCMAKE_CXX_COMPILER=/usr/bin/mpic++
 ```
 
-and then use *ccmake* or *cmake-gui* to configure further more CMake options.
+and then use `ccmake` or *cmake-gui* to configure further more CMake options.
 
 The other basic build configurations are the same as that described in [Build configuration]({{<ref
 "build-configuration">}}).
diff --git a/web/content/docs/devguide/getting-started/build/index.md b/web/content/docs/devguide/getting-started/build/index.md
index d0758b4d5c80cdabeb3d0102ea998d46dc65d6e4..bca60ff226c6394a8f86081e6980e9e1cd254331 100644
--- a/web/content/docs/devguide/getting-started/build/index.md
+++ b/web/content/docs/devguide/getting-started/build/index.md
@@ -17,7 +17,7 @@ weight = 1005
 
 Open the OGS.sln (in the build directory) either by double-clicking it in the file browser or opening in Visual Studio via **File / Open / Project**.
 
-On the project explorer right-click on **ogs** or **ogs-gui** and choose **Set as startup project**. Then press <kbd>F5</kbd> or click the green arrow to build and start the project.
+On the project explorer right-click on **`ogs`** or **`ogs-gui`** and choose **Set as startup project**. Then press <kbd>F5</kbd> or click the green arrow to build and start the project.
 
 #### About Visual Studio startup projects
 
@@ -25,7 +25,7 @@ The reason for this is that you can have only one sub-project of your Visual Stu
 
 ### How to work with CMake and Visual Studio
 
-You can work normally in Visual Studio but remember that you have to make project changes in the `CMakeLists.txt`-file and not inside Visual Studio. So you can add a new source file within Visual Studios File menu but you have to add that file also to the CMake file. Every time you change a `CMakeLists.txt` and you build the project a new CMake run is automatically invoked. After that Visual Studio informs you that the project files were changed and it reloads them.
+You can work normally in Visual Studio but remember that you have to make project changes in the `CMakeLists.txt`-file and not inside Visual Studio. You can add a new source file within Visual Studios File menu but you have to add that file also to the CMake file. Every time you change a `CMakeLists.txt` and you build the project a new CMake run is automatically invoked. After that Visual Studio informs you that the project files were changed and it reloads them.
 </div>
 
 <div class='linux'>
@@ -70,7 +70,7 @@ See Linux-tab!
 
 ## Waiting
 
-So now the build process is running... This can take some time because maybe there are external libraries which get automatically downloaded and compiled. This step is only done once per build directory, so subsequent builds will be much faster. See [this]({{< ref "cpm.md" >}}) for more.
+Now the build process is running... This can take some time because maybe there are external libraries which get automatically downloaded and compiled. This step is only done once per build directory, so subsequent builds will be much faster. See [this]({{< ref "cpm.md" >}}) for more.
 
 ## Finished
 
diff --git a/web/content/docs/devguide/getting-started/get-the-source-code/index.md b/web/content/docs/devguide/getting-started/get-the-source-code/index.md
index eabaffbf9bcd4acf1556282a5c0c6c772f071989..853717b193e75e1392e8134f8778216b71af4c08 100644
--- a/web/content/docs/devguide/getting-started/get-the-source-code/index.md
+++ b/web/content/docs/devguide/getting-started/get-the-source-code/index.md
@@ -32,7 +32,7 @@ tar xf ogs-master.tar.gz
 
 ## Option: Clone the source code repository with Git
 
-First you need to get the clone url:
+First you need to get the clone URL:
 
 ![Getting the git clone URL from the GitLab web interface](git-url.png)
 
@@ -44,6 +44,6 @@ git clone --filter=blob:limit=100 https://gitlab.opengeosys.org/ogs/ogs.git
 
 <div class='note'>
 
-The `--filter=blob:limit=100k`-parameter instructs git to only fetch files which are smaller than 100 Kbyte. Larger files (e.g. benchmark files, images, PDFs) are fetched on-demand only. This happens automatically and [is a replacement for the previous Git LFS tracked files](https://github.com/ufz/ogs/issues/2961). Requires at least **git 2.22**!
+The `--filter=blob:limit=100k`-parameter instructs git to only fetch files which are smaller than 100 Kilobyte. Larger files (e.g. benchmark files, images, PDFs) are fetched on-demand only. This happens automatically and [is a replacement for the previous Git LFS tracked files](https://github.com/ufz/ogs/issues/2961). Requires at least **git 2.22**!
 
 </div>
diff --git a/web/content/docs/devguide/getting-started/prerequisites/index.md b/web/content/docs/devguide/getting-started/prerequisites/index.md
index 87b1d051f4e8a70bc613135fd7d1c631380b906e..b9b81f0763c34fe2fa6b1c6605adfb668b802e77 100644
--- a/web/content/docs/devguide/getting-started/prerequisites/index.md
+++ b/web/content/docs/devguide/getting-started/prerequisites/index.md
@@ -57,13 +57,13 @@ On Debian-based (we recommend using Ubuntu {{< dataFile "versions.tested_version
 sudo apt install build-essential
 ```
 
-You need to have at least **gcc {{< dataFile "versions.minimum_version.gcc" >}}** which you can check with `gcc --version` (Ubuntu {{< dataFile "versions.tested_version.ubuntu" >}} has already version 11).
+You need to have at least **GCC {{< dataFile "versions.minimum_version.gcc" >}}** which you can check with `gcc --version` (Ubuntu {{< dataFile "versions.tested_version.ubuntu" >}} has already version 11).
 
 <div class='note'>
 
 ### Install the required compiler on older Ubuntu versions
 
-If you are on an older Ubuntu version you can install a newer compiler from the `ubuntu-toolchain-r/test`-repository (with the following steps e.g. you can install gcc 10.3.0 on Ubuntu 20.04):
+If you are on an older Ubuntu version you can install a newer compiler from the `ubuntu-toolchain-r/test`-repository (with the following steps e.g. you can install GCC 10.3.0 on Ubuntu 20.04):
 
 ```bash
 sudo apt-get install software-properties-common
@@ -106,7 +106,7 @@ Now also install the [Homebrew](http://brew.sh) package manager:
 brew doctor
 ```
 
-The Homebrew package manager is needed for installing other libraries and packages. It is just like a linux package manager.
+The Homebrew package manager is needed for installing other libraries and packages. It is just like a Linux package manager.
 </div>
 
 ## Step: Install Git
@@ -206,7 +206,7 @@ git config --global http.proxy http://yourproxy.example.com
 
 Install CMake via Kitware's APT Repository by [following their instructions](https://apt.kitware.com/).
 
-For other linux distributions you want to use your distributions package manager, [pip](https://pypi.org/project/cmake/) or [snap](https://snapcraft.io/cmake).
+For other Linux distributions you want to use your distributions package manager, [pip](https://pypi.org/project/cmake/) or [snap](https://snapcraft.io/cmake).
 </div>
 
 <div class='mac'>
@@ -282,7 +282,7 @@ brew install python
 
 ## Optional: Install Qt for the Data Explorer
 
-Use [Another Qt installer(aqt)](https://github.com/miurahr/aqtinstall) for installing the Qt binaries to some path on your machine:
+Use [Another Qt installer (`aqt`)](https://github.com/miurahr/aqtinstall) for installing the Qt binaries to some path on your machine:
 
 <div class='win'>
 
@@ -348,6 +348,6 @@ Conan version {{< dataFile "versions.minimum_version.conan" >}}
 
 <div class='note'>
 
-**Advanced usage:** You can also have Conan auto-installed when using the CMake-option `OGS_USE_CONAN=auto`. See the page on [Python environment]({{< ref "python-env.md" >}}) for details.
+**Advanced usage:** You can also have Conan auto-installed when using the CMake-option `OGS_USE_CONAN=auto`. See the page on [Python environment]({{% ref "python-env.md" %}}) for details.
 
 </div>
diff --git a/web/content/docs/devguide/packages/conan-package-manager/index.md b/web/content/docs/devguide/packages/conan-package-manager/index.md
index b626a4a52413083aa25b9d683336456a00f509a6..84ed8e6e1b828d362495252d55bbd23a745bff02 100644
--- a/web/content/docs/devguide/packages/conan-package-manager/index.md
+++ b/web/content/docs/devguide/packages/conan-package-manager/index.md
@@ -29,7 +29,7 @@ Per default when Conan is enabled it will try to fetch prebuilt binaries from th
 - `missing` - Default, only builds packages which are not available as a prebuilt binary for the current configuration
 - `all` - Builds all packages locally
 - `never` - Builds no package locally
-- `[a list of libraries to build]`, e.g. `"petsc;tfel"`. For names see [ConanSetup.cmake](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/scripts/cmake/ConanSetup.cmake). Make sure to set this back to 'never' after the libs have been built. Otherwise it would rebuild the libs on the next CMake run.
+- `[a list of libraries to build]`, e.g. `"petsc;tfel"`. For names see [`ConanSetup.cmake`](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/scripts/cmake/ConanSetup.cmake). Make sure to set this back to 'never' after the libraries have been built. Otherwise it would rebuild the libraries on the next CMake run.
 
 ### Conan environment
 
diff --git a/web/content/docs/devguide/packages/mfront/index.md b/web/content/docs/devguide/packages/mfront/index.md
index b6e4a29c5fd24ca9392e7abf8f99114acfa2922b..0e6c4ef90daec294127fb00b2b8077bb2592f567 100644
--- a/web/content/docs/devguide/packages/mfront/index.md
+++ b/web/content/docs/devguide/packages/mfront/index.md
@@ -13,15 +13,19 @@ MFront / TFEL support is enabled by the CMake-option `-DOGS_USE_MFRONT=ON` and c
 
 - system-wide,
 - in the user directory or
-- automatically inside the ogs build-directory.
+- automatically inside the OGS build-directory.
 
 ## System-wide install
 
-If you install it system-wide it will get picked up by CMake (when the `mfront`-executable is in the `PATH`). Make sure to install a compatible version! Currently OGS requires the TFEL branch [rliv-{{< dataFile "versions.minimum_version.tfel-rliv" >}}](https://github.com/thelfer/tfel/tree/rliv-{{< dataFile "versions.minimum_version.tfel-rliv" >}}). Check the CMake output for version information of MFront / TFEL.
+<!-- vale off -->
+
+If you install it system-wide it will get picked up by CMake (when the `mfront`-executable is in the `PATH`). Make sure to install a compatible version! Currently OGS requires the TFEL branch [rliv-{{< dataFile "versions.minimum_version.tfel-rliv" >}}](<https://github.com/thelfer/tfel/tree/rliv>-{{< dataFile "versions.minimum_version.tfel-rliv" >}}). Check the CMake output for version information of MFront / TFEL.
+
+<!-- vale on -->
 
 ## Installation in the user directory
 
-If you need another version of MFront / TFEL (e.g. for model development) as required for OGS one solution is to install MFront / TFEL in your user-directory with a version-suffix, see the [official documentation](http://tfel.sourceforge.net/install.html#sec:QuickUbuntu) for instructions! In this case you can use the mfront executable by using the binary name with the suffix, e.g. `mfront-4.0.0-dev` and OGS will automatically download and build a compatible MFront / TFEL version inside the build directory.
+If you need another version of MFront / TFEL (e.g. for model development) as required for OGS one solution is to install MFront / TFEL in your user-directory with a version-suffix, see the [official documentation](http://tfel.sourceforge.net/install.html#sec:QuickUbuntu) for instructions! In this case you can use the `mfront` executable by using the binary name with the suffix, e.g. `mfront-4.0.0-dev` and OGS will automatically download and build a compatible MFront / TFEL version inside the build directory.
 
 ## Automatic installation
 
diff --git a/web/content/docs/devguide/procedures/publish-a-release/index.md b/web/content/docs/devguide/procedures/publish-a-release/index.md
index ffec555b02d767f0331e41637180bfc332919c78..dc5d8a24902cbb5744cd962b47b489fbcae24ab7 100644
--- a/web/content/docs/devguide/procedures/publish-a-release/index.md
+++ b/web/content/docs/devguide/procedures/publish-a-release/index.md
@@ -13,7 +13,7 @@ weight = 1080
 
 - Update [merge request template](https://gitlab.opengeosys.org/ogs/ogs/edit) to point to a new changelog wiki page
 - Update `CHANGELOG.md` to point to new GitLab release
-- Create new web release page with generated artifact names and changelog (convert MR ids to urls: replace `!([0-9][0-9][0-9][0-9])` with `[!$1](https://gitlab.opengeosys.org/ogs/ogs/-/merge_requests/$1)` and `#([0-9][0-9][0-9][0-9])` with `[#$1](https://gitlab.opengeosys.org/ogs/ogs/-/issues/$1)`)
+- Create new web release page with generated artifact names and changelog (convert MR ids to URLs: replace `!([0-9][0-9][0-9][0-9])` with `[!$1](https://gitlab.opengeosys.org/ogs/ogs/-/merge_requests/$1)` and `#([0-9][0-9][0-9][0-9])` with `[#$1](https://gitlab.opengeosys.org/ogs/ogs/-/issues/$1)`)
 - Add a link to the (upcoming) Doxygen documentation for this tag in `Documentation/mainpage.dox.in` (with `v`-prefix)
 - Update `[docs-release]`-link in `README.md` to the new tag (with `v`-prefix)
 - Add a redirect in `scripts/doc/_redirects`
@@ -26,9 +26,11 @@ weight = 1080
 - Issue a scan on [Software Heritage Archive](https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://gitlab.opengeosys.org/ogs/ogs.git)
 - Create bugfix branch
   - Create new netlify site (in an empty directory)
+    <!-- vale off -->
     - `netlify init`
     - `# [ENTER]`
     - `# ogs-doxygen-v[TAG (- separated instead of .)]`
+    <!-- vale on -->
   - Create branch from `master` with name `v[TAG]` and push
 - Create a discourse announcement post
   - DOI badge
diff --git a/web/content/docs/devguide/testing/gitlab-ci/index.md b/web/content/docs/devguide/testing/gitlab-ci/index.md
index 5312b09dd2ff42fb62f20c582c3553472b0a7d50..64d4e487da0d9482f9fa6b3f39da285b30cd0a27 100644
--- a/web/content/docs/devguide/testing/gitlab-ci/index.md
+++ b/web/content/docs/devguide/testing/gitlab-ci/index.md
@@ -13,7 +13,7 @@ weight = 1022
 
 [GitLab CI](https://docs.gitlab.com/ee/ci/) is a powerful [Continuous Integration](../../development-workflows/continuous-integration) system integrated into GitLab.
 
-The tasks of the CI system are configured in [scripts inside the OGS source code](https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/scripts/ci). The entrypoint is defined in [.gitlab-ci.yml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/.gitlab-ci.yml). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a merge request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the merge request.
+The tasks of the CI system are configured in [scripts inside the OGS source code](https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/scripts/ci). The entrypoint is defined in [`.gitlab-ci.yml`](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/.gitlab-ci.yml). Scripting and versioning the configuration together with the source code is very powerful, e.g. if you introduce a new OGS CMake configuration in a merge request even the change of the CI jobs configuration or jobs environment (Docker container definition) can be part of the merge request.
 
 ## GitLab Pipeline
 
@@ -28,7 +28,7 @@ Some jobs run on native servers (e.g. on the `envinf[1,2,3]` Linux servers) and
 
 ## Automatic testing
 
-The master-branch of the the main repository as well as all merge requests on that repo are automatically tested. See [the pipelines page](https://gitlab.opengeosys.org/ogs/ogs/pipelines).
+The master-branch of the main repository as well as all merge requests on that repository are automatically tested. See [the pipelines page](https://gitlab.opengeosys.org/ogs/ogs/pipelines).
 
 ### Skip automatic testing
 
@@ -38,7 +38,7 @@ If you want to skip a pipeline run for a push add the `-o ci.skip` git push opti
 git push -o ci.skip
 ```
 
-Or add add `[ci skip]` to the commit message to skip the pipeline for this commit. Example:
+Or add `[ci skip]` to the commit message to skip the pipeline for this commit. Example:
 
 ```bash
 git commit -m "Added feature X [ci skip]"
diff --git a/web/content/docs/devguide/testing/test-data/index.md b/web/content/docs/devguide/testing/test-data/index.md
index 614b5d19320f9cb1510611b69e667d91b46f798f..de87cee77602548e41575ce4c7602a6bd4fcf6e9 100644
--- a/web/content/docs/devguide/testing/test-data/index.md
+++ b/web/content/docs/devguide/testing/test-data/index.md
@@ -26,7 +26,7 @@ AddTest(
 )
 ```
 
-Tests are then run with `ninja ctest` or for more verbose output with `ctest -VV` (you may also use other [ctest options](https://cmake.org/cmake/help/v3.4/manual/ctest.1.html)). If the checker has some errors they are displayed. `RUNTIME` specifies the typical runtime in seconds on an Intel Xeon E5-2680 v2 @ 2.80 GHz with 500 GiB RAM (`envinf1`). Tests with a `RUNTIME > {{< dataFile "versions.ctest.large_runtime" >}}` are considered `LARGE`-tests.
+Tests are then run with `ninja ctest` or for more verbose output with `ctest -VV` (you may also use other [`ctest` options](https://cmake.org/cmake/help/v3.4/manual/ctest.1.html)). If the checker has some errors they are displayed. `RUNTIME` specifies the typical runtime in seconds on an Intel Xeon E5-2680 v2 @ 2.80 GHz with 500 GiB RAM (`envinf1`). Tests with a `RUNTIME > {{< dataFile "versions.ctest.large_runtime" >}}` are considered `LARGE`-tests.
 
 The functionality is very flexible and more wrappers and checker can be added later on. e.g. for running some statistics on output files and comparing them with statistics from reference files.
 
@@ -41,7 +41,7 @@ ctest --preset release                          # equivalent to running `ninja c
 ctest --preset release -j 6 --label-regex Utils # run 6 tests in parallel which have a Utils label
 ```
 
-**To sum up:** from a clean source directory you can fully configure, build and test ogs with these 3 commands:
+**To sum up:** from a clean source directory you can fully configure, build and test OGS with these 3 commands:
 
 ```bash
 cmake --preset release
@@ -88,9 +88,9 @@ raise SystemExit()
 
 Add Python dependencies to `web/data/versions.json` (under `python/notebook_requirements`).
 
-### Run with ctest
+### Run with CTest
 
-Add to ctest with:
+Add to CTest with:
 
 ```cmake
 NotebookTest(NOTEBOOKFILE Notebooks/SimpleMechanics.ipynb RUNTIME 10)
diff --git a/web/content/docs/devguide/testing/unit-testing/index.md b/web/content/docs/devguide/testing/unit-testing/index.md
index 5cafd234d05cd72f7412cb9e103a9d6b289292a6..6573a8810d29fda10ff5cbd6be7d5a176e22a7bb 100644
--- a/web/content/docs/devguide/testing/unit-testing/index.md
+++ b/web/content/docs/devguide/testing/unit-testing/index.md
@@ -9,16 +9,16 @@ weight = 1021
     parent = "testing"
 +++
 
-## Introdution
+## Introduction
 
-[Unit testing](http://en.wikipedia.org/wiki/Unit_testing) can be used for testing small pieces of functionality. We use [googletest](https://code.google.com/p/googletest/wiki/V1_6_Primer) as our test framework.
+[Unit testing](http://en.wikipedia.org/wiki/Unit_testing) can be used for testing small pieces of functionality. We use [GoogleTest](https://code.google.com/p/googletest/wiki/V1_6_Primer) as our test framework.
 
 ## Running Tests
 
-Googletest is already included in the OGS source code. Running tests is as simple as building the `tests`-target.
+GoogleTest is already included in the OGS source code. Running tests is as simple as building the `tests`-target.
 
 {{< asciinema url="https://asciinema.org/a/249006" >}}
 
 ## Writing Tests
 
-All tests are located inside the *Tests*-directory in library-specific subfolders. To write a new test you simply create a new *.cpp*-file and use the googletest macros.
+All tests are located inside the *Tests*-directory in library-specific subfolders. To write a new test you simply create a new *.cpp*-file and use the GoogleTest macros.
diff --git a/web/content/docs/devguide/testing/workflow-testing/index.md b/web/content/docs/devguide/testing/workflow-testing/index.md
index f44e9bb114d008a530823728e0da16c447e39ce1..ac6d8798973e9f78916d2aa53f2500ee559d7a79 100644
--- a/web/content/docs/devguide/testing/workflow-testing/index.md
+++ b/web/content/docs/devguide/testing/workflow-testing/index.md
@@ -9,7 +9,7 @@ weight = 1024
     parent = "testing"
 +++
 
-## Introdution
+## Introduction
 
 We use the workflow manager [Snakemake](https://snakemake.readthedocs.io) to test workflows which consist of the execution of several steps which are based on each other.
 
@@ -25,7 +25,7 @@ We use the workflow manager [Snakemake](https://snakemake.readthedocs.io) to tes
 - [ExtractBoundary.smk](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Applications/Utils/ExtractBoundary.smk)
 - [VoxelGridFromLayers.smk](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Applications/Utils/VoxelGridFromLayers.smk)
 
-These example workflows [are added to ctest](https://gitlab.opengeosys.org/ogs/ogs/-/blob/540d0b454c9e3805a81f7c4a1b6ee7565be6845c/Applications/Utils/Tests.cmake#L302-315) as well:
+These example workflows [are added to CTest](https://gitlab.opengeosys.org/ogs/ogs/-/blob/540d0b454c9e3805a81f7c4a1b6ee7565be6845c/Applications/Utils/Tests.cmake#L302-315) as well:
 
 ```cmake
 if(SNAKEMAKE AND NOT OGS_USE_MPI)
diff --git a/web/content/docs/devguide/troubleshooting/build/index.md b/web/content/docs/devguide/troubleshooting/build/index.md
index 08ae88dbe2fe4da9ddf55cd64ee8ce1379549f3a..df7656baaad9f4778bbbc06333a062e30c5e9cc4 100644
--- a/web/content/docs/devguide/troubleshooting/build/index.md
+++ b/web/content/docs/devguide/troubleshooting/build/index.md
@@ -10,7 +10,7 @@ weight = 1073
     identifier = "build-troubleshooting"
 +++
 
-## Visual Studio out-of-heap or stackoverflow errors
+## Visual Studio out-of-heap or stack overflow errors
 
 <div class='note'>
 
diff --git a/web/content/docs/devguide/troubleshooting/cmake/index.md b/web/content/docs/devguide/troubleshooting/cmake/index.md
index d30d42fc28dd1d57888e99b0a0029fca79f084a3..b69f2e1b95a121f48be64c3a63b2d6b4ed7a5ae1 100644
--- a/web/content/docs/devguide/troubleshooting/cmake/index.md
+++ b/web/content/docs/devguide/troubleshooting/cmake/index.md
@@ -18,13 +18,13 @@ Please read the CMake output carefully. Often it will tell you what went wrong.
 Also consider using the command line for CMake configuration as lots of CMake options (which modify requirements on third-party libraries) have to be set via the command line **before** CMake ran for the first time. E.g. when building with PETSc the following fails:
 
 - Creating build directory
-- Starting CMake Gui
+- Starting CMake GUI
 - Click Configure
 - Enable option `OGS_USE_PETSC`
 
-When clicking *Configure*, CMake runs without `OGS_USE_PETSC` enabled and picks a VTK library which is not compiled for MPI usage. The picked VTK library is cached and never modified. So when enabling PETSc it still uses the old (and now wrong) VTK library.
+When clicking *Configure*, CMake runs without `OGS_USE_PETSC` enabled and picks a VTK library which is not compiled for MPI usage. The picked VTK library is cached and never modified. When enabling PETSc it still uses the old (and now wrong) VTK library.
 
-So you have to use the CMake command line:
+Instead you should use the CMake command line:
 
 ```bash
 mkdir build
diff --git a/web/content/docs/devguide/troubleshooting/run/index.md b/web/content/docs/devguide/troubleshooting/run/index.md
index 11f7d701ab3069c816a6c56adcee07317f9b4065..530d38e2ce974165a359c5bad01c6f34e11b1caa 100644
--- a/web/content/docs/devguide/troubleshooting/run/index.md
+++ b/web/content/docs/devguide/troubleshooting/run/index.md
@@ -22,7 +22,7 @@ Typical error message:
 error while loading shared libraries: libXX.so: cannot open shared object file: No such file or directory
 ```
 
-A shared library which was linked to OGS could not be found during runtime. The runtime search paths are determined by the system configuration but you add paths with the environment variable `LD_LIBRARY_PATH` (macOS: `DYLD_LIBRARY_PATH`). So you know where the missing library is located you can adapt the environment variable:
+A shared library which was linked to OGS could not be found during runtime. The runtime search paths are determined by the system configuration but you add paths with the environment variable `LD_LIBRARY_PATH` (macOS: `DYLD_LIBRARY_PATH`). If you know where the missing library is located you can adapt the environment variable:
 
 ```bash
 export LD_LIBRARY_PATH=/path/to/missing/lib:$LD_LIBRARY_PATH