List:Commits« Previous MessageNext Message »
From:paul Date:January 8 2006 1:28am
Subject:svn commit - mysqldoc@docsrva: r716 - in trunk: . internals refman refman-4.1 refman-5.0 refman-5.1 refman-common
View as plain text  
Author: paul
Date: 2006-01-08 02:28:29 +0100 (Sun, 08 Jan 2006)
New Revision: 716

Log:
 r5948@frost:  paul | 2006-01-07 18:59:49 -0600
 Typos, U.S. English, conventions.


Modified:
   trunk/
   trunk/internals/internals.xml
   trunk/refman-4.1/database-administration.xml
   trunk/refman-4.1/functions.xml
   trunk/refman-4.1/innodb.xml
   trunk/refman-4.1/ndbcluster.xml
   trunk/refman-4.1/optimization.xml
   trunk/refman-4.1/renamed-nodes.txt
   trunk/refman-4.1/sql-syntax.xml
   trunk/refman-5.0/data-types.xml
   trunk/refman-5.0/database-administration.xml
   trunk/refman-5.0/functions.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.0/ndbcluster.xml
   trunk/refman-5.0/optimization.xml
   trunk/refman-5.0/problems.xml
   trunk/refman-5.0/renamed-nodes.txt
   trunk/refman-5.0/replication.xml
   trunk/refman-5.0/restrictions.xml
   trunk/refman-5.0/sql-syntax.xml
   trunk/refman-5.0/triggers.xml
   trunk/refman-5.1/database-administration.xml
   trunk/refman-5.1/functions.xml
   trunk/refman-5.1/innodb.xml
   trunk/refman-5.1/ndbcluster.xml
   trunk/refman-5.1/optimization.xml
   trunk/refman-5.1/problems.xml
   trunk/refman-5.1/renamed-nodes.txt
   trunk/refman-5.1/replication.xml
   trunk/refman-5.1/restrictions.xml
   trunk/refman-5.1/sql-syntax.xml
   trunk/refman-common/news-3.23.xml
   trunk/refman-common/news-4.0.xml
   trunk/refman-common/news-4.1.xml
   trunk/refman-common/news-5.0.xml
   trunk/refman-common/news-cluster.xml
   trunk/refman-common/news-connector-j.xml
   trunk/refman-common/news-connector-net.xml
   trunk/refman-common/titles.en.ent
   trunk/refman/connector-j.xml
   trunk/refman/functions.xml
   trunk/refman/innodb.xml
   trunk/refman/mysql-database-administration.xml
   trunk/refman/mysql-optimization.xml
   trunk/refman/ndbcluster.xml
   trunk/refman/problems.xml
   trunk/refman/replication.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5944
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:5948
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994

Modified: trunk/internals/internals.xml
===================================================================
--- trunk/internals/internals.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/internals/internals.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -7703,7 +7703,7 @@
       <para>
         <literal>mysql_select</literal> creates a
         <literal>JOIN</literal> for select if it does not already exist
-        (it might already exist because if it called for subselect
+        (it might already exist because if it called for subquery
         <literal>JOIN</literal> can be created in
         <literal>JOIN::optimize</literal> of outer query when it decided
         to calculate the value of the subquery). Then it calls
@@ -20836,7 +20836,7 @@
 
     <para>
       The reads and writes to the database files happen here, in
-      co-ordination with the low-level file i/o routines (see os0file.c
+      coordination with the low-level file i/o routines (see os0file.c
       in the \os program group).
     </para>
 

Modified: trunk/refman/connector-j.xml
===================================================================
--- trunk/refman/connector-j.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/connector-j.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -4779,7 +4779,7 @@
       reports incorrect values for servers deployed on Windows.
   
     - Fixed BUG#11190 - ResultSet.moveToCurrentRow() fails to work when 
-      preceeded by a call to ResultSet.moveToInsertRow().
+      preceded by a call to ResultSet.moveToInsertRow().
   
     - Fixed BUG#11115, VARBINARY data corrupted when using server-side
       prepared statements and .setBytes().

Modified: trunk/refman/functions.xml
===================================================================
--- trunk/refman/functions.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/functions.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -9183,7 +9183,7 @@
       MySQL, as is required by standard SQL. For this reason, dates
       prior to the cutover stored as MySQL <literal>DATE</literal> or
       <literal>DATETIME</literal> values must be adjusted to compensate
-      for the difference. It is important to realise that the cutover
+      for the difference. It is important to realize that the cutover
       did not occur at the same time in all countries, and that the
       later it happened, the more days were lost. For example, in Great
       Britain, it took place in 1752, when Wednesday September 2 was

Modified: trunk/refman/innodb.xml
===================================================================
--- trunk/refman/innodb.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/innodb.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -796,7 +796,7 @@
 
         <para>
           The increment size (in megabytes) for extending the size of an
-          autoextending tablespace when it becomes full. The default
+          auto-extending tablespace when it becomes full. The default
           value is 8. This option is available starting from MySQL
           4.0.24 and 4.1.5. As of MySQL 4.0.24 and 4.1.6, it can be
           changed at runtime as a global system variable.
@@ -1119,7 +1119,7 @@
           shared or exclusive locks on any index records it encounters.
           Thus the row-level locks are actually index record locks. The
           locks that <literal>InnoDB</literal> sets on index records
-          also affect the <quote>gap</quote> preceeding that index
+          also affect the <quote>gap</quote> preceding that index
           record. If a user has a shared or exclusive lock on record
           <emphasis>R</emphasis> in an index, another user cannot insert
           a new index record immediately before <emphasis>R</emphasis>
@@ -5912,7 +5912,7 @@
 
       <para>
         That causes MySQL to rebuild the table. Another way to perform a
-        defragmention operation is to use <command>mysqldump</command>
+        defragmentation operation is to use <command>mysqldump</command>
         to dump the table to a text file, drop the table, and reload it
         from the dump file.
       </para>

Modified: trunk/refman/mysql-database-administration.xml
===================================================================
--- trunk/refman/mysql-database-administration.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/mysql-database-administration.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -344,7 +344,7 @@
             This option enables support for the InnoDB storage engine.
             MySQL-Max servers always include InnoDB support, but this
             option actually is needed only for MySQL 3.23. From MySQL 4
-            onwards, InnoDB is included by default in binary
+            onward, InnoDB is included by default in binary
             distributions, so you do not need a MySQL-Max server merely
             to obtain InnoDB support.
           </para>
@@ -11098,7 +11098,7 @@
             </para>
 
             <para>
-              The number of non-cached queries (not cachable, or not
+              The number of non-cached queries (not cacheable, or not
               cached due to the <literal>query_cache_type</literal>
               setting).
             </para>
@@ -22411,9 +22411,9 @@
 
   </section>
 
-  <section id="localisation">
+  <section id="localization">
 
-    <title>&title-localisation;</title>
+    <title>&title-localization;</title>
 
     <para>
       This section describes how to configure the server to use

Modified: trunk/refman/mysql-optimization.xml
===================================================================
--- trunk/refman/mysql-optimization.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/mysql-optimization.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -6560,7 +6560,7 @@
 
       <indexterm>
         <primary>storage space</primary>
-        <secondary>minimising</secondary>
+        <secondary>minimizing</secondary>
       </indexterm>
 
       <indexterm>

Modified: trunk/refman/ndbcluster.xml
===================================================================
--- trunk/refman/ndbcluster.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/ndbcluster.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -521,7 +521,7 @@
 
       <para>
         One of the strengths of MySQL Cluster is that it can be run on
-        commodity hardware and has no ususual requirements in this
+        commodity hardware and has no unusual requirements in this
         regard, other than for large amounts of RAM, due to the fact
         that all live data storage is done in memory. (Note that this is
         subject to change, and that we intend to implement disk-based
@@ -583,7 +583,7 @@
             MySQL Cluster on a private or protected network allows for
             the cluster to make exclusive use of bandwidth between
             cluster hosts. Using a separate switch for your MySQL
-            Cluster not only helps protect against unauthorised access
+            Cluster not only helps protect against unauthorized access
             to Cluster data, it also ensures that Cluster nodes are
             shielded from interference caused by transmissions between
             other computers on the network. For enhanced reliability,
@@ -1263,7 +1263,7 @@
             (beginning with MySQL 5.0.2, you may use <command>CREATE
             SCHEMA world;</command> instead) followed by <command>FLUSH
             TABLES;</command> on each SQL node in the cluster. This will
-            cause the node to recognise the database and read its table
+            cause the node to recognize the database and read its table
             definitions.
           </para>
 
@@ -1537,7 +1537,7 @@
       respect from a normal (non-clustered) MySQL server, in that it
       employs the <literal>NDB Cluster</literal> storage engine. This
       engine is also referred to simply as <literal>NDB</literal>, and
-      the two forms of the name are synonomous.
+      the two forms of the name are synonymous.
     </para>
 
     <para>
@@ -1618,7 +1618,7 @@
       <title>&title-mysql-cluster-quick;</title>
 
       <para>
-        In order to familiarise you with the basics, we will describe
+        In order to familiarize you with the basics, we will describe
         the simplest possible configuration for a functional MySQL
         Cluster. After this, you should be able to design your desired
         setup from the information provided in the other relevant
@@ -3020,7 +3020,7 @@
             <para>
               For each active transaction in the cluster there must be a
               record in one of the cluster nodes. The task of
-              coordinating transactions is spread amongst the nodes: the
+              coordinating transactions is spread among the nodes: the
               total number of transaction records in the cluster is the
               number of transactions in any given node times the number
               of nodes in the cluster.
@@ -3078,7 +3078,7 @@
 
             <para>
               Records are kept for each transaction updating cluster
-              data, both in the transaction co-ordinator and in the
+              data, both in the transaction coordinator and in the
               nodes where the actual updates are performed. These
               records contain state information needed in order to find
               UNDO records for rollback, lock queues, and other
@@ -3117,14 +3117,14 @@
               This parameter actually handles two values that can be
               configured separately. The first of these specifies how
               many operation records are to be placed with the
-              transaction co-ordinator. The second part specifies how
+              transaction coordinator. The second part specifies how
               many operation records are to be local to the database.
             </para>
 
             <para>
               A very large transaction performed on a 8-node cluster
               requires as many operation records in the transaction
-              co-ordinator as there are reads, updates, and deletes
+              coordinator as there are reads, updates, and deletes
               involved in the transaction. However, the operation
               records of the are spread over all 8 nodes. Thus, if it is
               necessary to configure the system for one very large
@@ -3132,7 +3132,7 @@
               parts separately.
               <literal>MaxNoOfConcurrentOperations</literal> will always
               be used to calculate the number of operation records in
-              the transaction co-ordinator portion of the node.
+              the transaction coordinator portion of the node.
             </para>
 
             <para>
@@ -3262,7 +3262,7 @@
               info, <literal>ZDATABUF_FILESIZE</literal> (also in
               <filename>Dbtc.hpp</filename>) contains 4000 * 16 = 62.5KB
               of buffer space. <literal>Dbtc</literal> is the module
-              which handles transaction co-ordination.
+              which handles transaction coordination.
             </para>
           </listitem>
 
@@ -3301,7 +3301,7 @@
             <para>
               This parameter is used to control the number of parallel
               scans that can be performed in the cluster. Each
-              transaction co-ordinator can handle the number of parallel
+              transaction coordinator can handle the number of parallel
               scans defined for this parameter. Each scan query is
               performed by scanning all partitions in parallel. Each
               partition scan uses a scan record in the node where the
@@ -3332,7 +3332,7 @@
 
             <para>
               This parameter specifies the number of scans possible in
-              the transaction co-ordinator. If the number of local scan
+              the transaction coordinator. If the number of local scan
               records is not provided, it is calculated as the product
               of <literal>MaxNoOfConcurrentScans</literal> and the
               number of data nodes in the system.
@@ -4497,7 +4497,7 @@
             </para>
 
             <para>
-              The backup log buffer fulfils a role similar to that
+              The backup log buffer fulfills a role similar to that
               played by the backup data buffer, except that it used for
               generating a log of all table writes made during execution
               of the backup. The same principles apply for writing these
@@ -5692,7 +5692,7 @@
             <command>ndb_mgmd</command> does not accept the -c option
             before MySQL 5.0, as this switch specifies the configuration
             file in previous versions). Available with
-            <command>ndb_mgm</command> from MySQL 4.1.8 onwards.
+            <command>ndb_mgm</command> from MySQL 4.1.8 onward.
           </para>
 
 <programlisting>
@@ -6369,7 +6369,7 @@
         Once this process is completed for an initial start or system
         restart, handling of transactions is enabled. For a node restart
         or initial node restart, completion of the startup process means
-        that the node may now act as a transaction co-ordinator.
+        that the node may now act as a transaction coordinator.
       </para>
 
     </section>
@@ -7009,10 +7009,10 @@
                   establish communication, or other problem</entry>
               </row>
               <row>
-                <entry>DB node neighbours</entry>
+                <entry>DB node neighbors</entry>
                 <entry>8</entry>
                 <entry>INFO</entry>
-                <entry>Shows neighbouring data nodes</entry>
+                <entry>Shows neighboring data nodes</entry>
               </row>
               <row>
                 <entry>DB node start phase <replaceable>X</replaceable> completed</entry>
@@ -7800,7 +7800,7 @@
         <para>
           <emphasis role="bold">Note</emphasis>: If there is no backup
           with ID <replaceable>backup_id</replaceable> running when it
-          is aborted, the management server will not make any exlicit
+          is aborted, the management server will not make any explicit
           response. However, there will be a line in the cluster log
           indicating that an invalid abort command was sent.
         </para>
@@ -9642,7 +9642,7 @@
 
         <para>
           Cluster is supported in the MySQL-max binaries from version
-          4.1.3 onwards. You can determine whether or not your server
+          4.1.3 onward. You can determine whether or not your server
           binary has <literal>NDB</literal> support using either of the
           commands <literal>SHOW VARIABLES LIKE 'have_%';</literal> or
           <literal>SHOW ENGINES;</literal>. (See
@@ -9800,7 +9800,7 @@
           All committed transactions are logged. Therefore, while it is
           possible that some data could be lost in the event of a
           catastrophe, this should be quite limited. Data loss can be
-          further reduced by minimising the number of operations per
+          further reduced by minimizing the number of operations per
           transaction.
         </para>
       </listitem>
@@ -10059,7 +10059,7 @@
           when no single node group has all its nodes alive, in which
           case network partitioning (the <quote>split-brain</quote>
           scenario) becomes possible. Then an arbitrator is required.
-          All cluster nodes recognise the same node as the arbitrator,
+          All cluster nodes recognize the same node as the arbitrator,
           which is normally the management server; however, it is
           possible to configure any of the MySQL Servers in the cluster
           to act as the arbirtrator instead. The arbitrator accepts the
@@ -10288,7 +10288,7 @@
           <emphasis role="bold"><literal>NDB
           Cluster</literal></emphasis> is the storage engine used by
           MySQL to implement data storage, retrieval, and management
-          distributed amongst several computers.
+          distributed among several computers.
           <emphasis role="bold">MySQL Cluster</emphasis> refers to a
           group of computers working together using the NDB engine to
           support a distributed MySQL database in a

Modified: trunk/refman/problems.xml
===================================================================
--- trunk/refman/problems.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/problems.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -3574,7 +3574,7 @@
 
       <para>
         If you want MySQL to check all dates and accept only legal dates
-        (unless overriden by IGNORE), you should set
+        (unless overridden by IGNORE), you should set
         <literal>sql_mode</literal> to
         <literal>"NO_ZERO_IN_DATE,NO_ZERO_DATE"</literal>.
       </para>

Modified: trunk/refman/replication.xml
===================================================================
--- trunk/refman/replication.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman/replication.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -4955,7 +4955,7 @@
       new server variables were introduced with MySQL 5.0.2:
       <literal>auto_increment_increment</literal> and
       <literal>auto_increment_offset</literal>. These variables have a
-      default (and mimimum) value of 1 and a maximum value of 65,535.
+      default (and minimum) value of 1 and a maximum value of 65,535.
     </para>
 
     <para>

Modified: trunk/refman-4.1/database-administration.xml
===================================================================
--- trunk/refman-4.1/database-administration.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-4.1/database-administration.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -351,7 +351,7 @@
             <literal>InnoDB</literal> storage engine. MySQL-Max servers
             always include <literal>InnoDB</literal> support, but this
             option actually is needed only for MySQL 3.23. From MySQL
-            4.0 onwards, <literal>InnoDB</literal> is included by
+            4.0 onward, <literal>InnoDB</literal> is included by
             default in all binary distributions, so you do not need a
             MySQL-Max server merely to obtain <literal>InnoDB</literal>
             support.
@@ -8851,7 +8851,7 @@
             </para>
 
             <para>
-              The number of non-cached queries (not cachable, or not
+              The number of non-cached queries (not cacheable, or not
               cached due to the <literal>query_cache_type</literal>
               setting).
             </para>
@@ -19839,9 +19839,9 @@
 
   </section>
 
-  <section id="localisation">
+  <section id="localization">
 
-    <title>&title-localisation;</title>
+    <title>&title-localization;</title>
 
     <para>
       This section describes how to configure the server to use

Modified: trunk/refman-4.1/functions.xml
===================================================================
--- trunk/refman-4.1/functions.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-4.1/functions.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -9011,7 +9011,7 @@
       required by standard SQL. For this reason, dates prior to the
       cutover stored as MySQL <literal>DATE</literal> or
       <literal>DATETIME</literal> values must be adjusted to compensate
-      for the difference. It is important to realise that the cutover
+      for the difference. It is important to realize that the cutover
       did not occur at the same time in all countries, and that the
       later it happened, the more days were lost. For example, in Great
       Britain, it took place in 1752, when Wednesday September 2 was

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-4.1/innodb.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -798,7 +798,7 @@
 
         <para>
           The increment size (in megabytes) for extending the size of an
-          autoextending tablespace when it becomes full. The default
+          auto-extending tablespace when it becomes full. The default
           value is 8. This option is available starting from MySQL
           4.0.24 and 4.1.5. As of MySQL 4.0.24 and 4.1.6, it can be
           changed at runtime as a global system variable.
@@ -1087,7 +1087,7 @@
           shared or exclusive locks on any index records it encounters.
           Thus, the row-level locks are actually index record locks. The
           locks that <literal>InnoDB</literal> sets on index records
-          also affect the <quote>gap</quote> preceeding that index
+          also affect the <quote>gap</quote> preceding that index
           record. If a user has a shared or exclusive lock on record
           <emphasis>R</emphasis> in an index, another user cannot insert
           a new index record immediately before <emphasis>R</emphasis>
@@ -4739,7 +4739,7 @@
           release Solaris &ge; 2.6 and any platform
           (sparc/x86/x64/amd64), a significant performance gain can be
           achieved by placing <literal>InnoDB</literal> data files and
-          log files on raw devices or on a seperate direct I/O UFS
+          log files on raw devices or on a separate direct I/O UFS
           Filesystem (mount option <literal>forcedirectio</literal>; see
           <literal>mount_ufs(1M)</literal>). Users of the Veritas
           filesystem VxFS should use the mount option
@@ -5872,7 +5872,7 @@
 
       <para>
         That causes MySQL to rebuild the table. Another way to perform a
-        defragmention operation is to use <command>mysqldump</command>
+        defragmentation operation is to use <command>mysqldump</command>
         to dump the table to a text file, drop the table, and reload it
         from the dump file.
       </para>

Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-4.1/ndbcluster.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -521,7 +521,7 @@
 
       <para>
         One of the strengths of MySQL Cluster is that it can be run on
-        commodity hardware and has no ususual requirements in this
+        commodity hardware and has no unusual requirements in this
         regard, other than for large amounts of RAM, due to the fact
         that all live data storage is done in memory. (Note that this is
         subject to change, and that we intend to implement disk-based
@@ -584,7 +584,7 @@
             MySQL Cluster on a private or protected network allows for
             the cluster to make exclusive use of bandwidth between
             cluster hosts. Using a separate switch for your MySQL
-            Cluster not only helps protect against unauthorised access
+            Cluster not only helps protect against unauthorized access
             to Cluster data, it also ensures that Cluster nodes are
             shielded from interference caused by transmissions between
             other computers on the network. For enhanced reliability,
@@ -1268,7 +1268,7 @@
             its tables have been created on one data node, you need to
             issue the command <command>CREATE DATABASE world;</command>
             followed by <command>FLUSH TABLES;</command> on each SQL
-            node in the cluster. This will cause the node to recognise
+            node in the cluster. This will cause the node to recognize
             the database and read its table definitions.
           </para>
 
@@ -1552,7 +1552,7 @@
       respect from a normal (non-clustered) MySQL server, in that it
       employs the <literal>NDB Cluster</literal> storage engine. This
       engine is also referred to simply as <literal>NDB</literal>, and
-      the two forms of the name are synonomous.
+      the two forms of the name are synonymous.
     </para>
 
     <para>
@@ -1632,7 +1632,7 @@
       <title>&title-mysql-cluster-quick;</title>
 
       <para>
-        In order to familiarise you with the basics, we will describe
+        In order to familiarize you with the basics, we will describe
         the simplest possible configuration for a functional MySQL
         Cluster. After this, you should be able to design your desired
         setup from the information provided in the other relevant
@@ -3043,7 +3043,7 @@
             <para>
               For each active transaction in the cluster there must be a
               record in one of the cluster nodes. The task of
-              coordinating transactions is spread amongst the nodes: the
+              coordinating transactions is spread among the nodes: the
               total number of transaction records in the cluster is the
               number of transactions in any given node times the number
               of nodes in the cluster.
@@ -3101,7 +3101,7 @@
 
             <para>
               Records are kept for each transaction updating cluster
-              data, both in the transaction co-ordinator and in the
+              data, both in the transaction coordinator and in the
               nodes where the actual updates are performed. These
               records contain state information needed in order to find
               UNDO records for rollback, lock queues, and other
@@ -3140,14 +3140,14 @@
               This parameter actually handles two values that can be
               configured separately. The first of these specifies how
               many operation records are to be placed with the
-              transaction co-ordinator. The second part specifies how
+              transaction coordinator. The second part specifies how
               many operation records are to be local to the database.
             </para>
 
             <para>
               A very large transaction performed on an 8-node cluster
               requires as many operation records in the transaction
-              co-ordinator as there are reads, updates, and deletes
+              coordinator as there are reads, updates, and deletes
               involved in the transaction. However, the operation
               records of the are spread over all 8 nodes. Thus, if it is
               necessary to configure the system for one very large
@@ -3155,7 +3155,7 @@
               parts separately.
               <literal>MaxNoOfConcurrentOperations</literal> will always
               be used to calculate the number of operation records in
-              the transaction co-ordinator portion of the node.
+              the transaction coordinator portion of the node.
             </para>
 
             <para>
@@ -3284,7 +3284,7 @@
               info, <literal>ZDATABUF_FILESIZE</literal> (also in
               <filename>Dbtc.hpp</filename>) contains 4000 * 16 = 62.5KB
               of buffer space. <literal>Dbtc</literal> is the module
-              which handles transaction co-ordination.
+              which handles transaction coordination.
             </para>
           </listitem>
 
@@ -3323,7 +3323,7 @@
             <para>
               This parameter is used to control the number of parallel
               scans that can be performed in the cluster. Each
-              transaction co-ordinator can handle the number of parallel
+              transaction coordinator can handle the number of parallel
               scans defined for this parameter. Each scan query is
               performed by scanning all partitions in parallel. Each
               partition scan uses a scan record in the node where the
@@ -3354,7 +3354,7 @@
 
             <para>
               This parameter specifies the number of scans possible in
-              the transaction co-ordinator. If the number of local scan
+              the transaction coordinator. If the number of local scan
               records is not provided, it is calculated as the product
               of <literal>MaxNoOfConcurrentScans</literal> and the
               number of data nodes in the system.
@@ -4560,7 +4560,7 @@
             </para>
 
             <para>
-              The backup log buffer fulfils a role similar to that
+              The backup log buffer fulfills a role similar to that
               played by the backup data buffer, except that it used for
               generating a log of all table writes made during execution
               of the backup. The same principles apply for writing these
@@ -5771,7 +5771,7 @@
             <command>ndb_mgmd</command> does not accept the -c option
             before MySQL 5.0, as this switch specifies the configuration
             file in previous versions). Available with
-            <command>ndb_mgm</command> from MySQL 4.1.8 onwards.
+            <command>ndb_mgm</command> from MySQL 4.1.8 onward.
           </para>
 
 <programlisting>
@@ -6450,7 +6450,7 @@
         Once this process is completed for an initial start or system
         restart, handling of transactions is enabled. For a node restart
         or initial node restart, completion of the startup process means
-        that the node may now act as a transaction co-ordinator.
+        that the node may now act as a transaction coordinator.
       </para>
 
     </section>
@@ -7095,10 +7095,10 @@
                   establish communication, or other problem</entry>
               </row>
               <row>
-                <entry>DB node neighbours</entry>
+                <entry>DB node neighbors</entry>
                 <entry>8</entry>
                 <entry>INFO</entry>
-                <entry>Shows neighbouring data nodes</entry>
+                <entry>Shows neighboring data nodes</entry>
               </row>
               <row>
                 <entry>DB node start phase <replaceable>X</replaceable> completed</entry>
@@ -7893,7 +7893,7 @@
         <para>
           <emphasis role="bold">Note</emphasis>: If there is no backup
           with ID <replaceable>backup_id</replaceable> running when it
-          is aborted, the management server does not make any exlicit
+          is aborted, the management server does not make any explicit
           response. However, the fact that an invalid abort command was
           sent is indicated in the cluster log.
         </para>
@@ -9592,7 +9592,7 @@
 
         <para>
           Cluster is supported in the MySQL-max binaries from version
-          4.1.3 onwards. You can determine whether or not your server
+          4.1.3 onward. You can determine whether or not your server
           binary has <literal>NDB</literal> support using either of the
           commands <literal>SHOW VARIABLES LIKE 'have_%';</literal> or
           <literal>SHOW ENGINES;</literal>. (See
@@ -9749,7 +9749,7 @@
           All committed transactions are logged. Therefore, while it is
           possible that some data could be lost in the event of a
           catastrophe, this should be quite limited. Data loss can be
-          further reduced by minimising the number of operations per
+          further reduced by minimizing the number of operations per
           transaction. (It is not a good idea to perform large numbers
           of operations per transaction in any case.)
         </para>
@@ -10011,7 +10011,7 @@
           when no single node group has all its nodes alive, in which
           case network partitioning (the <quote>split-brain</quote>
           scenario) becomes possible. Then an arbitrator is required.
-          All cluster nodes recognise the same node as the arbitrator,
+          All cluster nodes recognize the same node as the arbitrator,
           which is normally the management server; however, it is
           possible to configure any of the MySQL Servers in the cluster
           to act as the arbitrator instead. The arbitrator accepts the
@@ -10254,7 +10254,7 @@
 
         <para>
           This is the storage engine used in MySQL to implement data
-          storage, retrieval, and management distributed amongst several
+          storage, retrieval, and management distributed among several
           computers.
         </para>
 

Modified: trunk/refman-4.1/optimization.xml
===================================================================
--- trunk/refman-4.1/optimization.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-4.1/optimization.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -5141,7 +5141,7 @@
 
       <indexterm>
         <primary>storage space</primary>
-        <secondary>minimising</secondary>
+        <secondary>minimizing</secondary>
       </indexterm>
 
       <indexterm>

Modified: trunk/refman-4.1/renamed-nodes.txt
===================================================================
--- trunk/refman-4.1/renamed-nodes.txt	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-4.1/renamed-nodes.txt	2006-01-08 01:28:29 UTC (rev 716)
@@ -92,3 +92,4 @@
 mailing-list mailing-lists
 answering-questions mailing-list-use
 reproduceable-test-case reproducible-test-case
+localisation localization

Modified: trunk/refman-4.1/sql-syntax.xml
===================================================================
--- trunk/refman-4.1/sql-syntax.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-4.1/sql-syntax.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -2668,7 +2668,7 @@
 
           <listitem>
             <para>
-              From MySQL 4.1.0 onwards, a <literal>CHAR</literal> or
+              From MySQL 4.1.0 onward, a <literal>CHAR</literal> or
               <literal>VARCHAR</literal> column with a length
               specification greater than 255 is converted to the
               smallest <literal>TEXT</literal> type that can hold values
@@ -8754,7 +8754,7 @@
       <para>
         For other storage engines, <literal>TRUNCATE TABLE</literal>
         differs from <literal>DELETE FROM</literal> in the following
-        ways from MySQL 4.0 onwards:
+        ways from MySQL 4.0 onward:
       </para>
 
       <itemizedlist>
@@ -10153,7 +10153,7 @@
         </para>
 
         <para>
-          From 4.1.1 onwards in the MySQL 4.1 release series,
+          From 4.1.1 onward in the MySQL 4.1 release series,
           <literal>DROP USER</literal> serves only to remove each
           account record from the <literal>user</literal> table. To
           remove a MySQL account completely, you should use the
@@ -17919,7 +17919,7 @@
           <literal>START SLAVE</literal> does not warn you about this.
           You must check the slave's error log for error messages
           generated by the slave threads, or check that they are running
-          satisfactorilly with <literal>SHOW SLAVE STATUS</literal>.
+          satisfactorily with <literal>SHOW SLAVE STATUS</literal>.
         </para>
 
         <remark role="help-description-end"/>

Modified: trunk/refman-5.0/data-types.xml
===================================================================
--- trunk/refman-5.0/data-types.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/data-types.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -5043,7 +5043,7 @@
 
       <listitem>
         <para>
-          If the size of the column is geater than 256 characters, then
+          If the size of the column is greater than 256 characters, then
           the column requires 2 bytes extra storage per row.
         </para>
       </listitem>

Modified: trunk/refman-5.0/database-administration.xml
===================================================================
--- trunk/refman-5.0/database-administration.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/database-administration.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -352,7 +352,7 @@
           <para>
             This option enables support for the InnoDB storage engine.
             MySQL-Max servers always include InnoDB support. From MySQL
-            4.0 onwards, InnoDB is included by default in all binary
+            4.0 onward, InnoDB is included by default in all binary
             distributions, so you do not need a MySQL-Max server merely
             to obtain InnoDB support.
           </para>
@@ -10833,7 +10833,7 @@
             </para>
 
             <para>
-              The number of non-cached queries (not cachable, or not
+              The number of non-cached queries (not cacheable, or not
               cached due to the <literal>query_cache_type</literal>
               setting).
             </para>
@@ -21975,9 +21975,9 @@
 
   </section>
 
-  <section id="localisation">
+  <section id="localization">
 
-    <title>&title-localisation;</title>
+    <title>&title-localization;</title>
 
     <para>
       This section describes how to configure the server to use
@@ -24427,7 +24427,7 @@
         Note that if you specify <literal>localhost</literal> as a
         hostname, <command>mysqladmin</command> defaults to using a Unix
         socket file connection rather than TCP/IP. From MySQL 4.1
-        onwards, you can explicitly specify the connection protocol to
+        onward, you can explicitly specify the connection protocol to
         use by using the <option>--protocol={TCP | SOCKET | PIPE |
         MEMORY}</option> option.
       </para>

Modified: trunk/refman-5.0/functions.xml
===================================================================
--- trunk/refman-5.0/functions.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/functions.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -9077,7 +9077,7 @@
       required by standard SQL. For this reason, dates prior to the
       cutover stored as MySQL <literal>DATE</literal> or
       <literal>DATETIME</literal> values must be adjusted to compensate
-      for the difference. It is important to realise that the cutover
+      for the difference. It is important to realize that the cutover
       did not occur at the same time in all countries, and that the
       later it happened, the more days were lost. For example, in Great
       Britain, it took place in 1752, when Wednesday September 2 was

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/innodb.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -710,7 +710,7 @@
 
         <para>
           The increment size (in megabytes) for extending the size of an
-          autoextending tablespace when it becomes full. The default
+          auto-extending tablespace when it becomes full. The default
           value is 8. This option can be changed at runtime as a global
           system variable.
         </para>
@@ -1064,7 +1064,7 @@
           shared or exclusive locks on any index records it encounters.
           Thus, the row-level locks are actually index record locks. The
           locks that <literal>InnoDB</literal> sets on index records
-          also affect the <quote>gap</quote> preceeding that index
+          also affect the <quote>gap</quote> preceding that index
           record. If a user has a shared or exclusive lock on record
           <emphasis>R</emphasis> in an index, another user cannot insert
           a new index record immediately before <emphasis>R</emphasis>
@@ -4699,7 +4699,7 @@
           release Solaris &ge; 2.6 and any platform
           (sparc/x86/x64/amd64), a significant performance gain can be
           achieved by placing <literal>InnoDB</literal> data files and
-          log files on raw devices or on a seperate direct I/O UFS
+          log files on raw devices or on a separate direct I/O UFS
           Filesystem (mount option <literal>forcedirectio</literal>; see
           <literal>mount_ufs(1M)</literal>). Users of the Veritas
           filesystem VxFS should use the mount option
@@ -5822,7 +5822,7 @@
 
       <para>
         That causes MySQL to rebuild the table. Another way to perform a
-        defragmention operation is to use <command>mysqldump</command>
+        defragmentation operation is to use <command>mysqldump</command>
         to dump the table to a text file, drop the table, and reload it
         from the dump file.
       </para>

Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/ndbcluster.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -527,7 +527,7 @@
 
       <para>
         One of the strengths of MySQL Cluster is that it can be run on
-        commodity hardware and has no ususual requirements in this
+        commodity hardware and has no unusual requirements in this
         regard, other than for large amounts of RAM, due to the fact
         that all live data storage is done in memory. (Note that this is
         subject to change, and that we intend to implement disk-based
@@ -590,7 +590,7 @@
             MySQL Cluster on a private or protected network allows for
             the cluster to make exclusive use of bandwidth between
             cluster hosts. Using a separate switch for your MySQL
-            Cluster not only helps protect against unauthorised access
+            Cluster not only helps protect against unauthorized access
             to Cluster data, it also ensures that Cluster nodes are
             shielded from interference caused by transmissions between
             other computers on the network. For enhanced reliability,
@@ -1277,7 +1277,7 @@
             (beginning with MySQL 5.0.2, you may use <command>CREATE
             SCHEMA world;</command> instead), followed by <command>FLUSH
             TABLES;</command> on each SQL node in the cluster. This will
-            cause the node to recognise the database and read its table
+            cause the node to recognize the database and read its table
             definitions.
           </para>
 
@@ -1561,7 +1561,7 @@
       respect from a normal (non-clustered) MySQL server, in that it
       employs the <literal>NDB Cluster</literal> storage engine. This
       engine is also referred to simply as <literal>NDB</literal>, and
-      the two forms of the name are synonomous.
+      the two forms of the name are synonymous.
     </para>
 
     <para>
@@ -1641,7 +1641,7 @@
       <title>&title-mysql-cluster-quick;</title>
 
       <para>
-        In order to familiarise you with the basics, we will describe
+        In order to familiarize you with the basics, we will describe
         the simplest possible configuration for a functional MySQL
         Cluster. After this, you should be able to design your desired
         setup from the information provided in the other relevant
@@ -3049,7 +3049,7 @@
             <para>
               For each active transaction in the cluster there must be a
               record in one of the cluster nodes. The task of
-              coordinating transactions is spread amongst the nodes: the
+              coordinating transactions is spread among the nodes: the
               total number of transaction records in the cluster is the
               number of transactions in any given node times the number
               of nodes in the cluster.
@@ -3107,7 +3107,7 @@
 
             <para>
               Records are kept for each transaction updating cluster
-              data, both in the transaction co-ordinator and in the
+              data, both in the transaction coordinator and in the
               nodes where the actual updates are performed. These
               records contain state information needed in order to find
               UNDO records for rollback, lock queues, and other
@@ -3146,14 +3146,14 @@
               This parameter actually handles two values that can be
               configured separately. The first of these specifies how
               many operation records are to be placed with the
-              transaction co-ordinator. The second part specifies how
+              transaction coordinator. The second part specifies how
               many operation records are to be local to the database.
             </para>
 
             <para>
               A very large transaction performed on an 8-node cluster
               requires as many operation records in the transaction
-              co-ordinator as there are reads, updates, and deletes
+              coordinator as there are reads, updates, and deletes
               involved in the transaction. However, the operation
               records of the are spread over all 8 nodes. Thus, if it is
               necessary to configure the system for one very large
@@ -3161,7 +3161,7 @@
               parts separately.
               <literal>MaxNoOfConcurrentOperations</literal> will always
               be used to calculate the number of operation records in
-              the transaction co-ordinator portion of the node.
+              the transaction coordinator portion of the node.
             </para>
 
             <para>
@@ -3294,7 +3294,7 @@
               info, <literal>ZDATABUF_FILESIZE</literal> (also in
               <filename>Dbtc.hpp</filename>) contains 4000 * 16 = 62.5KB
               of buffer space. <literal>Dbtc</literal> is the module
-              which handles transaction co-ordination.
+              which handles transaction coordination.
             </para>
           </listitem>
 
@@ -3333,7 +3333,7 @@
             <para>
               This parameter is used to control the number of parallel
               scans that can be performed in the cluster. Each
-              transaction co-ordinator can handle the number of parallel
+              transaction coordinator can handle the number of parallel
               scans defined for this parameter. Each scan query is
               performed by scanning all partitions in parallel. Each
               partition scan uses a scan record in the node where the
@@ -3364,7 +3364,7 @@
 
             <para>
               This parameter specifies the number of scans possible in
-              the transaction co-ordinator. If the number of local scan
+              the transaction coordinator. If the number of local scan
               records is not provided, it is calculated as the product
               of <literal>MaxNoOfConcurrentScans</literal> and the
               number of data nodes in the system.
@@ -4573,7 +4573,7 @@
             </para>
 
             <para>
-              The backup log buffer fulfils a role similar to that
+              The backup log buffer fulfills a role similar to that
               played by the backup data buffer, except that it used for
               generating a log of all table writes made during execution
               of the backup. The same principles apply for writing these
@@ -6424,7 +6424,7 @@
         Once this process is completed for an initial start or system
         restart, handling of transactions is enabled. For a node restart
         or initial node restart, completion of the startup process means
-        that the node may now act as a transaction co-ordinator.
+        that the node may now act as a transaction coordinator.
       </para>
 
     </section>
@@ -7069,10 +7069,10 @@
                   establish communication, or other problem</entry>
               </row>
               <row>
-                <entry>DB node neighbours</entry>
+                <entry>DB node neighbors</entry>
                 <entry>8</entry>
                 <entry>INFO</entry>
-                <entry>Shows neighbouring data nodes</entry>
+                <entry>Shows neighboring data nodes</entry>
               </row>
               <row>
                 <entry>DB node start phase <replaceable>X</replaceable> completed</entry>
@@ -7867,7 +7867,7 @@
         <para>
           <emphasis role="bold">Note</emphasis>: If there is no backup
           with ID <replaceable>backup_id</replaceable> running when it
-          is aborted, the management server does not make any exlicit
+          is aborted, the management server does not make any explicit
           response. However, the fact that an invalid abort command was
           sent is indicated in the cluster log.
         </para>
@@ -10035,7 +10035,7 @@
           All committed transactions are logged. Therefore, while it is
           possible that some data could be lost in the event of a
           catastrophe, this should be quite limited. Data loss can be
-          further reduced by minimising the number of operations per
+          further reduced by minimizing the number of operations per
           transaction. (It is not a good idea to perform large numbers
           of operations per transaction in any case.)
         </para>
@@ -10297,7 +10297,7 @@
           when no single node group has all its nodes alive, in which
           case network partitioning (the <quote>split-brain</quote>
           scenario) becomes possible. Then an arbitrator is required.
-          All cluster nodes recognise the same node as the arbitrator,
+          All cluster nodes recognize the same node as the arbitrator,
           which is normally the management server; however, it is
           possible to configure any of the MySQL Servers in the cluster
           to act as the arbitrator instead. The arbitrator accepts the
@@ -10539,7 +10539,7 @@
 
         <para>
           This is the storage engine used in MySQL to implement data
-          storage, retrieval, and management distributed amongst several
+          storage, retrieval, and management distributed among several
           computers.
         </para>
 

Modified: trunk/refman-5.0/optimization.xml
===================================================================
--- trunk/refman-5.0/optimization.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/optimization.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -6606,7 +6606,7 @@
 
       <indexterm>
         <primary>storage space</primary>
-        <secondary>minimising</secondary>
+        <secondary>minimizing</secondary>
       </indexterm>
 
       <indexterm>

Modified: trunk/refman-5.0/problems.xml
===================================================================
--- trunk/refman-5.0/problems.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/problems.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -3538,7 +3538,7 @@
 
       <para>
         If you want MySQL to check all dates and accept only legal dates
-        (unless overriden by IGNORE), you should set
+        (unless overridden by IGNORE), you should set
         <literal>sql_mode</literal> to
         <literal>"NO_ZERO_IN_DATE,NO_ZERO_DATE"</literal>.
       </para>

Modified: trunk/refman-5.0/renamed-nodes.txt
===================================================================
--- trunk/refman-5.0/renamed-nodes.txt	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/renamed-nodes.txt	2006-01-08 01:28:29 UTC (rev 716)
@@ -389,3 +389,4 @@
 mailing-list mailing-lists
 answering-questions mailing-list-use
 reproduceable-test-case reproducible-test-case
+localisation localization

Modified: trunk/refman-5.0/replication.xml
===================================================================
--- trunk/refman-5.0/replication.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/replication.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -4289,7 +4289,7 @@
       new server variables were introduced with MySQL 5.0.2:
       <literal>auto_increment_increment</literal> and
       <literal>auto_increment_offset</literal>. Each of these variables
-      has a default (and mimimum) value of 1, and a maximum value of
+      has a default (and minimum) value of 1, and a maximum value of
       65,535.
     </para>
 

Modified: trunk/refman-5.0/restrictions.xml
===================================================================
--- trunk/refman-5.0/restrictions.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/restrictions.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -171,7 +171,7 @@
     </para>
 
     <para>
-      It is possible for the same identfier to be used for a routine
+      It is possible for the same identifier to be used for a routine
       parameter, a local variable, and a table column. Also, the same
       local variable name can be used in nested blocks. For example:
     </para>

Modified: trunk/refman-5.0/sql-syntax.xml
===================================================================
--- trunk/refman-5.0/sql-syntax.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/sql-syntax.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -7503,7 +7503,7 @@
               Before MySQL 5.0.12, the comma operator
               (<literal>,</literal>) and <literal>JOIN</literal> both
               had the same precedence, so the join expression
-              <literal>t1, t2 JOIN t3</literal> was intrepreted as
+              <literal>t1, t2 JOIN t3</literal> was interpreted as
               <literal>((t1, t2) JOIN t3)</literal>. Now
               <literal>JOIN</literal> has higher precedence, so the
               expression is interpreted as <literal>(t1, (t2 JOIN
@@ -19395,7 +19395,7 @@
           <literal>START SLAVE</literal> does not warn you about this.
           You must check the slave's error log for error messages
           generated by the slave threads, or check that they are running
-          satisfactorilly with <literal>SHOW SLAVE STATUS</literal>.
+          satisfactorily with <literal>SHOW SLAVE STATUS</literal>.
         </para>
 
         <remark role="help-description-end"/>

Modified: trunk/refman-5.0/triggers.xml
===================================================================
--- trunk/refman-5.0/triggers.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.0/triggers.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -460,7 +460,7 @@
 
     <para>
       Note that the introduction of the <literal>DEFINER</literal>
-      clause changes the meeaning of <literal>CURRENT_USER()</literal>
+      clause changes the meaning of <literal>CURRENT_USER()</literal>
       within trigger definitions: The <literal>CURRENT_USER()</literal>
       function evaluates to the trigger <literal>DEFINER</literal> value
       as of MySQL 5.0.17 and to the user whose actions caused the

Modified: trunk/refman-5.1/database-administration.xml
===================================================================
--- trunk/refman-5.1/database-administration.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/database-administration.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -352,7 +352,7 @@
           <para>
             This option enables support for the InnoDB storage engine.
             MySQL-Max servers always include InnoDB support. From MySQL
-            4.0 onwards, InnoDB is included by default in all binary
+            4.0 onward, InnoDB is included by default in all binary
             distributions, so you do not need a MySQL-Max server merely
             to obtain InnoDB support.
           </para>
@@ -10811,7 +10811,7 @@
             </para>
 
             <para>
-              The number of non-cached queries (not cachable, or not
+              The number of non-cached queries (not cacheable, or not
               cached due to the <literal>query_cache_type</literal>
               setting).
             </para>
@@ -21920,9 +21920,9 @@
 
   </section>
 
-  <section id="localisation">
+  <section id="localization">
 
-    <title>&title-localisation;</title>
+    <title>&title-localization;</title>
 
     <para>
       This section describes how to configure the server to use
@@ -24372,7 +24372,7 @@
         Note that if you specify <literal>localhost</literal> as a
         hostname, <command>mysqladmin</command> defaults to using a Unix
         socket file connection rather than TCP/IP. From MySQL 4.1
-        onwards, you can explicitly specify the connection protocol to
+        onward, you can explicitly specify the connection protocol to
         use by using the <option>--protocol={TCP | SOCKET | PIPE |
         MEMORY}</option> option.
       </para>

Modified: trunk/refman-5.1/functions.xml
===================================================================
--- trunk/refman-5.1/functions.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/functions.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -9021,7 +9021,7 @@
       required by standard SQL. For this reason, dates prior to the
       cutover stored as MySQL <literal>DATE</literal> or
       <literal>DATETIME</literal> values must be adjusted to compensate
-      for the difference. It is important to realise that the cutover
+      for the difference. It is important to realize that the cutover
       did not occur at the same time in all countries, and that the
       later it happened, the more days were lost. For example, in Great
       Britain, it took place in 1752, when Wednesday September 2 was

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/innodb.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -710,7 +710,7 @@
 
         <para>
           The increment size (in megabytes) for extending the size of an
-          autoextending tablespace when it becomes full. The default
+          auto-extending tablespace when it becomes full. The default
           value is 8. This option can be changed at runtime as a global
           system variable.
         </para>
@@ -1057,7 +1057,7 @@
           shared or exclusive locks on any index records it encounters.
           Thus, the row-level locks are actually index record locks. The
           locks that <literal>InnoDB</literal> sets on index records
-          also affect the <quote>gap</quote> preceeding that index
+          also affect the <quote>gap</quote> preceding that index
           record. If a user has a shared or exclusive lock on record
           <emphasis>R</emphasis> in an index, another user cannot insert
           a new index record immediately before <emphasis>R</emphasis>
@@ -4259,7 +4259,7 @@
             <literal>innodb_table_locks=1</literal> and
             <literal>AUTOCOMMIT=0</literal>, and the MySQL layer above
             <literal>InnoDB</literal> knows about row-level locks.
-            Otherwise, InooDB's automatic deadlock detection cannot
+            Otherwise, InnoDB's automatic deadlock detection cannot
             detect deadlocks where such table locks are involved. Also,
             since the higher MySQL layer does not know about row-level
             locks, it is possible to get a table lock on a table where
@@ -4659,7 +4659,7 @@
           release Solaris &ge; 2.6 and any platform
           (sparc/x86/x64/amd64), a significant performance gain can be
           achieved by placing <literal>InnoDB</literal> data files and
-          log files on raw devices or on a seperate direct I/O UFS
+          log files on raw devices or on a separate direct I/O UFS
           Filesystem (mount option <literal>forcedirectio</literal>; see
           <literal>mount_ufs(1M)</literal>). Users of the Veritas
           filesystem VxFS should use the mount option
@@ -5782,7 +5782,7 @@
 
       <para>
         That causes MySQL to rebuild the table. Another way to perform a
-        defragmention operation is to use <command>mysqldump</command>
+        defragmentation operation is to use <command>mysqldump</command>
         to dump the table to a text file, drop the table, and reload it
         from the dump file.
       </para>

Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/ndbcluster.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -527,7 +527,7 @@
 
       <para>
         One of the strengths of MySQL Cluster is that it can be run on
-        commodity hardware and has no ususual requirements in this
+        commodity hardware and has no unusual requirements in this
         regard, other than for large amounts of RAM, due to the fact
         that all live data storage is done in memory. (Note that this is
         subject to change, and that we intend to implement disk-based
@@ -590,7 +590,7 @@
             MySQL Cluster on a private or protected network allows for
             the cluster to make exclusive use of bandwidth between
             cluster hosts. Using a separate switch for your MySQL
-            Cluster not only helps protect against unauthorised access
+            Cluster not only helps protect against unauthorized access
             to Cluster data, it also ensures that Cluster nodes are
             shielded from interference caused by transmissions between
             other computers on the network. For enhanced reliability,
@@ -1277,7 +1277,7 @@
             (beginning with MySQL 5.0.2, you may use <command>CREATE
             SCHEMA world;</command> instead), followed by <command>FLUSH
             TABLES;</command> on each SQL node in the cluster. This will
-            cause the node to recognise the database and read its table
+            cause the node to recognize the database and read its table
             definitions.
           </para>
 
@@ -1561,7 +1561,7 @@
       respect from a normal (non-clustered) MySQL server, in that it
       employs the <literal>NDB Cluster</literal> storage engine. This
       engine is also referred to simply as <literal>NDB</literal>, and
-      the two forms of the name are synonomous.
+      the two forms of the name are synonymous.
     </para>
 
     <para>
@@ -1641,7 +1641,7 @@
       <title>&title-mysql-cluster-quick;</title>
 
       <para>
-        In order to familiarise you with the basics, we will describe
+        In order to familiarize you with the basics, we will describe
         the simplest possible configuration for a functional MySQL
         Cluster. After this, you should be able to design your desired
         setup from the information provided in the other relevant
@@ -3049,7 +3049,7 @@
             <para>
               For each active transaction in the cluster there must be a
               record in one of the cluster nodes. The task of
-              coordinating transactions is spread amongst the nodes: the
+              coordinating transactions is spread among the nodes: the
               total number of transaction records in the cluster is the
               number of transactions in any given node times the number
               of nodes in the cluster.
@@ -3107,7 +3107,7 @@
 
             <para>
               Records are kept for each transaction updating cluster
-              data, both in the transaction co-ordinator and in the
+              data, both in the transaction coordinator and in the
               nodes where the actual updates are performed. These
               records contain state information needed in order to find
               UNDO records for rollback, lock queues, and other
@@ -3146,14 +3146,14 @@
               This parameter actually handles two values that can be
               configured separately. The first of these specifies how
               many operation records are to be placed with the
-              transaction co-ordinator. The second part specifies how
+              transaction coordinator. The second part specifies how
               many operation records are to be local to the database.
             </para>
 
             <para>
               A very large transaction performed on an 8-node cluster
               requires as many operation records in the transaction
-              co-ordinator as there are reads, updates, and deletes
+              coordinator as there are reads, updates, and deletes
               involved in the transaction. However, the operation
               records of the are spread over all 8 nodes. Thus, if it is
               necessary to configure the system for one very large
@@ -3161,7 +3161,7 @@
               parts separately.
               <literal>MaxNoOfConcurrentOperations</literal> will always
               be used to calculate the number of operation records in
-              the transaction co-ordinator portion of the node.
+              the transaction coordinator portion of the node.
             </para>
 
             <para>
@@ -3294,7 +3294,7 @@
               info, <literal>ZDATABUF_FILESIZE</literal> (also in
               <filename>Dbtc.hpp</filename>) contains 4000 * 16 = 62.5KB
               of buffer space. <literal>Dbtc</literal> is the module
-              which handles transaction co-ordination.
+              which handles transaction coordination.
             </para>
           </listitem>
 
@@ -3333,7 +3333,7 @@
             <para>
               This parameter is used to control the number of parallel
               scans that can be performed in the cluster. Each
-              transaction co-ordinator can handle the number of parallel
+              transaction coordinator can handle the number of parallel
               scans defined for this parameter. Each scan query is
               performed by scanning all partitions in parallel. Each
               partition scan uses a scan record in the node where the
@@ -3364,7 +3364,7 @@
 
             <para>
               This parameter specifies the number of scans possible in
-              the transaction co-ordinator. If the number of local scan
+              the transaction coordinator. If the number of local scan
               records is not provided, it is calculated as the product
               of <literal>MaxNoOfConcurrentScans</literal> and the
               number of data nodes in the system.
@@ -4573,7 +4573,7 @@
             </para>
 
             <para>
-              The backup log buffer fulfils a role similar to that
+              The backup log buffer fulfills a role similar to that
               played by the backup data buffer, except that it used for
               generating a log of all table writes made during execution
               of the backup. The same principles apply for writing these
@@ -6424,7 +6424,7 @@
         Once this process is completed for an initial start or system
         restart, handling of transactions is enabled. For a node restart
         or initial node restart, completion of the startup process means
-        that the node may now act as a transaction co-ordinator.
+        that the node may now act as a transaction coordinator.
       </para>
 
     </section>
@@ -7069,10 +7069,10 @@
                   establish communication, or other problem</entry>
               </row>
               <row>
-                <entry>DB node neighbours</entry>
+                <entry>DB node neighbors</entry>
                 <entry>8</entry>
                 <entry>INFO</entry>
-                <entry>Shows neighbouring data nodes</entry>
+                <entry>Shows neighboring data nodes</entry>
               </row>
               <row>
                 <entry>DB node start phase <replaceable>X</replaceable> completed</entry>
@@ -7867,7 +7867,7 @@
         <para>
           <emphasis role="bold">Note</emphasis>: If there is no backup
           with ID <replaceable>backup_id</replaceable> running when it
-          is aborted, the management server does not make any exlicit
+          is aborted, the management server does not make any explicit
           response. However, the fact that an invalid abort command was
           sent is indicated in the cluster log.
         </para>
@@ -9622,7 +9622,7 @@
           <quote>dummy</quote> <literal>SELECT</literal> statement using
           the new or altered table in the statement's
           <literal>FROM</literal> clause. Although the statement fails, it
-          causes the change to be recognised by the cluster. However,
+          causes the change to be recognized by the cluster. However,
           issuing a <literal>SHOW TABLES</literal> is the preferred method.
         </para>
         
@@ -11615,7 +11615,7 @@
           All committed transactions are logged. Therefore, while it is
           possible that some data could be lost in the event of a
           catastrophe, this should be quite limited. Data loss can be
-          further reduced by minimising the number of operations per
+          further reduced by minimizing the number of operations per
           transaction. (It is not a good idea to perform large numbers
           of operations per transaction in any case.)
         </para>
@@ -11877,7 +11877,7 @@
           when no single node group has all its nodes alive, in which
           case network partitioning (the <quote>split-brain</quote>
           scenario) becomes possible. Then an arbitrator is required.
-          All cluster nodes recognise the same node as the arbitrator,
+          All cluster nodes recognize the same node as the arbitrator,
           which is normally the management server; however, it is
           possible to configure any of the MySQL Servers in the cluster
           to act as the arbitrator instead. The arbitrator accepts the
@@ -12119,7 +12119,7 @@
 
         <para>
           This is the storage engine used in MySQL to implement data
-          storage, retrieval, and management distributed amongst several
+          storage, retrieval, and management distributed among several
           computers.
         </para>
 

Modified: trunk/refman-5.1/optimization.xml
===================================================================
--- trunk/refman-5.1/optimization.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/optimization.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -6576,7 +6576,7 @@
 
       <indexterm>
         <primary>storage space</primary>
-        <secondary>minimising</secondary>
+        <secondary>minimizing</secondary>
       </indexterm>
 
       <indexterm>

Modified: trunk/refman-5.1/problems.xml
===================================================================
--- trunk/refman-5.1/problems.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/problems.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -3538,7 +3538,7 @@
 
       <para>
         If you want MySQL to check all dates and accept only legal dates
-        (unless overriden by IGNORE), you should set
+        (unless overridden by IGNORE), you should set
         <literal>sql_mode</literal> to
         <literal>"NO_ZERO_IN_DATE,NO_ZERO_DATE"</literal>.
       </para>

Modified: trunk/refman-5.1/renamed-nodes.txt
===================================================================
--- trunk/refman-5.1/renamed-nodes.txt	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/renamed-nodes.txt	2006-01-08 01:28:29 UTC (rev 716)
@@ -92,3 +92,4 @@
 mailing-list mailing-lists
 answering-questions mailing-list-use
 reproduceable-test-case reproducible-test-case
+localisation localization

Modified: trunk/refman-5.1/replication.xml
===================================================================
--- trunk/refman-5.1/replication.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/replication.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -4838,7 +4838,7 @@
         <literal>auto_increment_increment</literal> and
         <literal>auto_increment_offset</literal> help to accommodate
         multi-master replication with <literal>AUTO_INCREMENT</literal>
-        columns. Each of these variables has a default (and mimimum)
+        columns. Each of these variables has a default (and minimum)
         value of 1, and a maximum value of 65,535.
       </para>
 

Modified: trunk/refman-5.1/restrictions.xml
===================================================================
--- trunk/refman-5.1/restrictions.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/restrictions.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -148,7 +148,7 @@
     </para>
 
     <para>
-      It is possible for the same identfier to be used for a routine
+      It is possible for the same identifier to be used for a routine
       parameter, a local variable, and a table column. Also, the same
       local variable name can be used in nested blocks. For example:
     </para>

Modified: trunk/refman-5.1/sql-syntax.xml
===================================================================
--- trunk/refman-5.1/sql-syntax.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-5.1/sql-syntax.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -2915,7 +2915,7 @@
 
               <para>
                 A table implementing such a partitioning scheme can be
-                realised by the <literal>CREATE TABLE</literal>
+                realized by the <literal>CREATE TABLE</literal>
                 statement shown here:
               </para>
 
@@ -8060,7 +8060,7 @@
               In older versions, the comma operator
               (<literal>,</literal>) and <literal>JOIN</literal> both
               had the same precedence, so the join expression
-              <literal>t1, t2 JOIN t3</literal> was intrepreted as
+              <literal>t1, t2 JOIN t3</literal> was interpreted as
               <literal>((t1, t2) JOIN t3)</literal>. Now
               <literal>JOIN</literal> has higher precedence, so the
               expression is interpreted as <literal>(t1, (t2 JOIN
@@ -19857,7 +19857,7 @@
           <literal>START SLAVE</literal> does not warn you about this.
           You must check the slave's error log for error messages
           generated by the slave threads, or check that they are running
-          satisfactorilly with <literal>SHOW SLAVE STATUS</literal>.
+          satisfactorily with <literal>SHOW SLAVE STATUS</literal>.
         </para>
 
         <remark role="help-description-end"/>

Modified: trunk/refman-common/news-3.23.xml
===================================================================
--- trunk/refman-common/news-3.23.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/news-3.23.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -1519,7 +1519,7 @@
       <listitem>
         <para>
           <literal>InnoDB</literal> tables can now be set to
-          automatically grow in size (autoextend).
+          automatically grow in size (auto-extend).
         </para>
       </listitem>
 

Modified: trunk/refman-common/news-4.0.xml
===================================================================
--- trunk/refman-common/news-4.0.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/news-4.0.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -940,7 +940,7 @@
           InnoDB if one runs <literal>INSERT ... SELECT ...</literal>
           (binlog not enabled), or a multi-table
           <literal>UPDATE</literal> or <literal>DELETE</literal>, and
-          only the read tables are InnoDB type, the rest are MyISAM;
+          only the read tables are InnoDB type, the rest are <literal>MyISAM</literal>;
           this also fixes bug #7879 for InnoDB type tables. (Bug #7879)
         </para>
       </listitem>
@@ -1502,7 +1502,7 @@
 
       <listitem>
         <para>
-          Fixed that if a write to a MyISAM table fails because of a
+          Fixed that if a write to a <literal>MyISAM</literal> table fails because of a
           full disk or an exceeded disk quota, it prints a message to
           the error log every 10 minutes, and waits until disk becomes
           free. (Bug #3248)
@@ -8381,7 +8381,7 @@
       <listitem>
         <para>
           <literal>InnoDB</literal> tables can now be set to
-          automatically grow in size (autoextend).
+          automatically grow in size (auto-extend).
         </para>
       </listitem>
 

Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/news-4.1.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -272,7 +272,7 @@
       <listitem>
         <para>
           <literal>NDB Cluster</literal>: If an abort by the Transaction
-          Co-ordinator timed out, the abort condition was incorrectly
+          Coordinator timed out, the abort condition was incorrectly
           handled, causing the transacviton record to be released
           prematurely. (Bug #15685)
         </para>
@@ -1373,7 +1373,7 @@
       <listitem>
         <para>
           <literal>InnoDB</literal> was too permissive with
-          <literal>LOCK TABLE ... READ LOCAL</literal> and alowed new
+          <literal>LOCK TABLE ... READ LOCAL</literal> and allowed new
           inserts into the table. Now <literal>READ LOCAL</literal> is
           equivalent to <literal>READ</literal> for
           <literal>InnoDB</literal>. This will cause slightly more
@@ -3696,7 +3696,7 @@
       <listitem>
         <para>
           <literal>TIMEDIFF()</literal> with a negative time first
-          argument and postive time second argument produced incorrect
+          argument and positive time second argument produced incorrect
           results. (Bug #8068)
         </para>
       </listitem>
@@ -4585,7 +4585,7 @@
         <para>
           <literal>InnoDB</literal>: If one used <literal>LOCK
           TABLES</literal>, created an InnoDB temp table, and did a
-          multi-table update where a MyISAM table was the update table
+          multi-table update where a <literal>MyISAM</literal> table was the update table
           and the temp table was a read table, then InnoDB asserted in
           <filename>row0sel.c</filename> because
           <literal>n_mysql_tables_in_use</literal> was 0. Also, we
@@ -5483,7 +5483,7 @@
           InnoDB if one runs <literal>INSERT ... SELECT ...</literal>
           (binlog not enabled), or a multi-table
           <literal>UPDATE</literal> or <literal>DELETE</literal>, and
-          only the read tables are InnoDB type, the rest are MyISAM.
+          only the read tables are InnoDB type, the rest are <literal>MyISAM</literal>.
           (Bug #7879)
         </para>
       </listitem>
@@ -5959,8 +5959,8 @@
         <para>
           Added <option>--order-by-primary</option> to
           <command>mysqldump</command>, to sort each table's data in a
-          dump file. This may be useful when dumping a MyISAM table
-          which will be loaded into an InnoDB table. Dumping a MyISAM
+          dump file. This may be useful when dumping a <literal>MyISAM</literal> table
+          which will be loaded into an InnoDB table. Dumping a <literal>MyISAM</literal>
           table with this option is considerably slower than without.
         </para>
       </listitem>

Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/news-5.0.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -3598,7 +3598,7 @@
       <listitem>
         <para>
           <literal>InnoDB</literal> was too permissive with
-          <literal>LOCK TABLE ... READ LOCAL</literal> and alowed new
+          <literal>LOCK TABLE ... READ LOCAL</literal> and allowed new
           inserts into the table. Now <literal>READ LOCAL</literal> is
           equivalent to <literal>READ</literal> for
           <literal>InnoDB</literal>. This will cause slightly more
@@ -7352,7 +7352,7 @@
       <listitem>
         <para>
           The variable <literal>concurrent_insert</literal> now takes 3
-          values. Setting this to 2 changes MyISAM to do concurrent
+          values. Setting this to 2 changes <literal>MyISAM</literal> to do concurrent
           inserts to end of table if table is in use by another thread.
         </para>
       </listitem>
@@ -8153,7 +8153,7 @@
         <para>
           The server died with signal 11 if a non-existent location was
           specified for the location of the binary log. Now the server
-          exits after printing an appropriate error messsage. (Bug
+          exits after printing an appropriate error message. (Bug
           #9542)
         </para>
       </listitem>
@@ -8212,7 +8212,7 @@
       <listitem>
         <para>
           <literal>TIMEDIFF()</literal> with a negative time first
-          argument and postive time second argument produced incorrect
+          argument and positive time second argument produced incorrect
           results. (Bug #8068)
         </para>
       </listitem>
@@ -10870,7 +10870,7 @@
 
       <listitem>
         <para>
-          Fixed that if a write to a MyISAM table fails because of a
+          Fixed that if a write to a <literal>MyISAM</literal> table fails because of a
           full disk or an exceeded disk quota, it prints a message to
           the error log every 10 minutes, and waits until disk becomes
           free. (Bug #3248)

Modified: trunk/refman-common/news-cluster.xml
===================================================================
--- trunk/refman-common/news-cluster.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/news-cluster.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -1554,7 +1554,7 @@
 
       <listitem>
         <para>
-          Added more checks and warnings for erroneous and unappropriate
+          Added more checks and warnings for erroneous and inappropriate
           cluster configurations.
         </para>
       </listitem>

Modified: trunk/refman-common/news-connector-j.xml
===================================================================
--- trunk/refman-common/news-connector-j.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/news-connector-j.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -261,7 +261,7 @@
       reports incorrect values for servers deployed on Windows.
   
     - Fixed BUG#11190 - ResultSet.moveToCurrentRow() fails to work when 
-      preceeded by a call to ResultSet.moveToInsertRow().
+      preceded by a call to ResultSet.moveToInsertRow().
   
     - Fixed BUG#11115, VARBINARY data corrupted when using server-side
       prepared statements and .setBytes().

Modified: trunk/refman-common/news-connector-net.xml
===================================================================
--- trunk/refman-common/news-connector-net.xml	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/news-connector-net.xml	2006-01-08 01:28:29 UTC (rev 716)
@@ -240,7 +240,7 @@
 
       <listitem>
         <para>
-          Parameters were not recognised when they were separated by
+          Parameters were not recognized when they were separated by
           linefeeds. (Bug #9722)
         </para>
       </listitem>
@@ -2294,7 +2294,7 @@
 
       <listitem>
         <para>
-          Fixed bug in driver where error messsages were getting
+          Fixed bug in driver where error messages were getting
           truncated by 1 character (thanks Shane Krueger)
         </para>
       </listitem>

Modified: trunk/refman-common/titles.en.ent
===================================================================
--- trunk/refman-common/titles.en.ent	2006-01-07 21:27:25 UTC (rev 715)
+++ trunk/refman-common/titles.en.ent	2006-01-08 01:28:29 UTC (rev 716)
@@ -625,7 +625,7 @@
 <!ENTITY title-load-index "<literal>LOAD INDEX INTO CACHE</literal> Syntax">
 <!ENTITY title-load-table-from-master "<literal>LOAD TABLE <replaceable>tbl_name</replaceable> FROM MASTER</literal> Syntax">
 <!ENTITY title-loading-tables "Loading Data into a Table">
-<!ENTITY title-localisation "MySQL Localization and International Usage">
+<!ENTITY title-localization "MySQL Localization and International Usage">
 <!ENTITY title-lock-tables "<literal>LOCK TABLES</literal> and <literal>UNLOCK TABLES</literal> Syntax">
 <!ENTITY title-locking-issues "Locking Issues">
 <!ENTITY title-log-file-maintenance "Log File Maintenance">

Thread
svn commit - mysqldoc@docsrva: r716 - in trunk: . internals refman refman-4.1 refman-5.0 refman-5.1 refman-commonpaul8 Jan