diff --git a/doc/attribute_management.rst b/doc/attribute_management.rst
index ffef950..f20c5f9 100644
--- a/doc/attribute_management.rst
+++ b/doc/attribute_management.rst
@@ -111,7 +111,7 @@ ___________________________________________________
 
 To find the user in a LDAP directory, authentic2 must know its distinguished
 name (DN). If this LDAP has been used when the user has authenticated,
-Authentic 2 learn the user DN. Nothing has to be done from this point of view.
+Authentic 2 learns the user DN. Nothing has to be done from this point of view.
 
 However, if it is expected that user attributes be taken in a directory that
 is not used by the user for authentication, it is necessary to manually
diff --git a/doc/config_cas_sp.rst b/doc/config_cas_sp.rst
index 1e22f85..3712c9b 100644
--- a/doc/config_cas_sp.rst
+++ b/doc/config_cas_sp.rst
@@ -24,5 +24,5 @@ How to use Authentic 2 as a CAS 1.0 or CAS 2.0 identity provider ?
 
     http[s]://your.domain.com/idp/cas/
 
-5. If needed configure your service to resolve authenticated user with your
+5. If needed configure your service to resolve authenticated users with your
    LDAP directory (if user attributes are needed for your service)
diff --git a/doc/config_saml2_idp.rst b/doc/config_saml2_idp.rst
index 0d8a6d6..b04ab5f 100644
--- a/doc/config_saml2_idp.rst
+++ b/doc/config_saml2_idp.rst
@@ -123,10 +123,10 @@ the nameID is not recognized as an existing federation.
 Two values are possible: "Create new account" and "Account linking by authentication".
 
 The value "Create new account" makes Authentic 2 create a user account associated
-to the nameID received.
+with the nameID received.
 
 The value "Account linking by authentication" makes Authentic 2 ask the user to
-authenticate with an existing account to associate the nameID to this account.
+authenticate with an existing account to associate the nameID with this account.
 
 Behavior with transient nameID
 _______________________________
@@ -140,7 +140,7 @@ The value "Open a session" makes Authentic 2 open a session.
 
 The value "Ask authentication" makes Authentic 2 ask for a user authentication,
 even when a valid assertion is received. That may have sense for instance if
-the SSO login is used only to receive signed attributes for users with existing
+the SSO login is only used to receive signed attributes for users with existing
 accounts.
 
 
@@ -161,7 +161,7 @@ the menu 'Update metadata', then click on 'Go'.
    :width: 800 px
    :align: center
 
-How to create in bulk identity providers with the sync-metadata script?
+How to create in-bulk identity providers with the sync-metadata script?
 =======================================================================
 
 See the page explaining the use of the script sync-metadata :ref:`sync-metadata_script`.
diff --git a/doc/config_saml2_sp.rst b/doc/config_saml2_sp.rst
index ee8729d..72861a3 100644
--- a/doc/config_saml2_sp.rst
+++ b/doc/config_saml2_sp.rst
@@ -136,7 +136,7 @@ the menu 'Update metadata', then click on 'Go'.
    :width: 800 px
    :align: center
 
-How to create in bulk service providers with the sync-metadata script?
+How to create in-bulk service providers with the sync-metadata script?
 ======================================================================
 
 See the page explaining the use of the script sync-metadata :ref:`sync-metadata_script`.
diff --git a/doc/consent_management.rst b/doc/consent_management.rst
index b468ffd..2e714cf 100644
--- a/doc/consent_management.rst
+++ b/doc/consent_management.rst
@@ -8,11 +8,11 @@ What is the SAML2 federation consent aka account linking consent?
 =================================================================
 
 At the first single sign on process on the identity provider side, the user
-may be asked if she agrees to federation its local account with the remote
+may be asked if she agrees to federate her local account with the remote
 account on the service provider side.
 
 The account linking also called a federation means that the nameID is
-persistent and will link the two accounts. This signed identifier allows to
+persistent and will link the two accounts. This signed identifier allows
 the service provider to login the user without reauthentication during the
 following single sign on process.
 
@@ -34,7 +34,7 @@ if the user consent must be asked to the user.
    :width: 800 px
    :align: center
 
-*Take care that is the identity provider provides the service provider with
+*Take care that if the identity provider provides the service provider with
 a transient nameID, there is no account linking, so there is no need for a
 consent.*
 
diff --git a/doc/overview.rst b/doc/overview.rst
index e95e894..2553ec5 100644
--- a/doc/overview.rst
+++ b/doc/overview.rst
@@ -53,6 +53,6 @@ Support
 Authentic's developpers and users hangs on the mailing list authentic@listes.entrouvert.com.
 See archives or register at http://listes.entrouvert.com/info/authentic.
 
-You can open reports or feature request on http://authentic.entrouvert.org.
+You can open reports or feature requests on http://authentic.entrouvert.org.
 
-Entr'ouvert also provides a commercial support. For information, visit http://www.entrouvert.com.
+Entr'ouvert also provides commercial support. For information, visit http://www.entrouvert.com.
diff --git a/doc/quick_ldap_backend.rst b/doc/quick_ldap_backend.rst
index 1185608..b87bfe8 100644
--- a/doc/quick_ldap_backend.rst
+++ b/doc/quick_ldap_backend.rst
@@ -4,8 +4,8 @@
 Quickstart to connect a LDAP Directory
 ======================================
 
-Authentic use the module django_auth_ldap to synchronize the Django user tables
-with an LDAP. For complex use case, we will refer you to the django_auth_ldap
+Authentic uses the module django_auth_ldap to synchronize the Django user tables
+with an LDAP. For complex use cases, we will refer you to the django_auth_ldap
 documentation, see http://packages.python.org/django-auth-ldap/.
 
 How to authenticate users against an LDAP server with anonymous binding ?
diff --git a/doc/saml2_slo.rst b/doc/saml2_slo.rst
index d7bb107..0b45f01 100644
--- a/doc/saml2_slo.rst
+++ b/doc/saml2_slo.rst
@@ -8,9 +8,8 @@ Explanation
 ===========
 
 Authentic 2 implements the single logout profile of SAML2 (SLO). Single Logout is
-used to realise to close user session on distributed applications. The Single
-Logout is managed by the IdP. However, its exists many profiles all supported
-by Authentic 2:
+used to close user session on distributed applications. The Single Logout is
+managed by the IdP. However, Authentic 2 supports many profiles :
 
 - SLO IdP initiated by SOAP
 - SLO IdP initiated by Redirect
@@ -24,15 +23,15 @@ logout request can be received from:
 - a service provider;
 - a third identity provider.
 
-The configuration by policy allows to refuse SLO request coming from a SP or
-an IdP.
+The configuration by policy allows Authentic 2 to refuse SLO requests coming
+from a SP or an IdP.
 
 **The the SLO request is accepted or comes from the user interface, at the end
 of the process the local session on Authentic 2 will always be closed.**
 
 During the process of treatment of the logout request, when the logout request
 comes from a SP, if the local session was established through a third SAML2 IdP,
-Authentic 2 sends it a logout request (SLO proxying). Then, Authentic 2
+Authentic 2 sends it a logout request (SLO proxying) *au SP ? à l'IdP ?*. Then, Authentic 2
 sends logout resuests to all service providers with an active session but the
 requesting service provider.
 
@@ -40,8 +39,8 @@ During the process of treatment of the logout request, when the logout request
 comes from an IdP, Authentic 2 sends logout resuests to all service providers
 with an active session.
 
-The configuration by policy allows to select which IdP and SP to logout
-forwarding is done.
+The configuration by policy allows Authentic 2 to select IdPs and SPs to which
+logout forwarding is done.
 
 **Note:** When a logout request comes from an IdP, the logout request is always
 forwarded by soap to the service providers.
@@ -95,14 +94,15 @@ How activate the SLO?
 =====================
 
 No activation is required. However it is required a policy be found for the
-source or the desitnation of the logout request.
+source or the destination of the logout request.
 
 The sp options policy or idp options policy that applies has parameters to
-indicate if the sp or idp which the policy applies is allowed to send and
+indicate if the sp or idp to which the policy applies is allowed to send and
 receive logout requests.
 
-Then, create the 'default' options policy and check the both options
-*Accept to receive Single Logout requests* and *Forward Single Logout requests* as follows:
+Then, create the 'default' options policy and check both 
+*Accept to receive Single Logout requests* and *Forward Single Logout requests*
+options as follows:
 
 .. image:: pictures/slo_sp_options_activated.png
    :width: 800 px
@@ -122,8 +122,9 @@ Authentic 2 send logout requests when a logout request is received.
 If an options policy is not found for the source or the destination of the
 logout request, the logout requests are not accepted nor forwarded.
 
-However it is not the right way. The best is to create the 'all' options
-policies with the options *Accept to receive Single Logout requests* and *Forward Single Logout requests* unchecked as follows:
+However it is not the right way to proceed. The best way is to create the 'all'
+options policies with the options *Accept to receive Single Logout requests* and
+*Forward Single Logout requests* unchecked as follows:
 
 .. image:: pictures/slo_sp_options_deactivated.png
    :width: 800 px
@@ -133,9 +134,9 @@ policies with the options *Accept to receive Single Logout requests* and *Forwar
    :width: 800 px
    :align: center
 
-Take care that the 'all' policies are authoritative. To desactivate the SLO
-but for particular providers, the best is to unchecked these options on the
-'default' options policies and apply regular policies to those particular
+Ensure that the 'all' policies are authoritative. To deactivate the SLO
+but for particular providers, the best is to uncheck these options on the
+'default' options policies and to apply regular policies to those particular
 providers.
 
 How refuse SLO from an identity provider?
@@ -150,19 +151,19 @@ How refuse SLO from a service provider?
 Uncheck the option *Accept to receive Single Logout requests* of the policy that applies to that service
 provider.
 
-How indicate identity providers to not forward logout request?
+How indicate identity providers not to forward logout request?
 ==============================================================
 
 Uncheck the option *Forward Single Logout requests* of the policies that applies to the identity
-providers logout requests must not be forwarded.
+providers logout requests which must not be forwarded.
 
-How indicate service providers to not forward logout request?
+How indicate service providers not to forward logout request?
 =============================================================
 
 Uncheck the option *Forward Single Logout requests* of the policies that applies to the service
-providers logout requests must not be forwarded.
+providers logout requests which must not be forwarded.
 
-How do manage the SLO without closing the local session?
+How to manage the SLO without closing the local session?
 ========================================================
 
 Not implemented.
diff --git a/doc/sync-metadata_script.rst b/doc/sync-metadata_script.rst
index 4a11887..6e7f302 100644
--- a/doc/sync-metadata_script.rst
+++ b/doc/sync-metadata_script.rst
@@ -1,7 +1,7 @@
 .. _sync-metadata_script:
 
 ===========================================================================================================
-How to create/import and delete in bulk SAML2 identity and service providers with the sync-metadata script?
+How to create/import and delete in-bulk SAML2 identity and service providers with the sync-metadata script?
 ===========================================================================================================
 
 This section explains hot to use the script sync-metadata.
@@ -9,8 +9,8 @@ This section explains hot to use the script sync-metadata.
 Presentation
 ============
 
-This script allows to create/import and deleted in bulk SAML2 identity and
-service providers using standard SAML2 metadata files containing entity
+This script allows Authentic to create/import and delete in-bulk SAML2 identity
+and service providers using standard SAML2 metadata files containing entity
 descriptors.
 
 An example of such a file used in production is the global metadata file of
@@ -30,8 +30,8 @@ disabled.
 
 Currently it only supports the LDAP and the LDAP attribute profile of SAML,
 i.e. SAML attribute names must be LDAP attributes oid, the NameFormat must be
-URI, and an LDAP server must declared so that LDAP attributes can be resolved.
-Authentic2 contains a databases of the more common LDAP schemas to help the
+URI, and an LDAP server must be declared so that LDAP attributes can be resolved.
+Authentic2 contains a database of the more common LDAP schemas to help the
 resolution of attributes OIDs.
 
 Example of an AttributeConsumingService node::
@@ -101,11 +101,11 @@ Options
 
 * idp
 
-    Load only identity providers of the metadata file.
+    Load identity providers of the metadata file only.
 
 * sp
 
-    Load only service providers of the metadata file.
+    Load service providers of the metadata file only.
 
 * source
 
@@ -155,7 +155,7 @@ Options
 
     With no options, all providers are deleted.
 
-    With the source option, only providers with the source name given are deleted.
+    With the source option, only providers with the given source name are deleted.
 
     **This option can not be combined with options idp and sp.**
 
diff --git a/doc/translation.rst b/doc/translation.rst
index eae8657..3c33bc7 100644
--- a/doc/translation.rst
+++ b/doc/translation.rst
@@ -4,6 +4,6 @@
 Compiling translations
 ======================
 
-Translations must compiled to be useful, to do that run the following command::
+Translations must be compiled to be useful, to do that run the following command::
 
   ./setup.py compile_translations
diff --git a/doc/upgrading.rst b/doc/upgrading.rst
index 3015537..2ae848e 100644
--- a/doc/upgrading.rst
+++ b/doc/upgrading.rst
@@ -11,7 +11,7 @@ Update using pip::
 Authentic store all its data in a relational database as specified in its
 settings.py or local_settings.py file. So in order to upgrade to a new version
 of authentic you have to update your database schema using the
-migration command — you will need to have installed the dependency django-south,
+migration command — you will need to have the dependency django-south installed,
 see the beginning of this README file.::
 
     authentic2-ctl syncdb --migrate
