Index: classpath.html
===================================================================
--- classpath.html	(revision 987761)
+++ classpath.html	(working copy)
@@ -28,7 +28,7 @@
 
 <span class="tagdoc" id="ivysettings.classpath">Includes a jar in the classpath used to load plugins.</span> <span class="since">since 1.4</span>
 
-This let you add ivy plugins without relying on ant classpath for instance, easing therefore the use of ivy in multiple execution environment (ant, standalone, IDE plugins, ...).
+This let you add ivy plugins without relying on an external classpath (the ant classpath for instance), therefore easing the use of ivy in multiple execution environments (ant, standalone, IDE plugins, ...).
 
 <h1>Attributes</h1>
 <table class="ivy-attributes">
@@ -52,7 +52,7 @@
   </resolvers>
 </ivysettings>
 </code>
-Adds custom-resolver.jar found in the same directory as the ivysettings.xml file itself to the classpath, then define a custom resolver and use it.
+Adds the custom-resolver.jar (found in the same directory as the ivysettings.xml file) to the classpath, then defines a custom resolver and uses it.
 
 <hr/>
 <code type="xml">
@@ -64,7 +64,7 @@
   </resolvers>
 </ivysettings>
 </code>
-Same as above, but find the jar on a web server.
+Same as above, but finds the jar on a web server.
 	</textarea>
 <script type="text/javascript">xooki.postProcess();</script>
 </body>
Index: conflict-managers.html
===================================================================
--- conflict-managers.html	(revision 987761)
+++ conflict-managers.html	(working copy)
@@ -26,28 +26,27 @@
 	<textarea id="xooki-source">
 <b>Tag:</b> conflict-managers
 
-<span class="tagdoc" id="ivysettings.conflict-managers">Defines a list of <a href="../concept.html#conflict">conflicts managers</a> usable in ivy.</span> Each conflict manager is identified by its name, given as an attribute.
-The child tag used for the conflict manager must be equal to a name of a conflict manager type (either built-in
-or added with the typedef tag).
+<span class="tagdoc" id="ivysettings.conflict-managers">Defines a list of <a href="../concept.html#conflict">conflicts managers</a> usable in Ivy.</span> Each conflict manager is identified by its name, given as an attribute.
+The child tag used for the conflict manager must be equal to a name of a conflict manager type (either built-in or added with the typedef tag).
 
-Here is a list of predefined conflicts managers (which do not require anything in the configuration file):
+Here is a list of built-in conflicts managers (which do not require anything in the configuration file):
 <ul>
-<li>all</li> this conflicts manager resolve conflicts by selecting all revisions. Also called NoConflictManager, it does evict any module.
+<li>all</li> this conflicts manager resolve conflicts by selecting all revisions. Also called the NoConflictManager, it doesn't evict any modules.
 <li>latest-time</li> this conflict manager selects only the 'latest' revision, latest being defined as the latest in time. Note that latest in time is costly to compute, so prefer latest-revision if you can.
 <li>latest-revision</li> this conflict manager selects only the 'latest' revision, latest being defined by a string comparison of revisions.
-<li>latest-compatible</li> this conflict manager selects the latest version in the conflicts which can result in a compatible set of dependencies. This means that in the end this conflict manager does not allow any conflict (like the strict conflict manager), except that it follows a best effort strategy to try to find a set of compatible modules (according to the version constraints)
+<li>latest-compatible</li> this conflict manager selects the latest version in the conflicts which can result in a compatible set of dependencies. This means that in the end, this conflict manager does not allow any conflicts (similar to the strict conflict manager), except that it follows a best effort strategy to try to find a set of compatible modules (according to the version constraints)
 <li>strict</li> this conflict manager throws an exception (i.e. causes a build failure) whenever a conflict is found.
 </ul>
 The two "latest" conflict managers also take into account the force attribute of the dependencies.
-Indeed direct dependencies can declare a force attribute (see <a href="../ivyfile/dependency.html">dependency</a>), which indicates the the revision given in the direct dependency should be prefered over indirect dependencies.
+Indeed direct dependencies can declare a force attribute (see <a href="../ivyfile/dependency.html">dependency</a>), which indicates that the revision given in the direct dependency should be preferred over indirect dependencies.
 
 Here is a list of conflict manager types available, which can be used to define your own custom conflict managers:
 <ul>
 <li>latest-cm</li>The latest conflict manager uses a latest strategy to select the latest revision among several ones. Both latest-time and latest-revision conflict managers are based on this conflict manager type. It takes 'latest' as attribute to define which latest strategy should be used. Example:
 <code><latest-cm name="mylatest-conflict-manager" latest="my-latest-strategy"/></code>
-<li>compatible-cm</li>The latest compatible conflict manager uses a latest strategy to select the latest revision among several ones. It takes 'latest' as attribute to define which latest strategy should be used. Example:
+<li>compatible-cm</li>The latest compatible conflict manager uses a latest strategy to select the latest revision among several ones. It takes 'latest' as an attribute to define which latest strategy should be used. Example:
 <code><compatible-cm name="my-latest-compatible-conflict-manager" latest="my-latest-strategy"/></code>
-<li>regexp-cm</li>This conflict manager is based on a regular expression and throw an exception (i.e. causes a build failure) when a conflict is found with versions with different matching group. For instance if a conflict is found between 1.2.x and 1.3.y it will throw an exception if the regular exception is (.*)\.\d, because the matching group will match different string (1.2 and 1.3). 1.2.1 and 1.2.2 won't throw an exception with the same regular expression. The regular expression is set using the 'regexp' attribute. A 'ignoreNonMatching' attribute can also be set to simply warrn when a version is found which does not match the regular expression, instead of throwing an exception.
+<li>regexp-cm</li>This conflict manager is based on a regular expression and throws an exception (i.e. causes a build failure) when a conflict is found with versions with different matching group. For instance if a conflict is found between 1.2.x and 1.3.y it will throw an exception if the regular expression is (.*)\.\d, because the matching group will match different strings (1.2 and 1.3). 1.2.1 and 1.2.2 won't throw an exception with the same regular expression. The regular expression is set using the 'regexp' attribute. A 'ignoreNonMatching' attribute can also be set to simply warn when a version is found which does not match the regular expression, instead of throwing an exception.
 </ul>
 
 <h3>Child elements</h3>
Index: include.html
===================================================================
--- include.html	(revision 987761)
+++ include.html	(working copy)
@@ -71,7 +71,7 @@
 </ivysettings> 
 </code>
 with ivysettings-macro.xml being the ivysettings example given on the [[settings/macrodef macrodef documentation page]].
-This let reusing macro resolver easy.
+This lets us easily reuse the custom macro resolver.
 	</textarea>
 <script type="text/javascript">xooki.postProcess();</script>
 </body>
Index: latest-strategies.html
===================================================================
--- latest-strategies.html	(revision 987761)
+++ latest-strategies.html	(working copy)
@@ -26,18 +26,16 @@
 	<textarea id="xooki-source">
 <b>Tag:</b> latest-strategies
 
-<span class="tagdoc" id="ivysettings.latest-strategies">Defines a list of <a href="../concept.html#latest">latest strategies</a> usable in ivy.</span> Each latest strategy is identified by its name, given as an attribute.
+<span class="tagdoc" id="ivysettings.latest-strategies">Defines a list of <a href="../concept.html#latest">latest strategies</a> usable in Ivy.</span> Each latest strategy is identified by its name, given as an attribute.
 The child tag used for the latest strategy must be equal to a name of a latest strategy type (usually added with the typedef tag).
 
-The latest strategies which are always included in ivy (and do not require anything in the configuration file) are:
+The latest strategies which are included in Ivy by default are:
 <ul>
-<li>latest-time</li> compares the revisions date to know which is the latest. While this is often a good 
-strategy in terms of pertinence, it has the drawback to be costful to compute with distant repositories. If you use ivyrep, 
-for example, ivy has to ask the http server what is the date of each ivy file before knowing which is the latest.
-<li>latest-revision</li> compares the revisions as string, using an algorithm close to the one used in the php version_compare function.
-This algorithm takes into account special meaning of some text. For instance, with this strategy, 1.0-dev1 is considered
-before 1.0-alpha1, which in turn is before 1.0-rc1, which is before 1.0, which is before 1.0.1.
-<li>latest-lexico</li> compares the revisions as string, using lexicographic order (the one used by java string comparison).
+<li>latest-time</li> compares the revisions date to know which is the latest. While this is often a good strategy in terms of pertinence, it's drawback is that it can be slow when dealing with remote repositories. If you use ivyrep, 
+for example, Ivy has to ask the http server for the date of each ivy file before knowing which is the latest.
+<li>latest-revision</li> compares the revisions as strings, using an algorithm close to the one used in php's version_compare function.
+This algorithm takes into account the special meaning of some text. For instance, with this strategy, 1.0-dev1 is considered before 1.0-alpha1, which in turn is before 1.0-rc1, which is before 1.0, which is before 1.0.1.
+<li>latest-lexico</li> compares the revisions as strings, using lexicographic order (the one used by java string comparison).
 </ul>
 
 <h1>Child elements</h1>
@@ -64,13 +62,13 @@
   </latest-revision>
 </latest-strategies> 
 </code>
-Knowing that the default special meaning words are the following:
+Knowing that the default "special meaning" words are the following:
 <code type="xml">
     <specialMeaning name="dev" value="-1"/>
     <specialMeaning name="rc" value="1"/>
     <specialMeaning name="final" value="2"/>
 </code>
-You can even get rid or redefine the default special meanings by setting usedefaultspecialmeanings="false" on the latest-revision tag.
+You can even remove or redefine the default special meanings by setting usedefaultspecialmeanings="false" on the latest-revision tag.
 Example:
 <code type="xml">
 <latest-strategies>
Index: lock-strategies.html
===================================================================
--- lock-strategies.html	(revision 987761)
+++ lock-strategies.html	(working copy)
@@ -32,12 +32,12 @@
 
 Two lock strategies are registered by default:
 <ul>
-<li><b>no-lock</b></li> This lock strategy actually performs no locking at all, and thus should not be used in environment where the cache is shared by multiple processes. 
+<li><b>no-lock</b></li> This lock strategy actually performs no locking at all, and thus should not be used in an environment where the cache is shared by multiple processes. 
 
 This strategy is implemented by ([[svn:src/java/org/apache/ivy/plugins/lock/NoLockStrategy.java NoLockStrategy]])
 
 
-<li><b>artifact-lock</b></li> This strategy acquire a lock whenever a module descriptor or an artifact is downloaded to the cache, which makes a good solution when you want to share your repository cache.
+<li><b>artifact-lock</b></li> This strategy acquires a lock whenever a module descriptor or an artifact is downloaded to the cache, which makes a good solution when you want to share your repository cache.
 
 Note that this strategy is based on file locking, performed by default using the java.io.File.createNewFile() atomicity (which is documented as atomic in the javadoc, but not recommended to perform locks). A java.nio.FileLock based implementation is also provided, but according to our tests the createNewFile based one performs better and more reliably. We heavily recommend making your own testing in your target environment before relying on this lock strategy for heavily concurrent operations.
 
Index: macrodef.html
===================================================================
--- macrodef.html	(revision 987761)
+++ macrodef.html	(working copy)
@@ -26,18 +26,18 @@
 	<textarea id="xooki-source">
 <b>Tag:</b> macrodef
 
-<span class="tagdoc" id="ivysettings.macrodef">Defines a new dependency resolver type based upon an other one.</span> This definition is very similar to the macrodef feature of ant for defining macro tasks. <span class="since">since 1.3</span>
+<span class="tagdoc" id="ivysettings.macrodef">Defines a new dependency resolver type based upon another.</span> This definition is very similar to the macrodef feature of ant for defining macro tasks. <span class="since">since 1.3</span>
 
-This task eases the lot the process of creating new dependency resolver, because it avoid writing java code.
+This task eases the process of creating a new dependency resolver, because it avoids writing java code.
 
-It is generally used in combination with the [[settings/include]] feature to help reusing macro at several places.
+It is generally used in combination with the [[settings/include]] feature to help reuse a macro in multiple settings files.
 
-A macro is defined by writing the resolver it is equivalent to as if it were written in the resolver place, except that you can use attributes to pass parameters to the newly defined resolver type. Attributes are defined with a name and sometimes a default value, and are used using the following syntax: 
+A macro is defined by declaring an existing resolver within it. Then you can use attributes to pass parameters to the newly defined resolver type. Attributes are defined with a name, and optionally a default value, and are used using the following syntax: 
 <code>@{attributename}</code>
 <h2>Resolvers names</h2>
-Since you can use the same macro several times, and that your macro may define several resolvers (in a chain for instance), resolvers names need to be chosen carefully to avoid name conflicts (a resolver must have a unique name).
+Since you can use the same macro several times it can define several resolvers (in a chain for instance), the resolver names need to be chosen carefully to avoid name conflicts (each resolver must have a unique name).
 
-Therefore here is how Ivy deals with the names of the resolvers defined in a macro:
+Here is how Ivy deals with the names of the resolvers defined in a macro:
 <ul>
 <li>if there is no name attribute on a resolver in the macrodef, then Ivy will use the name given when using the macro. This is what usually should be done for the main resolver defined in the macro</li>
 <li>if there is a name attribute on a resolver in the macrodef, but this name doesn't contain a @{name} inside, then Ivy will use the provided name prefixed with the name of the macro separated by a dash</li>
Index: module.html
===================================================================
--- module.html	(revision 987761)
+++ module.html	(working copy)
@@ -72,35 +72,35 @@
   <module organisation="apache" name="*" resolver="myprojectsresolver"/>
 </modules>
 </code>
-Uses myprojectresolver for all modules from Apache.
+Uses myprojectresolver for all modules from <i>apache</i>.
 <hr/>
 <code type="xml">
 <modules>
   <module organisation="apache" name="commons-*" matcher="glob" resolver="myapachecommonsresolver"/>
 </modules>
 </code>
-Uses myapachecommonsresolver for all modules beginning by commons- from apache.
+Uses myapachecommonsresolver for all modules beginning with 'commons-' from 'apache'.
 <hr/>
 <code type="xml">
 <modules>
   <module organisation="apache" name="commons-[a-z]+" myextra="val.*" matcher="regexp" resolver="myapachecommonsresolver"/>
 </modules>
 </code>
-Uses myapachecommonsresolver for all modules from 'apache' beginning by 'commons-' followed by any number of alphabetic lowercase characters, and with the extra attribute 'myextra' having a value starting with 'val'.
+Uses myapachecommonsresolver for all modules from <i>apache</i> beginning with 'commons-' followed by any number of alphabetic lowercase characters, and with the extra attribute 'myextra' having a value beginning with 'val.'.
 <hr/>
 <code type="xml">
 <modules>
   <module organisation="apache" name="ivy*" matcher="glob" conflict-manager="latest-time"/> 
 </modules>
 </code>
-Uses latest-time conflict manager for all modules from apache which name begins with ivy.
+Uses latest-time conflict manager for all modules from <i>apache</i> whose name begins with 'ivy'.
 <hr/>
 <code type="xml">
 <modules>
   <module organisation="apache" name="ivy*" matcher="glob" branch="fix-103"/> 
 </modules>
 </code>
-Uses 'fix-103' as default branch for all modules from apache which name begins with ivy.
+Uses 'fix-103' as default branch for all modules from <i>apache</i> whose name begins with 'ivy'.
 
 
 
Index: modules.html
===================================================================
--- modules.html	(revision 987761)
+++ modules.html	(working copy)
@@ -28,11 +28,11 @@
 
 <span class="tagdoc" id="ivysettings.modules">Defines per module or module set settings.</span>
 
-The rules are given by defining a module set, using pattern for module organisation and name, and giving some settings for the set, like the name of the corresponding resolver to use.
+The rules are given by defining a module set, using a pattern for module organisation and name, and giving some settings for the set, like the name of the corresponding resolver to use.
 
-If no rule match a given module, the default setting will be used.
+If no rules match a given module, the default setting will be used.
 
-Even if not required, because the use of a default big resolver (chain, for instance) able to resolve all dependencies can answer all the needs, the configuration of smaller resolvers used for different cases can improve performances a lot. For instance, if you have a local repository for your modules and a distant repository for third party libraries, it is a good idea to have two separate resolvers, and configure ivy to use one for all your modules and another for the rest (the default one).
+Note: You can greatly improve the performance of dependency resolution by configuring multiple smaller resolvers instead of one large resolver (i.e. chain). For instance, if you have a local repository for your modules and a remote repository for third party libraries, it is a good idea to have two separate resolvers, one for all of your modules and another for the rest (the default one).
 
 <h1>Child elements</h1>
 <table class="ivy-children">
Index: namespace.html
===================================================================
--- namespace.html	(revision 987761)
+++ namespace.html	(working copy)
@@ -26,13 +26,13 @@
 	<textarea id="xooki-source">
 <b>Tag:</b> namespace
 
-<span class="tagdoc" id="ivysettings.namespaces.namespace">Defines a new namespace. A namespace is identified by a name, which is used to reference the namespace in the resolvers using the namespace.</span>
+<span class="tagdoc" id="ivysettings.namespaces.namespace">Defines a new namespace. A namespace is identified by a name, which can be referenced by one of the [[settings/resolvers]].</span>
 
-Namespaces overview is given in the [[settings/namespaces]] documentation.
+An overview of Namespaces is given in the [[settings/namespaces]] documentation.
 
-A namespace mainly consists of a list of rules, each rule defining a translation between system namespace and the defined namespace, and vice versa.
+A namespace mainly consists of a list of rules, each rule defining a translation between a system namespace and the defined namespace, and vice versa.
 
-There are two main possibilities for using these rules. By default, a namespace iterate through the rules, and when it finds one that translate the given name, it returns the translated name. But the namespace can be configured to do use the list as a translator chain: in this case, all rules are applied in order, the result of the first rule translation being passed to the second, and so on.
+There are two main possibilities for using these rules. By default, a namespace iterates through the rules, and when it finds one that translates the given name, it returns the translated name. But the namespace can be configured to use the list as a translator chain: in this case, all rules are applied in order, the result of the first rule translation being passed to the second, and so on.
 <h1>Attributes</h1>
 <table class="ivy-attributes">
 <thead>
Index: namespace/rule.html
===================================================================
--- namespace/rule.html	(revision 987761)
+++ namespace/rule.html	(working copy)
@@ -28,7 +28,7 @@
 
 <span class="tagdoc" id="ivysettings.namespaces.namespace.rule">Defines a new namespace rule. A rule defines a translation between system namespace and the defined namespace, and vice versa.</span>
 
-See [[settings/namespace]] doc for details.
+See the [[settings/namespace]] doc for details.
 
 <h1>Child elements</h1>
 <table class="ivy-children">
@@ -36,9 +36,9 @@
     <tr><th class="ivy-chld">Element</th><th class="ivy-chld-desc">Description</th><th class="ivy-chld-card">Cardinality</th></tr>
 </thead>
 <tbody>
-    <tr><td>[[settings/namespace/fromtosystem fromsystem]]</td><td>defines the translation to apply from system namespace to the defined namespace</td>
+    <tr><td>[[settings/namespace/fromtosystem fromsystem]]</td><td>defines the translation to apply from the system namespace to the defined namespace</td>
         <td>1</td></tr>
-    <tr><td>[[settings/namespace/fromtosystem tosystem]]</td><td>defines the translation to apply from the defined namespace to system namespace</td>
+    <tr><td>[[settings/namespace/fromtosystem tosystem]]</td><td>defines the translation to apply from the defined namespace to the system namespace</td>
         <td>1</td></tr>
 </tbody>
 </table>
Index: namespaces.html
===================================================================
--- namespaces.html	(revision 987761)
+++ namespaces.html	(working copy)
@@ -28,18 +28,18 @@
 
 <span class="tagdoc" id="ivysettings.namespaces">Namespaces are an advanced feature of Ivy which let you use resolvers in which module names and organisations are not consistent between each other.</span>
 
-For instance, if you want to use maven2 repository and ivyrep collectively, you will face some naming issues. For example all apache commons projects are declared to be part of the organisation apache in ivyrep whereas in maven2 ibiblio repository, they are declared to be part of the organisation of the same name of the module.
+For instance, if you want to use both a maven2 repository and an ivyrep, you will face some naming issues. For example, all apache commons projects are declared to be part of the organisation <i>apache</i> in ivyrep whereas in maven2 ibiblio repository, their organisation is same as the module.
 
 So if you try to use both maven2 and ivyrep repositories, you will face some issues like:
 <quote>
-How do I declare a dependency on commons-lang ?
-I have an error while trying to resolve module xxx. It says that it depends on [commons-httpclient commons-httpclient] ant that it isn't available.
+How do I declare a dependency on commons-lang?
+I have an error while trying to resolve module xxx. It says that it depends on [commons-httpclient commons-httpclient] and that it isn't available.
 ...
 </quote>
 
-Ivy has an answer to give to this kind of troubles, and this answer is called namespaces. In short, you can affect a namespace to each dependency resolver in Ivy, and each namespace defines rules to convert names from the system namespace to the defined namespace itself, and vice versa.
+Ivy's answer to this issue is called namespaces. In short, you can attach a namespace to each dependency resolver in Ivy, and each namespace defines rules to convert names from the system namespace to the defined namespace itself, and vice versa.
 
-This very powerful feature is thoroughly used in the <a href="../tutorial/build-repository/advanced.html">build your own repository tutorial</a>, and this is a good place to have examples of what can be done with namespaces.
+This very powerful feature is thoroughly used in the <a href="../tutorial/build-repository/advanced.html">build your own repository tutorial</a>, so is the best place to see an example of what can be done with namespaces.
 
 <h1>Child elements</h1>
 <table class="ivy-children">
Index: outputters.html
===================================================================
--- outputters.html	(revision 987761)
+++ outputters.html	(working copy)
@@ -41,7 +41,7 @@
         |      default     |   1   |   1   |   0   |   0   ||   1   |   1   |
         ---------------------------------------------------------------------
 </code>
-<li>an xml report outputter ([[svn:src/java/org/apache/ivy/plugins/report/XmlReportOutputter.java XmlReportOutputter]])</li>which produces an xml report in the cache, which is mandatory for correct Ivy behaviour, since it's that report which is used when you do a post resolve step in a separate buid from the resolve itself. It's also this xml report which is processed to generate all the different reports available in the [[ant:report]] task.
+<li>an xml report outputter ([[svn:src/java/org/apache/ivy/plugins/report/XmlReportOutputter.java XmlReportOutputter]])</li>which produces an xml report in the cache, which is mandatory for correct Ivy behaviour, since it's that report which is used when you do a post resolve step in a separate build from the resolve itself. It's also this xml report which is processed to generate all the different reports available in the [[ant:report]] task.
 </ul>
 
 The child tag used for the parser must be equal to a name of a report outputter type (added with the typedef tag).
Index: properties.html
===================================================================
--- properties.html	(revision 987761)
+++ properties.html	(working copy)
@@ -26,7 +26,7 @@
 	<textarea id="xooki-source">
 <b>Tag:</b> properties<br/>
 <br/>
-<span class="tagdoc" id="ivysettings.properties">Loads a properties file into ivy variables.</span> See variables chapter above for details about ivy variables.
+<span class="tagdoc" id="ivysettings.properties">Loads a properties file into ivy variables.</span> See the variables chapter above for details about ivy variables.
 
 <span class="since">Since 2.0</span>: it is possible to access environment variables. This can be done by specifying the environment attribute. This attribute specifies the prefix which can be used to access these environment variables. For instance, if you specify environment="env", you can access the PATH environment variable with the env.PATH property name.
 
@@ -39,7 +39,7 @@
     <tr><td>file</td><td>a path to a properties file to load</td>
         <td rowspan="2">One of these</td></tr>
     <tr><td>environment</td><td>the prefix to use when retrieving environment variables <span class="since">(since 2.0)</span></td></tr>
-    <tr><td>override</td><td>indicates if the variable found in the properties file should override their previous value, if any <span class="since">(since 1.3)</span></td>
+    <tr><td>override</td><td>indicates if the variable found in the properties file should override its previous value, if any <span class="since">(since 1.3)</span></td>
         <td>No, defaults to true</td></tr>
 </tbody>
 </table>
Index: property.html
===================================================================
--- property.html	(revision 987761)
+++ property.html	(working copy)
@@ -28,7 +28,7 @@
 
 <span class="tagdoc" id="ivysettings.property">Defines an ivy variable.</span> <span class="since">since 1.3</span>
 
-The optional override attribute enables to avoid overriding the previous value of the varable, which makes the definition behave like ant properties, which is particularly useful to define default values (values which are used only if they haven't been defined yet).
+The optional override attribute enables you to avoid overriding the previous value of the variable, which makes the definition behave like an ant property, which is particularly useful to define default values (values which are used only if they haven't been defined yet).
 <h1>Attributes</h1>
 <table class="ivy-attributes">
 <thead>
Index: resolvers.html
===================================================================
--- resolvers.html	(revision 987761)
+++ resolvers.html	(working copy)
@@ -34,7 +34,7 @@
 <code type="xml">
 <resolver ref="alreadydefinedresolver"/>
 </code>
-Note that this works only if the resolver has been already defined, and not if it is defined later in the ivysettings file.
+Note that this works only if the resolver has already been defined and NOT if it is defined later in the ivysettings file.
 <h1>Child elements</h1>
 <table class="ivy-children">
 <thead>
@@ -47,11 +47,11 @@
 </table>
 
 <h1>Built-in Resolvers</h1>
-Ivy comes with a set of built-in dependency resolvers able to answer to the most common needs. 
+Ivy comes with a set of built-in dependency resolvers that handle most common needs.
 
-If you don't find the one you want here, you can also check if some one has not contributed it in the [[links links page]], or even <a href="../extend.html">write your own</a>.
+If you don't find the one you want here, you can also check if someone has contributed it on the [[links links page]], or even <a href="../extend.html">write your own</a>.
 
-There are basically two types of resolver in Ivy: composite and standard resolvers. A composite resolver is a resolver which delegates the work to other resolvers. The other resolvers are standard resolvers.
+There are basically two types of resolvers in Ivy: composite and standard. A composite resolver is a resolver which delegates the work to other resolvers. The other resolvers are standard resolvers.
 
 Here is the list of built-in resolvers:
 
@@ -79,13 +79,13 @@
 <h3>validation</h3>
 All standard resolvers support several options for validation.
 
-The validate attribute is used to configure if Ivy files should be checked against the Ivy file xml schema.
+The <i>validate</i> attribute is used to configure if ivy files should be checked against the ivy file xml schema.
 
-The checkconsistency attribute allow to enable or disable consistency checking between what is expected by Ivy when it finds a module descriptor, and what the module descriptor actually contains.
+The checkconsistency attribute allows you to enable or disable consistency checking between what is expected by Ivy when it finds a module descriptor, and what the module descriptor actually contains.
 
-The descriptor attribute let one define if module descriptors are mandatory or optional.
+The descriptor attribute lets you define if module descriptors are mandatory or optional.
 
-The checksums attribute is used to define the list of checksums files to use to check the content of downloaded files has not been corrupted (eg during transfer).
+The checksums attribute is used to define the list of checksums files to use to check if the content of downloaded files has not been corrupted (eg during transfer).
 <h3>force</h3>
 Any standard resolver can be used in force mode, which is used mainly to handle local development builds. In force mode, the resolver attempts to find a dependency whatever the requested revision is (internally it replace the requested revision by 'latest.integration'), and if it finds one, it forces this revision to be returned, even when used in a chain with returnFirst=false.
 
@@ -98,7 +98,7 @@
     <tr><th class="ivy-att">Attribute</th><th class="ivy-att-desc">Description</th><th class="ivy-att-req">Required</th><th>Composite</th><th>Standard</th></tr>
 </thead>
 <tbody>
-    <tr><td>name</td><td>the name which identify the resolver</td>
+    <tr><td>name</td><td>the name which identifies the resolver</td>
         <td>Yes</td>
         <td>Yes</td>
         <td>Yes</td>
@@ -133,7 +133,7 @@
         <td>No</td>
         <td>Yes</td>
     </tr>
-    <tr><td>namespace</td><td>The name of the namespace to which this resolver belong <span class="since">since 1.3</span></td>
+    <tr><td>namespace</td><td>The name of the namespace to which this resolver belons <span class="since">since 1.3</span></td>
         <td>No, defaults to 'system'</td>
         <td>Yes</td>
         <td>Yes</td>
@@ -189,7 +189,7 @@
   </chain>
 </resolvers>
 </code>
-Defines a filesystem resolver, named '1', which is then used in two chains, the first which seconds the filesystem resolver with an ivyrep resolver, and second which seconds the filesystem resolver with an ibiblio resolver, and which returns the first module found, and uses the whole chain to download artifacts (see corresponding resolvers documentation for details about them).   Resolver 1 will use a cache named 'cache-1' which should have been defined under the caches element.
+Defines a filesystem resolver, named '1', which is then used in two chains, the first which combines the filesystem resolver with an ivyrep resolver, and second which combines the filesystem resolver with an ibiblio resolver, and which returns the first module found, and uses the whole chain to download artifacts (see corresponding resolvers documentation for details about them).   Resolver 1 will use a cache named 'cache-1' which should have been defined under the caches element.
 	</textarea>
 <script type="text/javascript">xooki.postProcess();</script>
 </body>
Index: settings.html
===================================================================
--- settings.html	(revision 987761)
+++ settings.html	(working copy)
@@ -28,9 +28,9 @@
 
 <span class="tagdoc" id="ivysettings.settings">Configures some important ivy info: default resolver, latest strategy, conflict manager...</span>
 
-Default resolver is used whenever nothing else is configured in the modules section of the settings file. It should give the name of a dependency resolver defined in the [[settings/resolvers]] section of the settings file.
+The default resolver is used whenever nothing else is configured in the modules section of the settings file. It should give the name of a dependency resolver defined in the [[settings/resolvers]] section of the settings file.
 
-Default latest strategy and conflict manager can also be configured here.
+The default latest strategy and conflict manager can also be configured here.
 
 <em>validate</em> indicates if ivy files should generally be validated against the xsd or not. This setting is only a default value, and can be overridden:
 1) in ant tasks
Index: triggers.html
===================================================================
--- triggers.html	(revision 987761)
+++ triggers.html	(working copy)
@@ -39,7 +39,7 @@
 
 If you want to use a different trigger, you can <a href="../extend.html">implement your own</a>.
 
-The event available in Ivy are the following ones:
+The following events are available in Ivy:
 <table class="ivy-children">
 <thead>
     <tr><th>Name</th><th>Attributes</th><th>Description</th></tr>
@@ -54,7 +54,7 @@
             <li>conf</li>comma separated list of configurations which will be resolved
           </ul>
         </td>
-        <td>Fired at the beginning of the resolve process, before a module dependencies and transitive dependencies are resolved.</td>
+        <td>Fired at the beginning of the resolve process, before module dependencies and transitive dependencies are resolved.</td>
     </tr>
     <tr><td>pre-resolve-dependency</td>
         <td>
@@ -186,7 +186,7 @@
             <li>to</li>the absolute path to which it will be retrieved
           </ul>
         </td>
-        <td>Fired before an artifact is retrieved from cache to a local location</td>
+        <td>Fired before an artifact is retrieved from the cache to a local location</td>
     </tr>
     <tr><td>post-retrieve-artifact <br/><span class="since">since 2.1</span></td>
         <td>
@@ -203,7 +203,7 @@
             <li>to</li>the absolute path to which it has just been retrieved
           </ul>
         </td>
-        <td>Fired after an artifact is retrieved from cache to a local location</td>
+        <td>Fired after an artifact is retrieved from the cache to a local location</td>
     </tr>
     <tr><td>pre-publish-artifact <br/><span class="since">since 2.0</span></td>
         <td>
@@ -236,9 +236,7 @@
             <li>status</li>"successful" if the artifact published successfully; "failed" if the artifact failed to publish, or if the status is unknown
           </ul>
         </td>
-        <td>Fired after an artifact is published into a repository.  Note that this event is fired
-        whether or not the publication succeeded.  The "status" property can be checked to 
-        verify success.</td>
+        <td>Fired after an artifact is published into a repository.  Note that this event is fired whether or not the publication succeeded.  The "status" property can be checked to verify success.</td>
     </tr>
 </tbody>
 </table>
Index: version-matchers.html
===================================================================
--- version-matchers.html	(revision 987761)
+++ version-matchers.html	(working copy)
@@ -30,7 +30,7 @@
 
 The child tag used for the version matcher must be equal to a name of a report outputter type (added with the typedef tag).
 
-A version matcher is used to evaluate if a a dependency version contraint matches a dependency version.
+A version matcher is used to evaluate if a dependency version constraint matches a dependency version.
 
 <h1>Child elements</h1>
 <table class="ivy-children">
@@ -62,7 +62,7 @@
 
 <h2>Latest (Status) Matcher</h2>
 
-A matcher that can matches versions based on their status. The predefined statuses in Ivy are 'release', 'milestone' and 'integration'. It's possible to define your own statuses, see [[settings/statuses]] for more detais.
+A matcher that matches versions based on their status. The predefined statuses in Ivy are 'release', 'milestone' and 'integration'. It's possible to define your own statuses, see [[settings/statuses]] for more details.
 
 <table class="ivy-children">
 <thead>