diff --git a/examples/freeflowchannel/README.md b/examples/freeflowchannel/README.md
index a12b05679bc3823216bb67489f93f08b536cea99..292b8c591b919ef1d6e98089c8b2f5a33c35f7ed 100644
--- a/examples/freeflowchannel/README.md
+++ b/examples/freeflowchannel/README.md
@@ -1,10 +1,10 @@
 <!-- Important: This file has been automatically generated by generate_example_docs.py. Do not edit this file directly! -->
 
-# Freeflow through a channel
+# Free flow through a channel
 
 __You learn how to__
 
-* solve a free flow channel problem
+* solve a free-flow channel problem
 * set outflow boundary conditions in the free-flow context
 
 __Results__. In this example we will obtain the following stationary velocity profile:
@@ -70,7 +70,7 @@ Take a look at Figure 1 for an illustration of the domain and the boundary condi
 ## Compile-time settings (`properties.hh`)
 
 In this file, the type tag used for this simulation is defined,
-for which we then specialize `properties` to the needs of the desired setup.
+for which we then specialize properties (compile time options) to the needs of the desired setup.
 
 
 <details open>
@@ -80,9 +80,9 @@ for which we then specialize `properties` to the needs of the desired setup.
 ### Includes
 <details><summary> Click to show includes</summary>
 
-The `NavierStokes` type tag specializes most of the `properties` required for Navier-
+The `NavierStokes` type tag specializes most of the properties required for Navier-
 Stokes single-phase flow simulations in DuMuX. We will use this in the following to inherit the
-respective properties and subsequently specialize those `properties` for our
+respective properties and subsequently specialize those properties for our
 type tag, which we want to modify or for which no meaningful default can be set.
 
 ```cpp
@@ -120,11 +120,11 @@ We include the problem header used for this simulation.
 ### Type tag definition
 
 We define a type tag for our simulation with the name `ChannelExample`
-and inherit the `properties` specialized for the type tags `NavierStokes` and `StaggeredFreeFlowModel`.
-This way, most of the `properties` required for Navier-Stokes single-phase flow simulations
+and inherit the properties specialized for the type tags `NavierStokes` and `StaggeredFreeFlowModel`.
+This way, most of the properties required for Navier-Stokes single-phase flow simulations
 using the staggered-grid scheme are conveniently specialized for our new type tag.
 However, some properties depend on user choices and no meaningful default value can be set.
-Those properties will be adressed later in this file.
+Those properties will be addressed later in this file.
 Please note that, in this example, we actually want to solve the Stokes instead of the
 Navier-Stokes equations. This can be achieved at runtime by setting the parameter
 `Problem.EnableInertiaTerms = false`. Have a look at the input file `params.input`
@@ -142,7 +142,7 @@ struct ChannelExample { using InheritsFrom = std::tuple<NavierStokes, StaggeredF
 
 ### Property specializations
 
-In the following piece of code, mandatory `properties` for which no meaningful
+In the following piece of code, mandatory properties for which no meaningful
 default can be set, are specialized for our type tag `ChannelExample`.
 
 ```cpp
@@ -167,11 +167,11 @@ We also set some properties related to memory management
 throughout the simulation.
 <details><summary> Click to show caching properties</summary>
 
-In Dumux, one has the option to activate/deactive the grid-wide caching of
+In Dumux, one has the option to activate/deactivate the grid-wide caching of
 geometries and variables. If active, the CPU time can be significantly reduced
 as less dynamic memory allocation procedures are necessary. Per default, grid-wide
 caching is disabled to ensure minimal memory requirements, however, in this example we
-want to active all available caches, which significanlty increases the memory
+want to active all available caches, which significantly increases the memory
 demand but makes the simulation faster.
 
 
@@ -328,7 +328,7 @@ This would be important if another fluidsystem was used.
     { return 273.15 + 10; }
 ```
 
-The inlet is at the left side of the physical domain.
+The inlet is on the left side of the physical domain.
 
 ```cpp
 private:
@@ -336,7 +336,7 @@ private:
     { return globalPos[0] < eps_; }
 ```
 
-The outlet is at the right side of the physical domain.
+The outlet is on the right side of the physical domain.
 
 ```cpp
     bool isOutlet_(const GlobalPosition& globalPos) const
@@ -382,7 +382,7 @@ the retrieval of input parameters specified in the input file or via the command
 #include <dumux/common/parameters.hh>
 ```
 
-The following files contains the non-linear Newton solver, the available linear solver backends and the assembler for the linear
+The following files contain the non-linear Newton solver, the available linear solver backends and the assembler for the linear
 systems arising from the staggered-grid discretization.
 
 ```cpp
@@ -442,7 +442,7 @@ int main(int argc, char** argv) try
     Parameters::init(argc, argv);
 ```
 
-We define a convenienc alias for the type tag of the problem. The type
+We define a convenience alias for the type tag of the problem. The type
 tag contains all the properties that are needed to define the model and the problem
 setup. Throughout the main file, we will obtain types defined for this type tag
 using the property system, i.e. with `GetPropType`.
@@ -464,7 +464,7 @@ of the corners of the grid and the number of cells to be used to discretize each
     const auto& leafGridView = gridManager.grid().leafGridView();
 ```
 
-### Step 2: Setting up and solving the problem
+#### Step 2: Setting up and solving the problem
 First, a finite volume grid geometry is constructed from the grid that was created above.
 This builds the sub-control volumes (scv) and sub-control volume faces (scvf) for each element
 of the grid partition.
@@ -596,7 +596,7 @@ In the following we calculate mass and volume fluxes over the planes specified a
     flux.calculateVolumeFluxes();
 ```
 
-### Final Output
+#### Final Output
 We write the VTK output and print the mass/energy/volume fluxes over the planes.
 We conclude by printing the dumux end message.
 
diff --git a/examples/freeflowchannel/doc/_intro.md b/examples/freeflowchannel/doc/_intro.md
index 3f66947835e0fdf340bd885481e8738023b6d41f..4007f34ec7d73865499a4cb80fb854b458203eeb 100644
--- a/examples/freeflowchannel/doc/_intro.md
+++ b/examples/freeflowchannel/doc/_intro.md
@@ -1,8 +1,8 @@
-# Freeflow through a channel
+# Free flow through a channel
 
 __You learn how to__
 
-* solve a free flow channel problem
+* solve a free-flow channel problem
 * set outflow boundary conditions in the free-flow context
 
 __Results__. In this example we will obtain the following stationary velocity profile:
diff --git a/examples/freeflowchannel/main.cc b/examples/freeflowchannel/main.cc
index 6289729f7e74f6cd45a0101e07e0ce72455877f3..8994914603f92b90486c858a87779978ad7b934c 100644
--- a/examples/freeflowchannel/main.cc
+++ b/examples/freeflowchannel/main.cc
@@ -38,7 +38,7 @@
 #include <dumux/common/properties.hh>
 #include <dumux/common/parameters.hh>
 
-// The following files contains the non-linear Newton solver, the available linear solver backends and the assembler for the linear
+// The following files contain the non-linear Newton solver, the available linear solver backends and the assembler for the linear
 // systems arising from the staggered-grid discretization.
 #include <dumux/nonlinear/newtonsolver.hh>
 #include <dumux/linear/seqsolverbackend.hh>
@@ -82,7 +82,7 @@ int main(int argc, char** argv) try
     Parameters::init(argc, argv);
     // [[/codeblock]]
 
-    // We define a convenienc alias for the type tag of the problem. The type
+    // We define a convenience alias for the type tag of the problem. The type
     // tag contains all the properties that are needed to define the model and the problem
     // setup. Throughout the main file, we will obtain types defined for this type tag
     // using the property system, i.e. with `GetPropType`.
diff --git a/examples/freeflowchannel/problem.hh b/examples/freeflowchannel/problem.hh
index c708ee74577d1e5a4d496c84a6a73f30e5e58b0a..2707c7376749ed8b855e4b6fca833d9b969ced65 100644
--- a/examples/freeflowchannel/problem.hh
+++ b/examples/freeflowchannel/problem.hh
@@ -141,14 +141,14 @@ public:
     Scalar temperature() const
     { return 273.15 + 10; }
 
-// The inlet is at the left side of the physical domain.
+// The inlet is on the left side of the physical domain.
 // [[codeblock]]
 private:
     bool isInlet_(const GlobalPosition& globalPos) const
     { return globalPos[0] < eps_; }
     // [[/codeblock]]
 
-    // The outlet is at the right side of the physical domain.
+    // The outlet is on the right side of the physical domain.
     bool isOutlet_(const GlobalPosition& globalPos) const
     { return globalPos[0] > this->gridGeometry().bBoxMax()[0] - eps_; }
 
diff --git a/examples/freeflowchannel/properties.hh b/examples/freeflowchannel/properties.hh
index 6b3a4cf3abbd0af46e38a3c7d0adcba8960107d1..56e717db3944fb12836334f670b6c0d3dc786248 100644
--- a/examples/freeflowchannel/properties.hh
+++ b/examples/freeflowchannel/properties.hh
@@ -23,16 +23,16 @@
 // ## Compile-time settings (`properties.hh`)
 //
 // In this file, the type tag used for this simulation is defined,
-// for which we then specialize `properties` to the needs of the desired setup.
+// for which we then specialize properties (compile time options) to the needs of the desired setup.
 //
 // [[content]]
 //
 // ### Includes
 // [[details]] includes
 //
-// The `NavierStokes` type tag specializes most of the `properties` required for Navier-
+// The `NavierStokes` type tag specializes most of the properties required for Navier-
 // Stokes single-phase flow simulations in DuMuX. We will use this in the following to inherit the
-// respective properties and subsequently specialize those `properties` for our
+// respective properties and subsequently specialize those properties for our
 // type tag, which we want to modify or for which no meaningful default can be set.
 #include <dumux/freeflow/navierstokes/model.hh>
 
@@ -52,11 +52,11 @@
 // ### Type tag definition
 //
 // We define a type tag for our simulation with the name `ChannelExample`
-// and inherit the `properties` specialized for the type tags `NavierStokes` and `StaggeredFreeFlowModel`.
-// This way, most of the `properties` required for Navier-Stokes single-phase flow simulations
+// and inherit the properties specialized for the type tags `NavierStokes` and `StaggeredFreeFlowModel`.
+// This way, most of the properties required for Navier-Stokes single-phase flow simulations
 // using the staggered-grid scheme are conveniently specialized for our new type tag.
 // However, some properties depend on user choices and no meaningful default value can be set.
-// Those properties will be adressed later in this file.
+// Those properties will be addressed later in this file.
 // Please note that, in this example, we actually want to solve the Stokes instead of the
 // Navier-Stokes equations. This can be achieved at runtime by setting the parameter
 // `Problem.EnableInertiaTerms = false`. Have a look at the input file `params.input`
@@ -73,7 +73,7 @@ struct ChannelExample { using InheritsFrom = std::tuple<NavierStokes, StaggeredF
 
 // ### Property specializations
 //
-// In the following piece of code, mandatory `properties` for which no meaningful
+// In the following piece of code, mandatory properties for which no meaningful
 // default can be set, are specialized for our type tag `ChannelExample`.
 // [[codeblock]]
 // This sets the grid type used for the simulation. Here, we use a structured 2D grid.
@@ -97,11 +97,11 @@ struct FluidSystem<TypeTag, TTag::ChannelExample>
 // throughout the simulation.
 // [[details]] caching properties
 //
-// In Dumux, one has the option to activate/deactive the grid-wide caching of
+// In Dumux, one has the option to activate/deactivate the grid-wide caching of
 // geometries and variables. If active, the CPU time can be significantly reduced
 // as less dynamic memory allocation procedures are necessary. Per default, grid-wide
 // caching is disabled to ensure minimal memory requirements, however, in this example we
-// want to active all available caches, which significanlty increases the memory
+// want to active all available caches, which significantly increases the memory
 // demand but makes the simulation faster.
 //
 // [[codeblock]]