Apply #2276 to all editions (versions)

Author: michaelklishin

docs/production-checklist.md

@@ -246,7 +246,7 @@ A few recommendations when adjusting the default
 
  * Nodes hosting RabbitMQ should have at least <strong>256 MiB</strong> of
    memory available at all times. Deployments that use [quorum queues](./quorum-queues) require more,
-   see [how quorum queue use resources](./quorum-queues#resource-use) for more informatio.
+   see [how quorum queue use resources](./quorum-queues#resource-use) for more information.
  * The recommended `vm_memory_high_watermark.relative` range is `0.4 to 0.7`
  * Values above `0.7` should be used with care and with solid [memory usage](./memory-use) and infrastructure-level [monitoring](./monitoring) in place.
    The OS and file system must be left with at least 30% of the memory, otherwise performance may degrade severely due to paging.

docs/quorum-queues/index.md

@@ -1249,7 +1249,7 @@ This leads to several recommendations:
 
 Segment file truncation happens periodically in response to client operations,
 when it is safe to do so. Quorum queues periodically take checkpoints and snapshots,
-and truncate the segment files that are know to not contain any more "live" (ready for delivery
+and truncate the segment files that are known to not contain any more "live" (ready for delivery
 or pending consumer acknowledgement) messages.
 
 When there is no client activity, these events won't happen, and neither will segment

versioned_docs/version-3.13/production-checklist.md

@@ -246,7 +246,7 @@ A few recommendations when adjusting the default
 
  * Nodes hosting RabbitMQ should have at least <strong>256 MiB</strong> of
    memory available at all times. Deployments that use [quorum queues](./quorum-queues) require more,
-   see [how quorum queue use resources](./quorum-queues#resource-use) for more informatio.
+   see [how quorum queue use resources](./quorum-queues#resource-use) for more information.
  * The recommended `vm_memory_high_watermark.relative` range is `0.4 to 0.7`
  * Values above `0.7` should be used with care and with solid [memory usage](./memory-use) and infrastructure-level [monitoring](./monitoring) in place.
    The OS and file system must be left with at least 30% of the memory, otherwise performance may degrade severely due to paging.

versioned_docs/version-3.13/quorum-queues/index.md

@@ -1128,7 +1128,7 @@ This leads to several recommendations:
 
 Segment file truncation happens periodically in response to client operations,
 when it is safe to do so. Quorum queues periodically take checkpoints and snapshots,
-and truncate the segment files that are know to not contain any more "live" (ready for delivery
+and truncate the segment files that are known to not contain any more "live" (ready for delivery
 or pending consumer acknowledgement) messages.
 
 When there is no client activity, these events won't happen, and neither will segment

versioned_docs/version-4.0/production-checklist.md

@@ -246,7 +246,7 @@ A few recommendations when adjusting the default
 
  * Nodes hosting RabbitMQ should have at least <strong>256 MiB</strong> of
    memory available at all times. Deployments that use [quorum queues](./quorum-queues) require more,
-   see [how quorum queue use resources](./quorum-queues#resource-use) for more informatio.
+   see [how quorum queue use resources](./quorum-queues#resource-use) for more information.
  * The recommended `vm_memory_high_watermark.relative` range is `0.4 to 0.7`
  * Values above `0.7` should be used with care and with solid [memory usage](./memory-use) and infrastructure-level [monitoring](./monitoring) in place.
    The OS and file system must be left with at least 30% of the memory, otherwise performance may degrade severely due to paging.

versioned_docs/version-4.0/quorum-queues/index.md

@@ -1250,7 +1250,7 @@ This leads to several recommendations:
 
 Segment file truncation happens periodically in response to client operations,
 when it is safe to do so. Quorum queues periodically take checkpoints and snapshots,
-and truncate the segment files that are know to not contain any more "live" (ready for delivery
+and truncate the segment files that are known to not contain any more "live" (ready for delivery
 or pending consumer acknowledgement) messages.
 
 When there is no client activity, these events won't happen, and neither will segment

versioned_docs/version-4.1/production-checklist.md

@@ -246,7 +246,7 @@ A few recommendations when adjusting the default
 
  * Nodes hosting RabbitMQ should have at least <strong>256 MiB</strong> of
    memory available at all times. Deployments that use [quorum queues](./quorum-queues) require more,
-   see [how quorum queue use resources](./quorum-queues#resource-use) for more informatio.
+   see [how quorum queue use resources](./quorum-queues#resource-use) for more information.
  * The recommended `vm_memory_high_watermark.relative` range is `0.4 to 0.7`
  * Values above `0.7` should be used with care and with solid [memory usage](./memory-use) and infrastructure-level [monitoring](./monitoring) in place.
    The OS and file system must be left with at least 30% of the memory, otherwise performance may degrade severely due to paging.

versioned_docs/version-4.1/quorum-queues/index.md

@@ -1247,7 +1247,7 @@ This leads to several recommendations:
 
 Segment file truncation happens periodically in response to client operations,
 when it is safe to do so. Quorum queues periodically take checkpoints and snapshots,
-and truncate the segment files that are know to not contain any more "live" (ready for delivery
+and truncate the segment files that are known to not contain any more "live" (ready for delivery
 or pending consumer acknowledgement) messages.
 
 When there is no client activity, these events won't happen, and neither will segment