[pve-devel] SPAM: [PATCH docs] fix typos in various adoc files

[pve-devel] SPAM: [PATCH docs] fix typos in various adoc files

[Oguz Bektas]

did quick proof reading for common misspellings or errors.

some of the changes (like favourite vs. favorite or virtualization v.
virtualisation) are because of US v. UK english

Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
---
 certificate-management.adoc |  2 +-
 local-zfs.adoc              |  6 +++---
 pve-firewall.adoc           |  2 +-
 pveceph.adoc                |  8 ++++----
 pveproxy.adoc               |  2 +-
 pveum.adoc                  | 10 +++++-----
 qm-cloud-init.adoc          | 10 +++++-----
 qm-pci-passthrough.adoc     |  4 ++--
 qm.adoc                     | 20 ++++++++++----------
 translation.adoc            |  2 +-
 vzdump.adoc                 |  2 +-
 11 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/certificate-management.adoc b/certificate-management.adoc
index 065433d..4fd2a8a 100644
--- a/certificate-management.adoc
+++ b/certificate-management.adoc
@@ -313,7 +313,7 @@ root@proxmox:~# pvenode acme plugin config example_plugin
 └────────┴──────────────────────────────────────────┘
 ----
 
-At last you can configure the domain you want to get certitficates for and
+At last you can configure the domain you want to get certificates for and
 place the certificate order for it:
 
 ----
diff --git a/local-zfs.adoc b/local-zfs.adoc
index f024889..affd6fe 100644
--- a/local-zfs.adoc
+++ b/local-zfs.adoc
@@ -249,7 +249,7 @@ Bootloader
 
 {pve} uses xref:sysboot_proxmox_boot_tool[`proxmox-boot-tool`] to manage the
 bootloader configuration.
-See the chapter on xref:sysboot[{pve} host bootladers] for details.
+See the chapter on xref:sysboot[{pve} host bootloaders] for details.
 
 
 ZFS Administration
@@ -439,7 +439,7 @@ and you can install it using `apt-get`:
 ----
 
 To activate the daemon it is necessary to edit `/etc/zfs/zed.d/zed.rc` with your
-favourite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
+favorite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
 
 --------
 ZED_EMAIL_ADDR="root"
@@ -515,7 +515,7 @@ to an external Storage.
 
 We strongly recommend to use enough memory, so that you normally do not
 run into low memory situations. Should you need or want to add swap, it is
-preferred to create a partition on a physical disk and use it as swapdevice.
+preferred to create a partition on a physical disk and use it as swap device.
 You can leave some space free for this purpose in the advanced options of the
 installer. Additionally, you can lower the
 ``swappiness'' value. A good value for servers is 10:
diff --git a/pve-firewall.adoc b/pve-firewall.adoc
index 648f8cb..faf580c 100644
--- a/pve-firewall.adoc
+++ b/pve-firewall.adoc
@@ -475,7 +475,7 @@ Logging of firewall rules
 -------------------------
 
 By default, all logging of traffic filtered by the firewall rules is disabled.
-To enable logging, the `loglevel` for incommig and/or outgoing traffic has to be
+To enable logging, the `loglevel` for incoming and/or outgoing traffic has to be
 set in *Firewall* -> *Options*. This can be done for the host as well as for the
 VM/CT firewall individually. By this, logging of {PVE}'s standard firewall rules
 is enabled and the output can be observed in *Firewall* -> *Log*.
diff --git a/pveceph.adoc b/pveceph.adoc
index a45004a..04fce9a 100644
--- a/pveceph.adoc
+++ b/pveceph.adoc
@@ -92,7 +92,7 @@ machines and containers, you must also account for having enough memory
 available for Ceph to provide excellent and stable performance.
 
 As a rule of thumb, for roughly **1 TiB of data, 1 GiB of memory** will be used
-by an OSD. Especially during recovery, rebalancing or backfilling.
+by an OSD. Especially during recovery, re-balancing or backfilling.
 
 The daemon itself will use additional memory. The Bluestore backend of the
 daemon requires by default **3-5 GiB of memory** (adjustable). In contrast, the
@@ -121,7 +121,7 @@ might take long. It is recommended that you use SSDs instead of HDDs in small
 setups to reduce recovery time, minimizing the likelihood of a subsequent
 failure event during recovery.
 
-In general SSDs will provide more IOPs than spinning disks. With this in mind,
+In general SSDs will provide more IOPS than spinning disks. With this in mind,
 in addition to the higher cost, it may make sense to implement a
 xref:pve_ceph_device_classes[class based] separation of pools. Another way to
 speed up OSDs is to use a faster disk as a journal or
@@ -623,7 +623,7 @@ NOTE: Further information can be found in the Ceph documentation, under the
 section CRUSH map footnote:[CRUSH map {cephdocs-url}/rados/operations/crush-map/].
 
 This map can be altered to reflect different replication hierarchies. The object
-replicas can be separated (eg. failure domains), while maintaining the desired
+replicas can be separated (e.g., failure domains), while maintaining the desired
 distribution.
 
 A common configuration is to use different classes of disks for different Ceph
@@ -672,7 +672,7 @@ ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class
 |<rule-name>|name of the rule, to connect with a pool (seen in GUI & CLI)
 |<root>|which crush root it should belong to (default ceph root "default")
 |<failure-domain>|at which failure-domain the objects should be distributed (usually host)
-|<class>|what type of OSD backing store to use (eg. nvme, ssd, hdd)
+|<class>|what type of OSD backing store to use (e.g., nvme, ssd, hdd)
 |===
 
 Once the rule is in the CRUSH map, you can tell a pool to use the ruleset.
diff --git a/pveproxy.adoc b/pveproxy.adoc
index a7538b0..dea8267 100644
--- a/pveproxy.adoc
+++ b/pveproxy.adoc
@@ -112,7 +112,7 @@ You can define the cipher list in `/etc/default/pveproxy`, for example
 Above is the default. See the ciphers(1) man page from the openssl
 package for a list of all available options.
 
-Additionally you can define that the client choses the used cipher in
+Additionally you can define that the client chooses the used cipher in
 `/etc/default/pveproxy` (default is the first cipher in the list available to
 both client and `pveproxy`):
 
diff --git a/pveum.adoc b/pveum.adoc
index 1f7c69f..7f34ae4 100644
--- a/pveum.adoc
+++ b/pveum.adoc
@@ -171,7 +171,7 @@ description: This is the first test user.
 The 'Base Domain Name' would be `ou=People,dc=ldap-test,dc=com` and the user
 attribute would be `uid`.
 +
-If {pve} needs to authenticate (bind) to the ldap server before being
+If {pve} needs to authenticate (bind) to the LDAP server before being
 able to query and authenticate users, a bind domain name can be
 configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
 password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`
@@ -181,13 +181,13 @@ single line containing the raw password.
 To verify certificates, you need to to set `capath`. You can set it either
 directly to the CA certificate of your LDAP server, or to the system path
 containing all trusted CA certificates (`/etc/ssl/certs`).
-Additionally, you need to set the `verify` option, which can also be doen over
+Additionally, you need to set the `verify` option, which can also be done over
 the web interface.
 
 Microsoft Active Directory::
 
 A server and authentication domain need to be specified. Like with
-ldap an optional fallback server, optional port, and SSL
+LDAP an optional fallback server, optional port, and SSL
 encryption can be configured.
 
 [[pveum_ldap_sync]]
@@ -409,7 +409,7 @@ of predefined roles which satisfies most needs.
 * `PVETemplateUser`: view and clone templates
 * `PVEUserAdmin`: user administration
 * `PVEVMAdmin`: fully administer VMs
-* `PVEVMUser`: view, backup, config CDROM, VM console, VM power management
+* `PVEVMUser`: view, backup, config CD-ROM, VM console, VM power management
 
 You can see the whole set of predefined roles on the GUI.
 
@@ -464,7 +464,7 @@ Virtual machine related privileges::
 * `VM.Audit`: view VM config
 * `VM.Clone`: clone/copy a VM
 * `VM.Config.Disk`: add/modify/delete Disks 
-* `VM.Config.CDROM`: eject/change CDROM
+* `VM.Config.CDROM`: eject/change CD-ROM
 * `VM.Config.CPU`: modify CPU settings
 * `VM.Config.Memory`: modify Memory settings
 * `VM.Config.Network`: add/modify/delete Network devices
diff --git a/qm-cloud-init.adoc b/qm-cloud-init.adoc
index 895db9f..7fc86ea 100644
--- a/qm-cloud-init.adoc
+++ b/qm-cloud-init.adoc
@@ -5,7 +5,7 @@ ifdef::wiki[]
 :pve-toplevel:
 endif::wiki[]
 
-http://cloudinit.readthedocs.io[Cloud-Init] is the defacto
+http://cloudinit.readthedocs.io[Cloud-Init] is the de facto
 multi-distribution package that handles early initialization of a
 virtual machine instance. Using Cloud-Init, configuration of network
 devices and ssh keys on the hypervisor side is possible. When the VM
@@ -32,7 +32,7 @@ needs to store an encrypted version of that password inside the
 Cloud-Init data.
 
 {pve} generates an ISO image to pass the Cloud-Init data to the VM. For
-that purpose all Cloud-Init VMs need to have an assigned CDROM drive.
+that purpose all Cloud-Init VMs need to have an assigned CD-ROM drive.
 Also many Cloud-Init images assume to have a serial console, so it is
 recommended to add a serial console and use it as display for those VMs.
 
@@ -70,11 +70,11 @@ qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-1
 NOTE: Ubuntu Cloud-Init images require the `virtio-scsi-pci`
 controller type for SCSI drives.
 
-.Add Cloud-Init CDROM drive
+.Add Cloud-Init CD-ROM drive
 
 [thumbnail="screenshot/gui-cloudinit-hardware.png"]
 
-The next step is to configure a CDROM drive which will be used to pass
+The next step is to configure a CD-ROM drive which will be used to pass
 the Cloud-Init data to the VM.
 
 ----
@@ -84,7 +84,7 @@ qm set 9000 --ide2 local-lvm:cloudinit
 To be able to boot directly from the Cloud-Init image, set the
 `bootdisk` parameter to `scsi0`, and restrict BIOS to boot from disk
 only. This will speed up booting, because VM BIOS skips the testing for
-a bootable CDROM.
+a bootable CD-ROM.
 
 ----
 qm set 9000 --boot c --bootdisk scsi0
diff --git a/qm-pci-passthrough.adoc b/qm-pci-passthrough.adoc
index abb9075..1f2fd88 100644
--- a/qm-pci-passthrough.adoc
+++ b/qm-pci-passthrough.adoc
@@ -309,7 +309,7 @@ Mediated Devices (vGPU, GVT-g)
 
 Mediated devices are another method to reuse features and performance from
 physical hardware for virtualized hardware. These are found most common in
-virtualized GPU setups such as Intels GVT-g and Nvidias vGPUs used in their
+virtualized GPU setups such as Intel's GVT-g and NVIDIA's vGPUs used in their
 GRID technology.
 
 With this, a physical Card is able to create virtual cards, similar to SR-IOV.
@@ -324,7 +324,7 @@ In general your card's driver must support that feature, otherwise it will
 not work. So please refer to your vendor for compatible drivers and how to
 configure them.
 
-Intels drivers for GVT-g are integrated in the Kernel and should work
+Intel's drivers for GVT-g are integrated in the Kernel and should work
 with 5th, 6th and 7th generation Intel Core Processors, as well as E3 v4, E3
 v5 and E3 v6 Xeon Processors.
 
diff --git a/qm.adoc b/qm.adoc
index a1d2f3d..61c8e27 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -38,7 +38,7 @@ emulated computer which sees them as if they were real devices.
 A guest operating system running in the emulated computer accesses these
 devices, and runs as it were running on real hardware. For instance you can pass
 an iso image as a parameter to Qemu, and the OS running in the emulated computer
-will see a real CDROM inserted in a CD drive.
+will see a real CD-ROM inserted in a CD drive.
 
 Qemu can emulate a great variety of hardware from ARM to Sparc, but {pve} is
 only concerned with 32 and 64 bits PC clone emulation, since it represents the
@@ -49,8 +49,8 @@ architecture.
 
 NOTE: You may sometimes encounter the term _KVM_ (Kernel-based Virtual Machine).
 It means that Qemu is running with the support of the virtualization processor
-extensions, via the Linux kvm module. In the context of {pve} _Qemu_ and
-_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the kvm
+extensions, via the Linux KVM module. In the context of {pve} _Qemu_ and
+_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the KVM
 module.
 
 Qemu inside {pve} runs as a root process, since this is required to access block
@@ -61,7 +61,7 @@ Emulated devices and paravirtualized devices
 --------------------------------------------
 
 The PC hardware emulated by Qemu includes a mainboard, network controllers,
-scsi, ide and sata controllers, serial ports (the complete list can be seen in
+SCSI, IDE and SATA controllers, serial ports (the complete list can be seen in
 the `kvm(1)` man page) all of them emulated in software. All these devices
 are the exact software equivalent of existing hardware devices, and if the OS
 running in the guest has the proper drivers it will use the devices as if it
@@ -138,7 +138,7 @@ snapshots) more intelligently.
 
 {pve} allows to boot VMs with different firmware and machine types, namely
 xref:qm_bios_and_uefi[SeaBIOS and OVMF]. In most cases you want to switch from
-the default SeabBIOS to OVMF only if you plan to use
+the default SeaBIOS to OVMF only if you plan to use
 xref:qm_pci_passthrough[PCIe pass through]. A VMs 'Machine Type' defines the
 hardware layout of the VM's virtual motherboard. You can choose between the
 default https://en.wikipedia.org/wiki/Intel_440FX[Intel 440FX] or the
@@ -271,10 +271,10 @@ However some software licenses depend on the number of sockets a machine has,
 in that case it makes sense to set the number of sockets to what the license
 allows you.
 
-Increasing the number of virtual cpus (cores and sockets) will usually provide a
+Increasing the number of virtual CPUs (cores and sockets) will usually provide a
 performance improvement though that is heavily dependent on the use of the VM.
-Multithreaded applications will of course benefit from a large number of
-virtual cpus, as for each virtual cpu you add, Qemu will create a new thread of
+Multi-threaded applications will of course benefit from a large number of
+virtual CPUs, as for each virtual cpu you add, Qemu will create a new thread of
 execution on the host system. If you're not sure about the workload of your VM,
 it is usually a safe bet to set the number of *Total cores* to 2.
 
@@ -282,7 +282,7 @@ NOTE: It is perfectly safe if the _overall_ number of cores of all your VMs
 is greater than the number of cores on the server (e.g., 4 VMs with each 4
 cores on a machine with only 8 cores). In that case the host system will
 balance the Qemu execution threads between your server cores, just like if you
-were running a standard multithreaded application. However, {pve} will prevent
+were running a standard multi-threaded application. However, {pve} will prevent
 you from starting VMs with more virtual CPU cores than physically available, as
 this will only bring the performance down due to the cost of context switches.
 
@@ -492,7 +492,7 @@ vCPU hot-plug
 ^^^^^^^^^^^^^
 
 Modern operating systems introduced the capability to hot-plug and, to a
-certain extent, hot-unplug CPUs in a running systems. Virtualisation allows us
+certain extent, hot-unplug CPUs in a running systems. Virtualization allows us
 to avoid a lot of the (physical) problems real hardware can cause in such
 scenarios.
 Still, this is a rather new and complicated feature, so its use should be
diff --git a/translation.adoc b/translation.adoc
index f925d0a..b0b8945 100644
--- a/translation.adoc
+++ b/translation.adoc
@@ -76,7 +76,7 @@ perl packages installed on your system. For Debian/Ubuntu:
 Sending the Translation
 ~~~~~~~~~~~~~~~~~~~~~~~
 You can send the finished translation (`.po` file) to the Proxmox team at the address
-office(at)proxmox.com, along with a signed contributor licence agreement.
+office(at)proxmox.com, along with a signed contributor license agreement.
 Alternatively, if you have some developer experience, you can send it as a
 patch to the {pve} development mailing list. See
 {webwiki-url}Developer_Documentation[Developer Documentation].
diff --git a/vzdump.adoc b/vzdump.adoc
index 0937fe2..3d9c1f9 100644
--- a/vzdump.adoc
+++ b/vzdump.adoc
@@ -449,7 +449,7 @@ but will match relative to any subdirectory. For example:
 
  # vzdump 777 --exclude-path bar
 
-excludes any file or directoy named `/bar`, `/var/bar`, `/var/foo/bar`, and
+excludes any file or directory named `/bar`, `/var/bar`, `/var/foo/bar`, and
 so on, but not `/bar2`.
 
 Configuration files are also stored inside the backup archive
-- 
2.20.1

Re: [pve-devel] SPAM: [PATCH docs] fix typos in various adoc files

[Dylan Whyte]

Hi,

Just a few small suggestions. Looking at some of the surrounding lines, 
certain sections could probably do with a proper fix up, but I'll look 
at that another day.


Reviewed-by: Dylan Whyte <d.whyte@proxmox.com>


On 4/29/21 11:46 AM, Oguz Bektas wrote:
> did quick proof reading for common misspellings or errors.
>
> some of the changes (like favourite vs. favorite or virtualization v.
> virtualisation) are because of US v. UK english
>
> Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
> ---
>   certificate-management.adoc |  2 +-
>   local-zfs.adoc              |  6 +++---
>   pve-firewall.adoc           |  2 +-
>   pveceph.adoc                |  8 ++++----
>   pveproxy.adoc               |  2 +-
>   pveum.adoc                  | 10 +++++-----
>   qm-cloud-init.adoc          | 10 +++++-----
>   qm-pci-passthrough.adoc     |  4 ++--
>   qm.adoc                     | 20 ++++++++++----------
>   translation.adoc            |  2 +-
>   vzdump.adoc                 |  2 +-
>   11 files changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/certificate-management.adoc b/certificate-management.adoc
> index 065433d..4fd2a8a 100644
> --- a/certificate-management.adoc
> +++ b/certificate-management.adoc
> @@ -313,7 +313,7 @@ root@proxmox:~# pvenode acme plugin config example_plugin
>   └────────┴──────────────────────────────────────────┘
>   ----
>   
> -At last you can configure the domain you want to get certitficates for and
> +At last you can configure the domain you want to get certificates for and
>   place the certificate order for it:
>   
>   ----
> diff --git a/local-zfs.adoc b/local-zfs.adoc
> index f024889..affd6fe 100644
> --- a/local-zfs.adoc
> +++ b/local-zfs.adoc
> @@ -249,7 +249,7 @@ Bootloader
>   
>   {pve} uses xref:sysboot_proxmox_boot_tool[`proxmox-boot-tool`] to manage the
>   bootloader configuration.
> -See the chapter on xref:sysboot[{pve} host bootladers] for details.
> +See the chapter on xref:sysboot[{pve} host bootloaders] for details.
>   
>   
>   ZFS Administration
> @@ -439,7 +439,7 @@ and you can install it using `apt-get`:
>   ----
>   
>   To activate the daemon it is necessary to edit `/etc/zfs/zed.d/zed.rc` with your
> -favourite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
> +favorite editor, and uncomment the `ZED_EMAIL_ADDR` setting:
>   
>   --------
>   ZED_EMAIL_ADDR="root"
> @@ -515,7 +515,7 @@ to an external Storage.
>   
>   We strongly recommend to use enough memory, so that you normally do not
>   run into low memory situations. Should you need or want to add swap, it is
> -preferred to create a partition on a physical disk and use it as swapdevice.
> +preferred to create a partition on a physical disk and use it as swap device.
s/as swap/as a swap/
>   You can leave some space free for this purpose in the advanced options of the
>   installer. Additionally, you can lower the
>   ``swappiness'' value. A good value for servers is 10:
> diff --git a/pve-firewall.adoc b/pve-firewall.adoc
> index 648f8cb..faf580c 100644
> --- a/pve-firewall.adoc
> +++ b/pve-firewall.adoc
> @@ -475,7 +475,7 @@ Logging of firewall rules
>   -------------------------
>   
>   By default, all logging of traffic filtered by the firewall rules is disabled.
> -To enable logging, the `loglevel` for incommig and/or outgoing traffic has to be
> +To enable logging, the `loglevel` for incoming and/or outgoing traffic has to be
>   set in *Firewall* -> *Options*. This can be done for the host as well as for the
>   VM/CT firewall individually. By this, logging of {PVE}'s standard firewall rules
>   is enabled and the output can be observed in *Firewall* -> *Log*.
> diff --git a/pveceph.adoc b/pveceph.adoc
> index a45004a..04fce9a 100644
> --- a/pveceph.adoc
> +++ b/pveceph.adoc
> @@ -92,7 +92,7 @@ machines and containers, you must also account for having enough memory
>   available for Ceph to provide excellent and stable performance.
>   
>   As a rule of thumb, for roughly **1 TiB of data, 1 GiB of memory** will be used
> -by an OSD. Especially during recovery, rebalancing or backfilling.
> +by an OSD. Especially during recovery, re-balancing or backfilling.
>   
>   The daemon itself will use additional memory. The Bluestore backend of the
>   daemon requires by default **3-5 GiB of memory** (adjustable). In contrast, the
> @@ -121,7 +121,7 @@ might take long. It is recommended that you use SSDs instead of HDDs in small
>   setups to reduce recovery time, minimizing the likelihood of a subsequent
>   failure event during recovery.
>   
> -In general SSDs will provide more IOPs than spinning disks. With this in mind,
> +In general SSDs will provide more IOPS than spinning disks. With this in mind,
s/general SSDs/general, SSDs/
>   in addition to the higher cost, it may make sense to implement a
>   xref:pve_ceph_device_classes[class based] separation of pools. Another way to
>   speed up OSDs is to use a faster disk as a journal or
> @@ -623,7 +623,7 @@ NOTE: Further information can be found in the Ceph documentation, under the
>   section CRUSH map footnote:[CRUSH map {cephdocs-url}/rados/operations/crush-map/].
>   
>   This map can be altered to reflect different replication hierarchies. The object
> -replicas can be separated (eg. failure domains), while maintaining the desired
> +replicas can be separated (e.g., failure domains), while maintaining the desired
>   distribution.
>   
>   A common configuration is to use different classes of disks for different Ceph
> @@ -672,7 +672,7 @@ ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class
>   |<rule-name>|name of the rule, to connect with a pool (seen in GUI & CLI)
>   |<root>|which crush root it should belong to (default ceph root "default")
>   |<failure-domain>|at which failure-domain the objects should be distributed (usually host)
> -|<class>|what type of OSD backing store to use (eg. nvme, ssd, hdd)
> +|<class>|what type of OSD backing store to use (e.g., nvme, ssd, hdd)
>   |===
>   
>   Once the rule is in the CRUSH map, you can tell a pool to use the ruleset.
> diff --git a/pveproxy.adoc b/pveproxy.adoc
> index a7538b0..dea8267 100644
> --- a/pveproxy.adoc
> +++ b/pveproxy.adoc
> @@ -112,7 +112,7 @@ You can define the cipher list in `/etc/default/pveproxy`, for example
>   Above is the default. See the ciphers(1) man page from the openssl
>   package for a list of all available options.
>   
> -Additionally you can define that the client choses the used cipher in
> +Additionally you can define that the client chooses the used cipher in

I would rephrase the line to:

"Additionally, you can set the client to choose the cipher used in"

>   `/etc/default/pveproxy` (default is the first cipher in the list available to
>   both client and `pveproxy`):
>   
> diff --git a/pveum.adoc b/pveum.adoc
> index 1f7c69f..7f34ae4 100644
> --- a/pveum.adoc
> +++ b/pveum.adoc
> @@ -171,7 +171,7 @@ description: This is the first test user.
>   The 'Base Domain Name' would be `ou=People,dc=ldap-test,dc=com` and the user
>   attribute would be `uid`.
>   +
> -If {pve} needs to authenticate (bind) to the ldap server before being
> +If {pve} needs to authenticate (bind) to the LDAP server before being
>   able to query and authenticate users, a bind domain name can be
>   configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
>   password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`
> @@ -181,13 +181,13 @@ single line containing the raw password.
>   To verify certificates, you need to to set `capath`. You can set it either
>   directly to the CA certificate of your LDAP server, or to the system path
>   containing all trusted CA certificates (`/etc/ssl/certs`).
> -Additionally, you need to set the `verify` option, which can also be doen over
> +Additionally, you need to set the `verify` option, which can also be done over
>   the web interface.
>   
>   Microsoft Active Directory::
>   
>   A server and authentication domain need to be specified. Like with
> -ldap an optional fallback server, optional port, and SSL
> +LDAP an optional fallback server, optional port, and SSL

s/LDAP an/LDAP, an/

s/fallback server, optional port/fallback server, port/

>   encryption can be configured.
>   
>   [[pveum_ldap_sync]]
> @@ -409,7 +409,7 @@ of predefined roles which satisfies most needs.
>   * `PVETemplateUser`: view and clone templates
>   * `PVEUserAdmin`: user administration
>   * `PVEVMAdmin`: fully administer VMs
> -* `PVEVMUser`: view, backup, config CDROM, VM console, VM power management
> +* `PVEVMUser`: view, backup, config CD-ROM, VM console, VM power management
>   
>   You can see the whole set of predefined roles on the GUI.
>   
> @@ -464,7 +464,7 @@ Virtual machine related privileges::
>   * `VM.Audit`: view VM config
>   * `VM.Clone`: clone/copy a VM
>   * `VM.Config.Disk`: add/modify/delete Disks
> -* `VM.Config.CDROM`: eject/change CDROM
> +* `VM.Config.CDROM`: eject/change CD-ROM
>   * `VM.Config.CPU`: modify CPU settings
>   * `VM.Config.Memory`: modify Memory settings
>   * `VM.Config.Network`: add/modify/delete Network devices
> diff --git a/qm-cloud-init.adoc b/qm-cloud-init.adoc
> index 895db9f..7fc86ea 100644
> --- a/qm-cloud-init.adoc
> +++ b/qm-cloud-init.adoc
> @@ -5,7 +5,7 @@ ifdef::wiki[]
>   :pve-toplevel:
>   endif::wiki[]
>   
> -http://cloudinit.readthedocs.io[Cloud-Init] is the defacto
> +http://cloudinit.readthedocs.io[Cloud-Init] is the de facto
>   multi-distribution package that handles early initialization of a
>   virtual machine instance. Using Cloud-Init, configuration of network
>   devices and ssh keys on the hypervisor side is possible. When the VM
> @@ -32,7 +32,7 @@ needs to store an encrypted version of that password inside the
>   Cloud-Init data.
>   
>   {pve} generates an ISO image to pass the Cloud-Init data to the VM. For
> -that purpose all Cloud-Init VMs need to have an assigned CDROM drive.
> +that purpose all Cloud-Init VMs need to have an assigned CD-ROM drive.
s/purpose all/purpose, all/
>   Also many Cloud-Init images assume to have a serial console, so it is
>   recommended to add a serial console and use it as display for those VMs.
>   
> @@ -70,11 +70,11 @@ qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-1
>   NOTE: Ubuntu Cloud-Init images require the `virtio-scsi-pci`
>   controller type for SCSI drives.
>   
> -.Add Cloud-Init CDROM drive
> +.Add Cloud-Init CD-ROM drive
>   
>   [thumbnail="screenshot/gui-cloudinit-hardware.png"]
>   
> -The next step is to configure a CDROM drive which will be used to pass
> +The next step is to configure a CD-ROM drive which will be used to pass
s/drive which/drive, which/
>   the Cloud-Init data to the VM.
>   
>   ----
> @@ -84,7 +84,7 @@ qm set 9000 --ide2 local-lvm:cloudinit
>   To be able to boot directly from the Cloud-Init image, set the
>   `bootdisk` parameter to `scsi0`, and restrict BIOS to boot from disk
>   only. This will speed up booting, because VM BIOS skips the testing for
> -a bootable CDROM.
> +a bootable CD-ROM.
>   
>   ----
>   qm set 9000 --boot c --bootdisk scsi0
> diff --git a/qm-pci-passthrough.adoc b/qm-pci-passthrough.adoc
> index abb9075..1f2fd88 100644
> --- a/qm-pci-passthrough.adoc
> +++ b/qm-pci-passthrough.adoc
> @@ -309,7 +309,7 @@ Mediated Devices (vGPU, GVT-g)
>   
>   Mediated devices are another method to reuse features and performance from
>   physical hardware for virtualized hardware. These are found most common in
> -virtualized GPU setups such as Intels GVT-g and Nvidias vGPUs used in their
> +virtualized GPU setups such as Intel's GVT-g and NVIDIA's vGPUs used in their
>   GRID technology.
>   
>   With this, a physical Card is able to create virtual cards, similar to SR-IOV.
> @@ -324,7 +324,7 @@ In general your card's driver must support that feature, otherwise it will
>   not work. So please refer to your vendor for compatible drivers and how to
>   configure them.
>   
> -Intels drivers for GVT-g are integrated in the Kernel and should work
> +Intel's drivers for GVT-g are integrated in the Kernel and should work
>   with 5th, 6th and 7th generation Intel Core Processors, as well as E3 v4, E3
>   v5 and E3 v6 Xeon Processors.
>   
> diff --git a/qm.adoc b/qm.adoc
> index a1d2f3d..61c8e27 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -38,7 +38,7 @@ emulated computer which sees them as if they were real devices.
>   A guest operating system running in the emulated computer accesses these
>   devices, and runs as it were running on real hardware. For instance you can pass

s/as it were/as if it were/

s/For instance you/For instance, you/

>   an iso image as a parameter to Qemu, and the OS running in the emulated computer
> -will see a real CDROM inserted in a CD drive.
> +will see a real CD-ROM inserted in a CD drive.
s/inserted in/inserted into/
>   
>   Qemu can emulate a great variety of hardware from ARM to Sparc, but {pve} is
>   only concerned with 32 and 64 bits PC clone emulation, since it represents the
> @@ -49,8 +49,8 @@ architecture.
>   
>   NOTE: You may sometimes encounter the term _KVM_ (Kernel-based Virtual Machine).
>   It means that Qemu is running with the support of the virtualization processor
> -extensions, via the Linux kvm module. In the context of {pve} _Qemu_ and
> -_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the kvm
> +extensions, via the Linux KVM module. In the context of {pve} _Qemu_ and
s/{pve} _Qemu_/{pve}, _Qemu_/
> +_KVM_ can be used interchangeably as Qemu in {pve} will always try to load the KVM
s/interchangeably as/interchangeably, as/
>   module.
>   
>   Qemu inside {pve} runs as a root process, since this is required to access block
> @@ -61,7 +61,7 @@ Emulated devices and paravirtualized devices
>   --------------------------------------------
>   
>   The PC hardware emulated by Qemu includes a mainboard, network controllers,
> -scsi, ide and sata controllers, serial ports (the complete list can be seen in
> +SCSI, IDE and SATA controllers, serial ports (the complete list can be seen in
>   the `kvm(1)` man page) all of them emulated in software. All these devices
>   are the exact software equivalent of existing hardware devices, and if the OS
>   running in the guest has the proper drivers it will use the devices as if it
> @@ -138,7 +138,7 @@ snapshots) more intelligently.
>   
>   {pve} allows to boot VMs with different firmware and machine types, namely
>   xref:qm_bios_and_uefi[SeaBIOS and OVMF]. In most cases you want to switch from
> -the default SeabBIOS to OVMF only if you plan to use
> +the default SeaBIOS to OVMF only if you plan to use
>   xref:qm_pci_passthrough[PCIe pass through]. A VMs 'Machine Type' defines the
>   hardware layout of the VM's virtual motherboard. You can choose between the
>   default https://en.wikipedia.org/wiki/Intel_440FX[Intel 440FX] or the
> @@ -271,10 +271,10 @@ However some software licenses depend on the number of sockets a machine has,
>   in that case it makes sense to set the number of sockets to what the license
>   allows you.
>   
> -Increasing the number of virtual cpus (cores and sockets) will usually provide a
> +Increasing the number of virtual CPUs (cores and sockets) will usually provide a
>   performance improvement though that is heavily dependent on the use of the VM.
> -Multithreaded applications will of course benefit from a large number of
> -virtual cpus, as for each virtual cpu you add, Qemu will create a new thread of
> +Multi-threaded applications will of course benefit from a large number of
> +virtual CPUs, as for each virtual cpu you add, Qemu will create a new thread of
>   execution on the host system. If you're not sure about the workload of your VM,
>   it is usually a safe bet to set the number of *Total cores* to 2.
>   
> @@ -282,7 +282,7 @@ NOTE: It is perfectly safe if the _overall_ number of cores of all your VMs
>   is greater than the number of cores on the server (e.g., 4 VMs with each 4
>   cores on a machine with only 8 cores). In that case the host system will
>   balance the Qemu execution threads between your server cores, just like if you
> -were running a standard multithreaded application. However, {pve} will prevent
> +were running a standard multi-threaded application. However, {pve} will prevent
>   you from starting VMs with more virtual CPU cores than physically available, as
>   this will only bring the performance down due to the cost of context switches.
>   
> @@ -492,7 +492,7 @@ vCPU hot-plug
>   ^^^^^^^^^^^^^
>   
>   Modern operating systems introduced the capability to hot-plug and, to a
> -certain extent, hot-unplug CPUs in a running systems. Virtualisation allows us
> +certain extent, hot-unplug CPUs in a running systems. Virtualization allows us
s/running systems/running system/
>   to avoid a lot of the (physical) problems real hardware can cause in such
>   scenarios.
>   Still, this is a rather new and complicated feature, so its use should be
> diff --git a/translation.adoc b/translation.adoc
> index f925d0a..b0b8945 100644
> --- a/translation.adoc
> +++ b/translation.adoc
> @@ -76,7 +76,7 @@ perl packages installed on your system. For Debian/Ubuntu:
>   Sending the Translation
>   ~~~~~~~~~~~~~~~~~~~~~~~
>   You can send the finished translation (`.po` file) to the Proxmox team at the address
> -office(at)proxmox.com, along with a signed contributor licence agreement.
> +office(at)proxmox.com, along with a signed contributor license agreement.
>   Alternatively, if you have some developer experience, you can send it as a
>   patch to the {pve} development mailing list. See
>   {webwiki-url}Developer_Documentation[Developer Documentation].
> diff --git a/vzdump.adoc b/vzdump.adoc
> index 0937fe2..3d9c1f9 100644
> --- a/vzdump.adoc
> +++ b/vzdump.adoc
> @@ -449,7 +449,7 @@ but will match relative to any subdirectory. For example:
>   
>    # vzdump 777 --exclude-path bar
>   
> -excludes any file or directoy named `/bar`, `/var/bar`, `/var/foo/bar`, and
> +excludes any file or directory named `/bar`, `/var/bar`, `/var/foo/bar`, and
>   so on, but not `/bar2`.
>   
>   Configuration files are also stored inside the backup archive