Merge branch 'resolve-transifex-issues' of https://github.com/tokideveloper/qubes-doc into tokideveloper-resolve-transifex-issues

developer/building/development-workflow.md

@@ -19,7 +19,7 @@ assumes you're using qubes-builder to build Qubes.
 
 # Repositories and committing Code
 
-Qubes is split into a bunch of git repos. This are all contained in the
+Qubes is split into a bunch of git repos. These are all contained in the
 `qubes-src` directory under qubes-builder. Subdirectories there are separate
 components, stored in separate git repositories.
 
@@ -117,7 +117,7 @@ cd ../..
 vi series.conf
 ~~~
 
-#### Building RPMS
+#### Building RPMs
 
 TODO: Is this step generic for all subsystems?
 
@@ -130,13 +130,13 @@ distinguish between different versions of the same package.
 You might want to take a moment here to review (git diff, git status), commit
 your changes locally.
 
-To actually build RPMS, in qubes-builder:
+To actually build RPMs, in qubes-builder:
 
 ~~~
 make linux-kernel
 ~~~
 
-RPMS will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64:
+RPMs will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64:
 
 ~~~
 -rw-rw-r-- 1 user user 42996126 Nov 17 04:08 kernel-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm
@@ -153,7 +153,7 @@ RPMS will appear in qubes-src/linux-kernel/pkgs/fc20/x86\_64:
 if all repository are tagged with signed tag.
 2. `make show-vtags` - show version of each component (based on git tags) -
 mostly useful just before building ISO. **Note:** this will not show version
-for components containing changes since last version tag
+for components containing changes since last version tag.
 3. `make push` - push change from **all** repositories to git server. You must
 set proper remotes (see above) for all repositories first.
 4. `make prepare-merge` - fetch changes from remote repositories (can be
@@ -166,7 +166,7 @@ FETCH_HEAD` (in each repo directory). Or `make do-merge` to merge all of them.
 
 When developing it is convenient to be able to rapidly test changes. Assuming
 you're developing Qubes on Qubes, you should be working in a special VM for
-Qubes and occasionally you will want to transfer code or rpms back to dom0 for
+Qubes and occasionally you will want to transfer code or RPMs back to dom0 for
 testing.
 
 Here are some handy scripts Marek has shared to facilitate this.

developer/building/qubes-builder.md

@@ -99,7 +99,7 @@ cp example-configs/qubes-os-master.conf builder.conf
 
 make get-sources
 
-# And now to build all Qubes rpms (this will take a few hours):
+# And now to build all Qubes RPMs (this will take a few hours):
 
 make qubes
 

developer/general/gsoc.md

@@ -332,7 +332,7 @@ immune to altering past entries. See
   in files there, no file manager, etc).
 - Configure GNOME to not look into external devices plugged in (no auto
   mounting, device notifications etc).
-- Package above modifications as rpms, preferably as extra configuration files
+- Package above modifications as RPMs, preferably as extra configuration files
   and/or plugins than overwriting existing files. Exceptions to this rule may
   apply if no other option.
 - Adjust comps.xml (in installer-qubes-os repo) to define package group with

developer/general/gsod.md

@@ -94,7 +94,7 @@ Here are some successful projects which have been implemented in the past by Goo
 **Project**: Consolidate troubleshooting guides
 
 **Brief explanation**: Troubleshooting guides are scattered across many pages and sometimes incomplete, leading to repeatedly posting the same instruction over and over when helping users to diagnose problems.
-This could be helped by writing consolidated guide with with a clear list of symptom-action layout.
+This could be helped by writing a consolidated guide with a clear list of symptom-action layout.
 
 **Expected results**:
 

developer/services/dom0-secure-updates.md

@@ -44,7 +44,7 @@ The qubes-receive-updates script processes the untrusted input from Update VM: i
 
 Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-cached.repo).
 
-Finally, qubes-dom0-update runs ``yum update`` that fetches the rpms from qubes-cached repo and installs them as usual.
+Finally, qubes-dom0-update runs ``yum update`` that fetches the RPMs from qubes-cached repo and installs them as usual.
 
 Security benefit of our update mechanism
 ----------------------------------------

introduction/faq.md

@@ -114,7 +114,7 @@ These programs are popular because they're designed primarily to be easy to use
 However, the fact that Type 2 hypervisors run under the host OS means that they're really only as secure as the host OS itself.
 If the host OS is ever compromised, then any VMs it hosts are also effectively compromised.
 
-By contrast, Qubes uses a "Type 1" or "bare metal" hypervisor called [Xen](https://www.xenproject.org/).
+By contrast, Qubes uses a "Type 1" or "bare-metal" hypervisor called [Xen](https://www.xenproject.org/).
 Instead of running inside an OS, Type 1 hypervisors run directly on the "bare metal" of the hardware.
 This means that an attacker must be capable of subverting the hypervisor itself in order to compromise the entire system, which is vastly more difficult.
 
@@ -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?
 
@@ -554,7 +554,7 @@ A fully encrypted drive does not appear in Nautilus.
 
 The workaround is to manually decrypt and mount the drive:
 
-1. Attach usb device to qube - it should be attached as `/dev/xvdi` or similar.
+1. Attach USB device to qube - it should be attached as `/dev/xvdi` or similar.
 2. `sudo cryptsetup open /dev/xvdi bk --type luks`
 3. `sudo cryptsetup status /dev/mapper/bk` (Shows useful status info.)
 4. `sudo mount /dev/mapper/bk /mnt`
@@ -563,7 +563,7 @@ The decrypted device is now available at `/mnt` - when you have finished using i
 
 1. `sudo umount /mnt`
 2. `sudo cryptsetup close bk --type luks`
-3. Remove usb from qube.
+3. Remove USB from qube.
 
 ### Windows Update is stuck.
 

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/advanced-configuration/usb-qubes.md

@@ -54,7 +54,7 @@ Alternatively, you can create a USB qube manually as follows:
 5. Recommended: Check the box on the "Basic" tab which says "Start VM automatically on boot".
    (This will help to mitigate attacks in which someone forces your system to reboot, then plugs in a malicious USB device.)
 
-If the USB qube will not start, please have a look at the [faq](/faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot).
+If the USB qube will not start, please have a look at the [faq](/faq/#i-created-a-usb-vm-and-assigned-usb-controllers-to-it-now-the-usb-vm-wont-boot).
 
 ## Enable a USB keyboard for login ##
 

user/common-tasks/backup-restore.md

@@ -114,7 +114,7 @@ This brings up the **Qubes Restore VMs** window.
 4. If your backup is encrypted, you must check the **Encrypted backup** box.
 If a passphrase was supplied during the creation of your backup (regardless of whether it is encrypted), then you must supply it here.
 
-   **Note:** The passphrase which was supplied when the backup was created was used for **both** encryption/decryption and integrity verification.
+   **Note:** The passphrase which was supplied when the backup was created is used for **both** encryption/decryption and integrity verification.
    If the backup was not encrypted, the supplied passphrase is used only for integrity verification.
    All backups made from a Qubes R4.0 system will be encrypted.
 

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: