--- a/doc/book/en/B0011-schema-stdlib.en.txt	Thu Mar 26 15:18:48 2009 +0100
+++ b/doc/book/en/B0011-schema-stdlib.en.txt	Thu Mar 26 17:18:06 2009 +0100
@@ -10,7 +10,7 @@
 
 System schemas
 ``````````````
-The system entities available are :
+The system entities available are:
 
 * `EUser`, system users
 * `EGroup`, users groups
@@ -31,8 +31,11 @@
 * `Bookmark`, an entity type used to allow a user to customize his links within
   the application
 
-Cubes available
-```````````````
+(The first 'E' in some of the names is the first letter of 'Erudi', 
+`CubicWeb`'s old name; it might be changed/removed some day.)
+
+  Cubes available
+  ```````````````
 
 An application is based on several basic cubes. In the set of available
 basic cubes we can find for example :

--- a/doc/book/en/B0040-migration.en.txt	Thu Mar 26 15:18:48 2009 +0100
+++ b/doc/book/en/B0040-migration.en.txt	Thu Mar 26 17:18:06 2009 +0100
@@ -5,10 +5,10 @@
 Migration
 =========
 
-One of the main concept in `CubicWeb` is to create incremental applications
-and for this purpose multiple actions are provided to facilitate the improvement
-of an application and in particular changes applied to the data model
-without loosing existing data.
+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 application, and in particular to handle the changes to be applied
+to the data model, without loosing existing data.
 
 The current version of an application model is provided in the file
 `__pkginfo__.py` as a tuple of 3 integers.
@@ -16,8 +16,8 @@
 Migration scripts management
 ----------------------------
 
-Migration scripts needs to be located in the directory `migration` of your
-application and nammed accordingly:
+Migration scripts has to be located in the directory `migration` of your
+application and named accordingly:
 
 ::
 
@@ -25,26 +25,27 @@
 
 in which : 
 
-* X.Y.Z is the model version number to which the script enable to migrate
+* X.Y.Z is the model version number to which the script enables to migrate.
 
-* *mode* (between the last "_" and the extension ".py") indicates which part
-  of the application (RQL server, web server) the script applies to in case
-  of distributed installation. Its value could be :
+* *mode* (between the last "_" and the extension ".py") is used for 
+  distributed installation. It indicates to which part
+  of the application (RQL server, web server) the script applies.
+  Its value could be :
 
   * `common`, applies to the RQL server as well as the web server and updates
     files on the hard drive (configuration files migration for example).
 
-  * `web`, applies only to the web server and updates files on the hard drive
+  * `web`, applies only to the web server and updates files on the hard drive.
 
   * `repository`, applies only to the RQL server and updates files on the
-    hard drive
+    hard drive.
 
   * `Any`, applies only to the RQL server and updates data in the database
-    (schema and data migration for example)
+    (schema and data migration for example).
 
 Again in the directory `migration`, the file `depends.map` allows to indicate
 that to migrate to a particular model version, you always have to first migrate
-to a particular `CubicWeb` version. This file can contains comments (lines
+to a particular `CubicWeb` version. This file can contain comments (lines
 starting by `#`) and a dependancy is listed as follows: ::
   
   <model version n° X.Y.Z> : <cubicweb version n° X.Y.Z>
@@ -53,7 +54,7 @@
 
   0.12.0: 2.26.0
   0.13.0: 2.27.0
-  # 0.14 works with 2.27 <= erudi <= 2.28 at least
+  # 0.14 works with 2.27 <= cubicweb <= 2.28 at least
   0.15.0: 2.28.0
 
 Base context
@@ -68,18 +69,16 @@
 
 * `appltemplversion`, application model version of the instance
 
-* `applerudiversion`, cubicweb instance version
-
 * `templversion`, installed application model version
 
-* `erudiversion`, installed cubicweb version
+* `cubicwebversion`, installed cubicweb version
 
 * `confirm(question)`, function interrogating the user and returning true
-  if the user answers yes, false otherwise (always returns true when in a
+  if the user answers yes, false otherwise (always returns true in
   non-interactive mode)
 
-* `_`, function fonction equivalent to `unicode` allowing to flag the strings
-  to internationalize in the migration scripts
+* the function `_`, it is equivalent to `unicode` allowing to flag the strings
+  to internationalize in the migration scripts.
 
 In the `repository` scripts, the following identifiers are also defined:
 
@@ -89,7 +88,7 @@
   current migration)
 
 * `newschema`, installed schema on the file system (e.g. schema of 
-  the updated model and erudi)
+  the updated model and cubicweb)
 
 * `sqlcursor`, SQL cursor for very rare cases where it is really
    necessary or beneficial to go through the sql
@@ -109,7 +108,7 @@
 * `drop_attribute(etype, attrname, commit=True)`, removes an attribute from an
   existing entity type.
 
-* `rename_attribute(etype, oldname, newname, commit=True)`, rename an attribute
+* `rename_attribute(etype, oldname, newname, commit=True)`, renames an attribute
             
 * `add_entity_type(etype, auto=True, commit=True)`, adds a new entity type.
   If `auto` is True, all the relations using this entity type and having a known