Fix various comment and documentation typos

Doc/Manual/Allegrocl.html

@@ -155,7 +155,7 @@ SWIG directives. SWIG can be furnished with a header file, but an
 interface can also be generated without library headers by supplying a
 simple text file--called the interface file, which is typically named
 with a <tt>.i</tt> extension--containing any foreign declarations of
-identifiers you wish to use. The most common approach is to use a an
+identifiers you wish to use. The most common approach is to use an
 interface file with directives to parse the needed headers. A straight
 parse of library headers will result in usable code, but SWIG
 directives provides much freedom in how a user might tailor the

Doc/Manual/Android.html

@@ -409,7 +409,7 @@ All the steps required to compile and use a simple hierarchy of classes for shap
 
 <p>
 First create an Android project called <tt>SwigClass</tt> in a subdirectory called <tt>class</tt>.
-The steps below create and build a the JNI C++ app.
+The steps below create and build the JNI C++ app.
 Adjust the <tt>--target</tt> id as mentioned earlier in the <a href="Android.html#Android_examples_intro">Examples introduction</a>.
 </p>
 

Doc/Manual/CCache.html

@@ -411,7 +411,7 @@ following conditions need to be met:
 
 
 <p>
-ccache was inspired by the compilercache shell script script written
+ccache was inspired by the compilercache shell script written
 by Erik Thiele and I would like to thank him for an excellent piece of
 work. See
 <a href="http://www.erikyyy.de/compilercache/">http://www.erikyyy.de/compilercache/</a>

Doc/Manual/CSharp.html

@@ -1772,7 +1772,7 @@ should pass the call on to <tt>CSharpDefaults.DefaultMethod(int)</tt>using the C
 
 
 <p>
-When using <a href="Modules.html#Modules">multiple modules</a> it is is possible to compile each SWIG generated wrapper
+When using <a href="Modules.html#Modules">multiple modules</a> it is possible to compile each SWIG generated wrapper
 into a different assembly.
 However, by default the generated code may not compile if 
 generated classes in one assembly use generated classes in another assembly.

Doc/Manual/D.html

@@ -280,7 +280,7 @@ class SomeClass : AnInterface, AnotherInterface {
   ...
 }
 </pre></div>
-    <p>For this to work, <tt>AnInterface</tt> and <tt>AnotherInterface</tt> have to be in scope. If SWIG is not in split proxy mode, this is already the case, but it it is, they have to be added to the import list via the <tt>dimports</tt> typemap. Additionally, the import statement depends on the package SWIG is configured to emit the modules to.</p>
+    <p>For this to work, <tt>AnInterface</tt> and <tt>AnotherInterface</tt> have to be in scope. If SWIG is not in split proxy mode, this is already the case, but if it is, they have to be added to the import list via the <tt>dimports</tt> typemap. Additionally, the import statement depends on the package SWIG is configured to emit the modules to.</p>
     <p>The <tt>$importtype</tt> macro helps you to elegantly solve this problem:</p>
 <div class="code"><pre>
 %typemap(dimports) RemoteMpe %{

Doc/Manual/Extending.html

@@ -1576,7 +1576,7 @@ return the node for the first class member.
 
 <div class="indent">
 Returns the last child node.   You might use this if you wanted to append a new
-node to the of a class.
+node to the children of a class.
 </div>
 
 <p>
@@ -3164,7 +3164,7 @@ these kinds of problems.
 </p>
 
 <dt> <b>Examples/Makefile.in</b>
-<dd> Nothing special here; see comments at top the of this file
+<dd> Nothing special here; see comments at the top of this file
 and look to the existing languages for examples.
 
 <dt> <b>Examples/qux99/check.list</b>

Doc/Manual/Java.html

@@ -4105,7 +4105,7 @@ the exception specification or <code>%catches</code> feature.
 </p>
 
 <p>Note that the "directorthrows" typemaps are important
-only if it is important for the the exceptions passed through the C++
+only if it is important for the exceptions passed through the C++
 layer to be mapped to distinct C++ exceptions.  If director methods
 are being called by C++ code that is itself wrapped in a
 SWIG generated Java wrapper and access is always through this wrapper,

Doc/Manual/Php.html

@@ -163,7 +163,7 @@ If the module is in PHP's default extension directory, you can omit the path.
 <p>
 For some SAPIs (for example, the CLI SAPI) you can instead use the
 <a href="http://php.net/manual/en/function.dl.php">dl() function</a> to load
-an extension at run time, by adding a like like this to the start of each
+an extension at run time, by adding a line like this to the start of each
 PHP script which uses your extension:
 </p>
 

Doc/Manual/Python.html

@@ -6046,7 +6046,7 @@ zipimporter requires python-3.5.1 or newer to work with subpackages.
 
 <p>
 When SWIG creates wrappers from an interface file, say foo.i, two Python modules are
-created.  There is a pure Python module module (foo.py) and C/C++ code which is
+created.  There is a pure Python module (foo.py) and C/C++ code which is
 built and linked into a dynamically (or statically) loaded low-level module _foo
 (see the <a href="Python.html#Python_nn3">Preliminaries section</a> for details).  So, the interface
 file really defines two Python modules.   How these two modules are loaded is

Doc/Manual/SWIGPlus.html

@@ -2779,7 +2779,7 @@ into two methods such that additional logic can be packed into the operations; C
 <tt>this[type key] { get { ... } set { ... }}</tt>, Python uses
 <tt>__getitem__</tt> and <tt>__setitem__</tt>, etc. In C++ if the return
 type of <tt>operator[]</tt> is a reference and the method is const, it is often indicative of the <i>setter</i>,
-and and the <i>getter</i> is usually a const function return an object by value.
+and the <i>getter</i> is usually a const function return an object by value.
 In the absence of any hard and fast rules and the fact that there may be multiple index operators,
 it is up to the user to choose the getter and setter to use by using %rename as shown earlier.
 </p>

Doc/Manual/Scilab.html

@@ -1136,7 +1136,7 @@ But we can use either use the <tt>get_perimeter()</tt> function of the parent cl
 As explained in <a href="SWIGPlus.html#SWIGPlus_overloaded_methods">6.15</a> SWIG provides support for overloaded functions and constructors.
 </p>
 
-<p>As SWIG knows pointer types, the overloading works also with pointer types, here is is an example with a function <tt>magnify</tt> overloaded for the previous classes <tt>Shape</tt> and <tt>Circle</tt>:
+<p>As SWIG knows pointer types, the overloading works also with pointer types, here is an example with a function <tt>magnify</tt> overloaded for the previous classes <tt>Shape</tt> and <tt>Circle</tt>:
 </p>
 
 <div class="code"><pre>
@@ -1620,11 +1620,11 @@ void printArray(int values[], int len) {
 
 
 <p>
-There are no specific typemaps for pointer-to-pointers, they are are mapped as pointers in Scilab.
+There are no specific typemaps for pointer-to-pointers, they are mapped as pointers in Scilab.
 </p>
 
 <p>
-Pointer-to-pointers are sometimes used to implement matrices in C. The following is a an example of this:
+Pointer-to-pointers are sometimes used to implement matrices in C. The following is an example of this:
 </p>
 
 
@@ -2062,7 +2062,7 @@ In this mode, the following SWIG options may be used to setup the build:
 Let's give an example how to build a module <tt>example</tt>, composed of two sources, and using a library dependency:
 </p>
 <ul>
-<li>the sources are <tt>baa1.c</tt> and <tt>baa2.c</tt> (and are stored in in the current directory)</li>
+<li>the sources are <tt>baa1.c</tt> and <tt>baa2.c</tt> (and are stored in the current directory)</li>
 <li>the library is <tt>libfoo</tt> in <tt>/opt/foo</tt> (headers stored in <tt>/opt/foo/include</tt>, and shared library in <tt>/opt/foo/lib</tt>)</li>
 </ul>