diff --git a/reference/mysqlnd_ms/concepts.xml b/reference/mysqlnd_ms/concepts.xml
index e907331fac..75c491144a 100644
--- a/reference/mysqlnd_ms/concepts.xml
+++ b/reference/mysqlnd_ms/concepts.xml
@@ -66,10 +66,10 @@
    (<link linkend="ref.mysqli">mysqli</link>,
   <link linkend="ref.mysql">mysql</link>, and
   <link linkend="ref.pdo-mysql">PDO_MYSQL</link>) are not changed in
-  a way that functions are added or removed. But their behaviour
+  a way that functions are added or removed. But their behavior
   changes when using the plugin. Existing applications do not need to
   be adapted to a new API, but they may need to be modified because of
-  the behaviour changes.
+  the behavior changes.
   </para>
   <para>
    The plugin breaks the one-by-one relationship between a
@@ -1099,7 +1099,7 @@ Transient error retries before error: 2
    not lagging more seconds behind the master than allowed.
   </para>
   <para>
-   Filters can accept parameters to change their behaviour.
+   Filters can accept parameters to change their behavior.
    The <literal>random</literal> filter accepts an optional
    <literal>sticky</literal> parameter. If set to true, the filter changes
    load balancing from random to random once. Random picks a random server
@@ -1110,7 +1110,7 @@ Transient error retries before error: 2
   <para>
    One of the biggest strength of the filter concept is the possibility to
    chain filters. This strength does not become immediately visible because
-   tje <literal>random</literal>, <literal>roundrobin</literal> and
+   the <literal>random</literal>, <literal>roundrobin</literal> and
    <literal>user</literal> filters  are supposed to output no more than one server.
    If a filter reduces the list of candidates for running a statement to
    only one server, it  makes little sense to use that one server as
@@ -1410,7 +1410,7 @@ Transient error retries before error: 2
    <link linkend="mysqlnd-ms.gtid">Global transaction IDs</link> to
    throttle clients. Throttling does reduce the write load on the master
    by slowing down clients. If session consistency is requested and
-   global transactions idenentifier are used to check the status of
+   global transactions identifier are used to check the status of
    a slave, the check can be done in two ways. By default a slave
    is checked and skipped immediately if it does not match
    the criteria for session consistency. Alternatively, the
@@ -1455,7 +1455,7 @@ Transient error retries before error: 2
   </para>
   <para>
    In case of a master failure a database administrator can easily identify the
-   most recent slave for promiting it as a new master. The most recent slave has
+   most recent slave for promoting it as a new master. The most recent slave has
    the highest transaction identifier.
   </para>
   <para>
@@ -1665,7 +1665,7 @@ Transient error retries before error: 2
   </para>
   <para>
    Applications have full control of cache usage and can request fresh data
-   at any time, if need be. Thec ache usage can be enabled and disabled
+   at any time, if need be. The cache usage can be enabled and disabled
    time during the execution of a script. The cache will be used
    if <function>mysqlnd_ms_set_qos</function> sets the quality of service
    to eventual consistency and enables cache usage. Cache usage is disabled by
@@ -1764,7 +1764,7 @@ Transient error retries before error: 2
   <para>
    The algorithm may seem expensive. <literal>SHOW SLAVE STATUS</literal> is a very
    fast operation. Given a sufficient number of requests and cache hits per second the cost of
-   checking the slaves lag can easily outweight the costs of the cache decision.
+   checking the slaves lag can easily outweigh the costs of the cache decision.
   </para>
   <para>
    Suggestions on a better algorithm are always welcome.
@@ -2215,7 +2215,7 @@ mysqlnd_ms_xa_commit($link, 1);
   <para>
    Should a client that has initiated a global transaction crash after all the
    participating servers gave their promise to be ready to commit, then the servers
-   must wait for a decision. The servers are not allowed to uniliterally decide on the
+   must wait for a decision. The servers are not allowed to unilaterally decide on the
    transaction.
   </para>
   <para>
@@ -2246,8 +2246,8 @@ mysqlnd_ms_xa_commit($link, 1);
     Errors during the second phase can be ignored, handled by yourself or solved
     by the build-int garbage collection logic. Ignoring them is not recommended
     as you may experience unfinished global transactions on your servers that block
-    resources virtually indefinetly. Handling the errors requires knowing the
-    participants, checking their state and issueing appropriate SQL commands on them.
+    resources virtually indefinitely. Handling the errors requires knowing the
+    participants, checking their state and issuing appropriate SQL commands on them.
     There are no user API calls to expose this very information. You will have to
     configure a state store and make the plugin record its actions in it to receive
     the desired facts.
@@ -2322,7 +2322,7 @@ mysqlnd_ms_xa_commit($link, 1);
     the situation, then the problem must be solved by an operator.
   </para>
   <para>
-    The function <link linkend="function.mysqlnd-ms-get-stats"><function>mysqlnd_ms_get_stats</function></link>
+    The function <function>mysqlnd_ms_get_stats</function>
     provides some statistics on how many XA transactions have been started,
     committed, failed or rolled back.
   </para>