[doc] Some rewording

INSTALL.t2t

@@ -24,13 +24,14 @@ above should also work. Compilation of the C modules has been tested
 with GCC and Clang and should work with older versions of these
 compilers.
 
-The additional tools are also recommended:
+The following additional tools are recommended:
 - ``perl``
 - ``pod2man`` (normally provided in the same package as //Perl//)
 - ``doxygen``
 - ``txt2tags``
 
-If you miss one or more of the requirements, the concerned modules will
+
+If you're missing one or more of the requirements, all the modules will
 not be built.
 
 OwlPS uses //CMake// as a build manager. You need to install it (package
@@ -40,12 +41,11 @@ it is not shipped with the main CMake package (package
 ``cmake-curses-gui`` on Debian).
 
 It is strongly advised to build out of the source tree, which can be
-achieved by typing for instance (assuming OwlPS' source files are in
+achieved by typing the following commands from the source tree:
-``~/owlps``):
 
 ```
-    mkdir ~/owlps/build
+    mkdir build
-    cd ~/owlps/build
+    cd build
     cmake ..
 ```
 
@@ -130,7 +130,7 @@ OwlPS Client, just type ``make owlps-client.static``. If you want to
 generate static executables for all the modules, call the ``static``
 meta-target (``make static``).
 
-So called “semistatic” targets are also provided. The semistatic
+So-called “semistatic” targets are also provided. The semistatic
 executables are statically linked to OwlPS libraries (such as libowlps),
 but dynamically linked to other libraries. This allows for quick testing
 of libraries changes as well as running on systems where you can install
@@ -152,7 +152,7 @@ To run the unit tests, use the ``test`` target:
 
 ``` make test
 
-Currently, only OwlPS Positioner has unit tests.
+Currently, only OwlPS Positioner has (partial) unit tests.
 
 
 = Compiling for OpenWrt =

doc/owlps.t2t

@@ -23,12 +23,12 @@ June 2013
 + What is OwlPS? +
 
 **OwlPS** (//Owl Positioning System//) is a positioning (localization)
-system based on the IEEE 802.11 radio network (Wi-Fi). It targets mainly
+system based on the IEEE 802.11 radio network (Wi-Fi), targeting mainly
-UNIX-like operating systems and is developed and tested primarily on
+indoor environments. It is developed and tested primarily on GNU/Linux,
-GNU/Linux, but it should work on BSD platforms as well. Originally
+but it should work on BSD platforms as well. Originally developed at the
-developed at the University of Franche-Comté (Université de
+University of Franche-Comté (Université de Franche-Comté, France), it is
-Franche-Comté, France), it is released under the terms of the CeCILL
+released under the terms of the CeCILL free software license (GNU
-free software license (GNU GPL-compatible).
+GPL-compatible).
 
 OwlPS uses an infrastructure-centred architecture, which means the
 infrastructure does the measurements and computes the mobile terminals'
@@ -64,10 +64,12 @@ If you would like to contribute to OwlPS, you can:
 - use it, test it, and report suggestions and bugs on the forge:
   http://code.lm7.fr/p/owlps/issues/
 
-- get the last development code, add functionalities and send me pull
+- get the latest development code, add functionalities and send me pull
-  requests by email or submit code reviews on the forge:
+  requests by email or on the forge:
   http://code.lm7.fr/p/owlps/review/
 
+  You can get improvement ideas from the ``TODO.t2t`` file.
+
 
 
 
@@ -76,8 +78,8 @@ If you would like to contribute to OwlPS, you can:
 
 ++ Timeline ++
 
-There is no precise timeline for OwlPS, but the file TODO.t2t lists a
+There is no precise timeline for OwlPS, but the file ``TODO.t2t`` lists
-bunch of things that should be addressed at some point. A development
+a bunch of things that should be addressed at some point. A development
 point release is made after some work has been done, usually mainly on a
 particular topic. Usually such a release represents between 30 and 90
 commits.
@@ -114,11 +116,12 @@ revision number is not mandatory, but it is allowed. For example:
 
 The communication protocol between the elements of the system is
 guaranteed to stay the same across revisions of a given stable branch
-(e.g. mixing modules of versions 1.2, 1.2.1 and 1.2.2 is possible). In
+(e.g. mixing modules of versions 1.2, 1.2.1 and 1.2.2 would be
-development branches, the protocol can evolve from one point release to
+possible). In development branches, the protocol can evolve from one
-the next (e.g.  mixing modules of versions 1.3.0 and 1.3.1 is not
+point release to the next (e.g.  mixing modules of versions 1.3.0 and
-possible). Changes in communication protocols, libraries' APIs, file
+1.3.1 may not be possible). Changes in communication protocols,
-formats, etc., are pointed out in the ``CHANGELOG`` file.
+libraries' APIs, file formats, etc., are documented in the ``CHANGELOG``
+file.