--- a/doc/book/en/annexes/faq.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/annexes/faq.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -39,11 +39,10 @@
   When doing development, you need a real language and template
   languages are not real languages.
 
-  Using Python enables developing applications for which code is
-  easier to maintain with real functions/classes/contexts
-  without the need of learning a new dialect. By using Python,
-  we use standard OOP techniques and this is a key factor in a
-  robust application.
+  Using Python instead of a template langage for describing the user interface
+  makes it to maintain with real functions/classes/contexts without the need of
+  learning a new dialect. By using Python, we use standard OOP techniques and
+  this is a key factor in a robust application.
 
 Why do you use the LGPL license to prevent me from doing X ?
 ------------------------------------------------------------

--- a/doc/book/en/annexes/rql/intro.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/annexes/rql/intro.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -5,41 +5,38 @@
 Goals of RQL
 ~~~~~~~~~~~~
 
-The goal is to have a language emphasizing the way of browsing
-relations. As such, attributes will be regarded as cases of
-special relations (in terms of implementation, the language
-user should see virtually no difference between an attribute and a
+The goal is to have a language emphasizing the way of browsing relations. As
+such, attributes will be regarded as cases of special relations (in terms of
+implementation, the user should see no difference between an attribute and a
 relation).
 
-RQL is inspired by SQL but is the highest level. A knowledge of the
-*CubicWeb* schema defining the application is necessary.
-
 Comparison with existing languages
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 SQL
 ```
-RQL builds on the features of SQL but is at a higher level
-(the current implementation of RQL generates SQL). For that it is limited
-to the way of browsing relations and introduces variables.
-The user does not need to know the model underlying SQL, but the *CubicWeb*
-schema defining the application.
+
+RQL may remind of SQL but works at a higher abstraction level (the *CubicWeb*
+framework generates SQL from RQL to fetch data from relation databases). RQL is
+focused on browsing relations. The user needs only to know about the *CubicWeb*
+data model he is querying, but not about the underlying SQL model.
+
+Sparql
+``````
+
+The query language most similar to RQL is SPARQL_, defined by the W3C to serve
+for the semantic web.
 
 Versa
 `````
-We should look in more detail, but here are already some ideas for
-the moment ... Versa_ is the language most similar to what we wanted
-to do, but the model underlying data being RDF, there is some
-number of things such as namespaces or handling of the RDF types which
-does not interest us. On the functionality level, Versa_ is very comprehensive
-including through many functions of conversion and basic types manipulation,
-which may need to be guided at one time or another.
-Finally, the syntax is a little esoteric.
 
-Sparql
-``````
-The query language most similar to RQL is SPARQL_, defined by the W3C to serve
-for the semantic web.
+We should look in more detail, but here are already some ideas for the moment
+... Versa_ is the language most similar to what we wanted to do, but the model
+underlying data being RDF, there is some number of things such as namespaces or
+handling of the RDF types which does not interest us. On the functionality
+level, Versa_ is very comprehensive including through many functions of
+conversion and basic types manipulation, which may need to be guided at one time
+or another.  Finally, the syntax is a little esoteric.
 
 
 The different types of queries

--- a/doc/book/en/development/devweb/internationalization.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/development/devweb/internationalization.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -69,6 +69,8 @@
    used by a particular instance's schema as they are generated
    automatically.
 
+If you need to add messages on top of those that can be found in the source,
+you can create a file named `i18n/static-messages.pot`.
 
 Handle the translation catalog
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--- a/doc/book/en/development/migration/index.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/development/migration/index.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -5,10 +5,10 @@
 Migration
 =========
 
-One of the main concept in *CubicWeb* is to create incremental applications.
-For this purpose, multiple actions are provided to facilitate the improvement
-of an instance, and in particular to handle the changes to be applied
-to the data model, without loosing existing data.
+One of the main design goals of *CubicWeb* was to support iterative and agile
+development. For this purpose, multiple actions are provided to facilitate the
+improvement of an instance, and in particular to handle the changes to be
+applied to the data model, without loosing existing data.
 
 The current version of a cube (and of cubicweb itself) is provided in the file
 `__pkginfo__.py` as a tuple of 3 integers.

--- a/doc/book/en/intro/concepts/index.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/intro/concepts/index.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -155,7 +155,7 @@
 identifier in the same registry, At runtime, appobjects are selected in the
 vregistry according to the context.
 
-Application objects are stored in the registry using a two level hierarchy :
+Application objects are stored in the registry using a two-level hierarchy :
 
   object's `__registry__` : object's `id` : [list of app objects]
 

--- a/doc/book/en/intro/tutorial/conclusion.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/intro/tutorial/conclusion.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -3,15 +3,13 @@
 What's next?
 ------------
 
-We demonstrated how from a straight out of the box *CubicWeb*
-installation, you can build your web-application based on a
-schema. It's all already there: views, templates, permissions,
-etc. The step forward is now for you to customize according
-to your needs.
+We demonstrated how from a straight out of the box *CubicWeb* installation, you
+can build your web application based on a data model. It's all already there:
+views, templates, permissions, etc. The step forward is now for you to customize
+according to your needs.
 
-More than a web application, many features are available to
-extend your application, for example: RSS channel integration
-(:ref:`rss`), hooks (:ref:`hooks`), support of sources such as
-Google App Engine (:ref:`gaecontents`) and lots of others to
-discover through our book.
+Many features are available to extend your application, for example: RSS channel
+integration (:ref:`rss`), hooks (:ref:`hooks`), support of sources such as
+Google App Engine (:ref:`gaecontents`) and lots of others to discover through
+our book.
 

--- a/doc/book/en/intro/tutorial/create-cube.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/intro/tutorial/create-cube.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -91,8 +91,8 @@
 
 .. image:: ../../images/blog-demo-first-page.png
 
-Please notice that so far, the *CubicWeb* franework managed all aspects of
-the web application based on the schema provided at first.
+Please notice that so far, the *CubicWeb* framework managed all aspects of
+the web application based on the schema provided at the beginning.
 
 
 Add entities

--- a/doc/book/en/intro/tutorial/maintemplate.rst	Tue Jul 28 19:59:50 2009 +0200
+++ b/doc/book/en/intro/tutorial/maintemplate.rst	Tue Jul 28 20:26:45 2009 +0200
@@ -36,8 +36,8 @@
 Customize header
 `````````````````
 
-Let's now move the search box in the header and remove the login form
-from the header. We'll show how to move it to the left column of the application.
+Let's now move the search box in the header and remove the login form from the
+header. We'll show how to move it to the left column of the user interface.
 
 Let's say we do not want anymore the login menu to be in the header