Resolve open issues mentioned on Transifex

introduction/faq.md

@@ -459,10 +459,10 @@ In your TemplateVMs, open a terminal and run `sudo dnf upgrade`.
 
 Enable "debug mode" in the qube's settings, either by checking the box labeled "Run in debug mode" in the Qubes VM Manager qube settings menu or by running the `qvm-prefs` command.
 
-### I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.
+### I created a USB VM and assigned USB controllers to it. Now the USB VM won't boot.
 
 This is probably because one of the controllers does not support reset.
-See the [USB Troubleshooting guide](/doc/usb-troubleshooting/#usbvm-does-not-boot-after-creating-and-assigning-usb-controllers-to-it).
+See the [USB Troubleshooting guide](/doc/usb-troubleshooting/#usb-vm-does-not-boot-after-creating-and-assigning-usb-controllers-to-it).
 
 ### I assigned a PCI device to a qube, then unassigned it/shut down the qube. Why isn't the device available in dom0?
 

user/advanced-configuration/salt.md

@@ -431,16 +431,16 @@ System NetVM
 
 #### `qvm.sys-usb`
 
-System UsbVM
+System USB VM
 
 #### `qvm.sys-net-with-usb`
 
-System UsbVM bundled into NetVM. Do not enable together with `qvm.sys-usb`.
+System USB VM bundled into NetVM. Do not enable together with `qvm.sys-usb`.
 
 #### `qvm.usb-keyboard`
 
-Enable USB keyboard together with USBVM, including for early system boot (for LUKS passhprase).
-This state implicitly creates a USBVM (`qvm.sys-usb` state), if not already done.
+Enable USB keyboard together with USB VM, including for early system boot (for LUKS passhprase).
+This state implicitly creates a USB VM (`qvm.sys-usb` state), if not already done.
 
 #### `qvm.sys-firewall`
 

user/downloading-installing-upgrading/upgrade/upgrade-to-r3_1.md

@@ -114,7 +114,7 @@ Maid passphrase to the new configuration. Please consult the Anti Evil Maid
 
 If you use USB VM, you may encounter problem with starting it on updated Xen
 version (because of strict default settings). Take a look at 
-[User FAQ](/faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot)
+[User FAQ](/faq/#i-created-a-usb-vm-and-assigned-usb-controllers-to-it-now-the-usb-vm-wont-boot)
 for details.
 
 Once you have upgraded dom0, you can install new templates from Qubes R3.1

user/hardware/system-requirements.md

@@ -63,7 +63,7 @@ title: System Requirements
   In addition to the convenience of having a portable copy of Qubes, this allows users to test for hardware compatibility on multiple machines (e.g., at a brick-and-mortar computer
   store) before deciding on which computer to purchase.
   (See [hcl-report](/doc/hcl/#generating-and-submitting-new-reports) for advice on hardware compatibility testing.)
-  Remember to change the devices assigned to your NetVM and USBVM if you move between different machines.
+  Remember to change the devices assigned to your NetVM and USB VM if you move between different machines.
 - [Advice on finding a VT-d capable notebook](https://groups.google.com/d/msg/qubes-users/Sz0Nuhi4N0o/ZtpJdoc0OY8J).
 - You can check whether an Intel processor has VT-x and VT-d on [ark.intel.com](https://ark.intel.com/content/www/us/en/ark.html#@Processors).
 

user/security-in-qubes/anti-evil-maid.md

@@ -53,7 +53,7 @@ Therefore, it is up to each individual Qubes user to evaluate the relative risk
 For example, a user who frequently travels with a Qubes laptop holding sensitive data may be at a much higher risk of Evil Maid attacks than a home user with a stationary Qubes desktop.
 If the frequent traveler judges her risk of an Evil Maid attack to be higher than the risk of a malicious USB device, she might reasonably opt to install and use AEM.
 On the other hand, the home user might deem the probability of an Evil Maid attack occurring in her own home to be so low that there is a higher probability that any USB drive she purchases is already compromised, in which case she might reasonably opt never to attach any USB devices directly to dom0.
-(In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USBVM](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md#creating-and-using-a-usbvm).)
+(In either case, users can--and should--secure dom0 against further USB-related attacks through the use of a [USB VM](https://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md#creating-and-using-a-usbvm).)
 
 For more information, please see [this discussion thread](https://groups.google.com/d/msg/qubes-devel/EBc4to5IBdg/n1hfsHSfbqsJ).
 

user/troubleshooting/usb-troubleshooting.md

@@ -34,7 +34,7 @@ After attaching a device to a qube, upon attempting to use the device results in
 
 As a first line of defense, increase the amount of memory given to the USB VM (sys-usb). High-bandwidth devices such as webcams have been [observed](https://github.com/QubesOS/qubes-issues/issues/6200) to need more memory in sys-usb. If increasing the amount of memory does not resolve the issue, check kernel logs within sys-usb as well as the attached qube for errors before filing a bug report.
 
-## usbVM does not boot after creating and assigning USB controllers to it
+## USB VM does not boot after creating and assigning USB controllers to it
 
 This is probably because one of the controllers does not support reset.
 In Qubes R2 any such errors were ignored. In Qubes R3.x they are not.
@@ -43,7 +43,7 @@ In R4.x, devices that are automatically added to sys-net and sys-usb on install
 A device that does not support reset is not ideal and generally should not be assigned to a VM.
 
 Most likely the offending controller is a USB 3.0 device.
-You can remove this controller from the usbVM, and see if this allows the VM to boot.
+You can remove this controller from the USB VM, and see if this allows the VM to boot.
 Alternatively you may be able to disable USB 3.0 in the BIOS.
 If the BIOS does not have the option to disable USB 3.0, try running the following command in dom0 to force USB 2.0 modes for the USB ports: