diff --git a/nixos/doc/manual/development/option-declarations.section.md b/nixos/doc/manual/development/option-declarations.section.md
index fff06e1ea5ba..819fc6d891f0 100644
--- a/nixos/doc/manual/development/option-declarations.section.md
+++ b/nixos/doc/manual/development/option-declarations.section.md
@@ -145,26 +145,26 @@ As an example, we will take the case of display managers. There is a
central display manager module for generic display manager options and a
module file per display manager backend (sddm, gdm \...).
-There are two approach to this module structure:
+There are two approaches we could take with this module structure:
-- Managing the display managers independently by adding an enable
+- Configuring the display managers independently by adding an enable
option to every display manager module backend. (NixOS)
-- Managing the display managers in the central module by adding an
- option to select which display manager backend to use.
+- Configuring the display managers in the central module by adding
+ an option to select which display manager backend to use.
Both approaches have problems.
Making backends independent can quickly become hard to manage. For
-display managers, there can be only one enabled at a time, but the type
-system can not enforce this restriction as there is no relation between
-each backend `enable` option. As a result, this restriction has to be
-done explicitely by adding assertions in each display manager backend
-module.
+display managers, there can only be one enabled at a time, but the
+type system cannot enforce this restriction as there is no relation
+between each backend's `enable` option. As a result, this restriction
+has to be done explicitly by adding assertions in each display manager
+backend module.
-On the other hand, managing the display managers backends in the central
-module will require to change the central module option every time a new
-backend is added or removed.
+On the other hand, managing the display manager backends in the
+central module will require changing the central module option every
+time a new backend is added or removed.
By using extensible option types, it is possible to create a placeholder
option in the central module
@@ -175,7 +175,7 @@ and to extend it in each backend module
As a result, `displayManager.enable` option values can be added without
changing the main service module file and the type system automatically
-enforce that there can only be a single display manager enabled.
+enforces that there can only be a single display manager enabled.
::: {#ex-option-declaration-eot-service .example}
::: {.title}
diff --git a/nixos/doc/manual/development/option-types.section.md b/nixos/doc/manual/development/option-types.section.md
index 071e7751eb67..c34ac0367c4f 100644
--- a/nixos/doc/manual/development/option-types.section.md
+++ b/nixos/doc/manual/development/option-types.section.md
@@ -16,9 +16,9 @@ merging is handled.
`types.path`
-: A filesystem path, defined as anything that when coerced to a string
- starts with a slash. Even if derivations can be considered as path,
- the more specific `types.package` should be preferred.
+: A filesystem path is anything that starts with a slash when
+ coerced to a string. Even if derivations can be considered as
+ paths, the more specific `types.package` should be preferred.
`types.package`
diff --git a/nixos/doc/manual/from_md/development/option-declarations.section.xml b/nixos/doc/manual/from_md/development/option-declarations.section.xml
index 0eeffae628e1..554705e2e424 100644
--- a/nixos/doc/manual/from_md/development/option-declarations.section.xml
+++ b/nixos/doc/manual/from_md/development/option-declarations.section.xml
@@ -215,21 +215,22 @@ lib.mkOption {
manager backend (sddm, gdm ...).
- There are two approach to this module structure:
+ There are two approaches we could take with this module
+ structure:
- Managing the display managers independently by adding an
- enable option to every display manager module backend.
- (NixOS)
+ Configuring the display managers independently by adding
+ an enable option to every display manager module
+ backend. (NixOS)
- Managing the display managers in the central module by
- adding an option to select which display manager backend
- to use.
+ Configuring the display managers in the central module
+ by adding an option to select which display manager
+ backend to use.
@@ -238,16 +239,16 @@ lib.mkOption {
Making backends independent can quickly become hard to
- manage. For display managers, there can be only one enabled
- at a time, but the type system can not enforce this
- restriction as there is no relation between each backend
+ manage. For display managers, there can only be one enabled
+ at a time, but the type system cannot enforce this
+ restriction as there is no relation between each backend’s
enable option. As a result, this
- restriction has to be done explicitely by adding assertions
+ restriction has to be done explicitly by adding assertions
in each display manager backend module.
- On the other hand, managing the display managers backends in
- the central module will require to change the central module
+ On the other hand, managing the display manager backends in
+ the central module will require changing the central module
option every time a new backend is added or removed.
@@ -268,7 +269,7 @@ lib.mkOption {
As a result, displayManager.enable option
values can be added without changing the main service module
- file and the type system automatically enforce that there
+ file and the type system automatically enforces that there
can only be a single display manager enabled.
diff --git a/nixos/doc/manual/from_md/development/option-types.section.xml b/nixos/doc/manual/from_md/development/option-types.section.xml
index 50a3da0ef5bb..e16453df51e6 100644
--- a/nixos/doc/manual/from_md/development/option-types.section.xml
+++ b/nixos/doc/manual/from_md/development/option-types.section.xml
@@ -30,10 +30,10 @@
- A filesystem path, defined as anything that when coerced to
- a string starts with a slash. Even if derivations can be
- considered as path, the more specific
- types.package should be preferred.
+ A filesystem path is anything that starts with a slash when
+ coerced to a string. Even if derivations can be considered
+ as paths, the more specific types.package
+ should be preferred.