Grammar and typo fixes (#125)

docs/README.md

@@ -1,18 +1,19 @@
+
 # Xen Orchestra
 
 ## Introduction
 
-Welcome on the official Xen Orchestra (XO) documentation.
+Welcome to the official Xen Orchestra (XO) documentation.
 
-XO is a web interface to visualize and administrate your XenServer (or XAPI enabled) hosts. **No agent** is requiered to make it work.
+XO is a web interface to visualize and administer your XenServer (or XAPI enabled) hosts. **No agent** is required for it to work.
 
-It aims to be easy to use on any device supporting modern web technologies (HTML 5, CSS 3, JavaScript) such as your desktop computer or your smartphone.
+It aims to be easy to use on any device supporting modern web technologies (HTML 5, CSS 3, JavaScript), such as your desktop computer or your smartphone.
 
 ![](https://pbs.twimg.com/profile_images/601775622675898368/xWbbafyO_400x400.png)
 
 ## XOA quick deploy
 
-SSH on your XenServer, and execute this:
+SSH to your XenServer, and execute the following:
 
 ```
 bash -c "$(curl -s http://xoa.io/deploy)"

docs/architecture.md

@@ -1,16 +1,17 @@
+
 # Architecture
 
-Xen Orchestra (XO) is a software built with a server and clients, such as the web client, `xo-web`, but also a CLI capable client, called `xo-cli`.
+Xen Orchestra (XO) is software built with a server and clients, such as the web client `xo-web`, but also a CLI capable client, called `xo-cli`.
 
-> XO is totally agent-less: it means that you don't have to install any program on your hosts to get it working!
+> XO is totally agent-less: you don't have to install any program on your hosts to get it working!
 
 ## XOA
 
-*Xen Orchestra virtual Appliance* (XOA) is a virtual machine with Xen Orchestra already installed, thus working out-of-the-box.
+*Xen Orchestra Virtual Appliance* (XOA) is a virtual machine with Xen Orchestra already installed, thus working out-of-the-box.
 
-This is the easiest way to try Xen Orchestra in a minute.
+This is the easiest way to try Xen Orchestra quickly.
 
-Your XOA is connected to all your hosts, or on the pool master only if you are using Pools in XenServer:
+Your XOA is connected to all your hosts, or the pool master only if you are using Pools in XenServer:
 
 ![](./assets/partner2.jpg)
 
@@ -19,9 +20,9 @@ Your XOA is connected to all your hosts, or on the pool master only if you are u
 ![](./assets/xo-arch.jpg)
 
 Xen Orchestra itself is built as a modular solution. Each part has its role:
-- the core is "[xo-server](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server/)", a daemon dealing directly with XenServer or XAPI capable hosts. This is where users are stored, and it's the center point for talking to your whole Xen infrastructure.
+- The core is "[xo-server](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-server/)" - a daemon dealing directly with XenServer or XAPI capable hosts. This is where users are stored, and it's the center point for talking to your whole Xen infrastructure.
-- the Web interface is in "[xo-web](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-web)": you are running it directly in your browser. The connection with "xo-server" is done via *WebSockets*.
+- The web interface is "[xo-web](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-web)" - it runs directly from your browser. The connection with ```xo-server``` is done via *WebSockets*.
-- "[xo-cli](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-cli)" is a module allowing to send commands directly from the command line.
+- "[xo-cli](https://github.com/vatesfr/xen-orchestra/tree/master/packages/xo-cli)" is a module allowing you to send commands directly from the command line.
 
 
-We already have other modules around it (like the LDAP plugin for example). It allows to use this modular architecture to add further parts later. It's completely flexible, allowing us to adapt Xen Orchestra in every existing work-flow.
+We have other modules as well (like the LDAP plugin for example). It allows us to use this modular architecture to add further parts as we need them. It's completely flexible, allowing us to adapt Xen Orchestra to every existing workflow.

docs/xo-server.md

@@ -1,10 +1,11 @@
+
 # xo-server
 
-XO-Server is the core of Xen Orchestra. Its central role opens a lot of possibilities versus other solutions. Let's see why.
+XO-Server is the core of Xen Orchestra. Its central role opens a lot of possibilities versus other solutions -  let's see why.
 
 ### Daemon mode
 
-As a daemon, XO-server is always up. In this way, it can listen and record every event occurring on your whole Xen infrastructure. Connections are always open and it can cache informations before serving it to another client (CLI, Web or anything else).
+As a daemon, XO-Server is always up. Because of this, it can listen and record every event occurring on your entire Xen infrastructure. Connections are always open and it can cache information before serving it to another client (CLI, Web or anything else).
 
 ### Central point
 
@@ -12,7 +13,7 @@ Contrary to XenCenter, each Xen Orchestra's client is connected to one XO-Server
 
 ![](./assets/without-xo.jpg)
 
-You can see how we avoid a lot of resources and bandwidth waste with a central point:
+You can see how we avoid a lot of resource and bandwidth waste with a central point:
 
 ![](./assets/with-xo.jpg)
 
@@ -22,13 +23,13 @@ Legacy interfaces use the "pull" model, requesting data every "x" seconds:
 
 ![](./assets/noevent.jpg)
 
-It's **not scalable** and slow.
+It's **not scalable** and **slow**.
 
-With XO < 3.4, we used events in the following way:
+Previously with XO < 3.4, we used events in the following way:
 
 ![](./assets/semievent.jpg)
 
-But the interface was still lagging behind the server. With XO 3.4, we now have a full event system, allowing instant display of what is happening on your infrastructure:
+But the interface was still lagging behind the server. With XO 3.4 and beyond, we now have a full event system, allowing instant display of what's happening on your infrastructure:
 
 ![](./assets/fullevent.jpg)
 
@@ -46,31 +47,31 @@ A good example is the console: you can now expose your consoles even if your cli
 
 #### VM streaming
 
-Another possibility is to stream a VM from a host to another.
+Another possibility is to stream a VM from one host to another.
 
 To do that previously, you needed to export your VM somewhere, then re-import it:
 
 ![](https://xen-orchestra.com/blog/content/images/2015/10/oldsolution.png)
 
-Thanks to our architecture, it's now far better:
+Thanks to our architecture, it's now far easier:
 
 ![](https://xen-orchestra.com/blog/content/images/2015/10/newsolution.png)
 
 
 #### Patching on the fly
 
-To install a patch manually, you need a lot of steps: find, download, extract and apply the patch, sequentially.
+To install a patch manually, it requires a lot of steps: find, download, extract and apply the patch, sequentially.
 
-"xo-server" can do all these steps once:
+"xo-server" can do all these steps at once:
 
-1. downloading automatically the patch on Citrix servers
+1. automatically download the patch from Citrix servers
-2. unzipping it and uploading it on the fly to your host
+2. unzip it and upload it on the fly to your host
-3. applying it as soon it's done
+3. apply it as soon it's done
 
 
 ### Pluggable
 
-It's really easy to plug other modules to XO-server, and extend or adapt the solution to your needs (see XO-web and XO-cli for real examples).
+It's really easy to connect other modules to XO-server, and extend or adapt the solution to your needs (see XO-web and XO-cli for real examples).
 
 #### ACLs