Fixing typos on docs (mvantellingen#694)

docs/attachments.rst

@@ -3,7 +3,7 @@ SOAP Attachments (multipart)
 ============================
 
 If the server responds with a Content-type: multipart, a MessagePack object
-will be returned. It contains a root object and a number of attachments.
+will be returned. It contains a root object and some attachments.
 
 Example based on https://www.w3.org/TR/SOAP-attachments
 

docs/client.rst

@@ -7,7 +7,7 @@ The Client object
 The :class:`Client` is the main interface for interacting with a SOAP server.
 It provides a ``service`` attribute which references the default binding of
 the client (via a :class:`ServiceProxy` object). The default binding can be specified
-when initating the client by passing the ``service_name`` and ``port_name``.
+when initiating the client by passing the ``service_name`` and ``port_name``.
 Otherwise the first service and first port within that service are used as the
 default.
 
@@ -16,9 +16,9 @@ default.
 
 Caching of WSDL and XSD files
 ------------------------------
-When the client is initialised it will automaticaly retrieve the wsdl file
-passed as argument. This wsdl file generally references various other wsdl and
-xsd files. By default Zeep doesn't cache these files but it is however
+When the client is initialized it will automatically retrieve the WSDL file
+passed as argument. This WSDL file generally references various other WSDL and
+XSD files. By default Zeep doesn't cache these files but it is however
 advised to enable this for performance reasons.
 
 Please see :ref:`transport_caching` how to enable this. To make it easy to
@@ -49,7 +49,7 @@ kwarg ``strict=False`` to the ``Client``.  Disabling strict mode will change
 the following behaviour:
 
  - The XML is parsed with the recover mode enabled
- - Non optional elements are allowed to be missing in xsd:sequences
+ - Nonoptional elements are allowed to be missing in xsd:sequences
 
 Note that disabling strict mode should be considered a last resort since it
 might result in data-loss between the XML and the returned response.
@@ -100,15 +100,15 @@ operation on the binding.
     client.service.X()
 
     # The operation can also be called via an __getitem__ call.
-    # This is usefull if the operation name is not a valid
+    # This is useful if the operation name is not a valid
     # python attribute name.
     client.service['X-Y']()
 
 
 Using non-default bindings
 --------------------------
-As mentioned by default Zeep picks the first binding in the wsdl as the
-default. This binding is availble via ``client.service``. To use a specific
+As mentioned by default Zeep picks the first binding in the WSDL as the
+default. This binding is available via ``client.service``. To use a specific
 binding you can use the ``bind()`` method on the client object:
 
 

docs/headers.rst

@@ -6,7 +6,7 @@ elements can be passed to all operations using the ``_soapheaders`` kwarg.
 
 There are multiple ways to pass a value to the soapheader.
 
-1. When the soap header expects a complex type you can either pass a dict or
+1. When the SOAP header expects a complex type you can either pass a dict or
    an object created via the ``client.get_element()`` method.
 2. When the header expects a simple type value you can pass it directly to the
    ``_soapheaders`` kwarg. (e.g.: ``client.service.Method(_soapheaders=1234)``)

docs/helpers.rst

@@ -1,7 +1,7 @@
 Helpers
 =======
 
-In the `zeep.helpers` module the following helpers functions are available:
+In the `zeep.helpers` module the following helper functions are available:
 
 .. automodule:: zeep.helpers
    :members:

docs/in_depth.rst

@@ -11,7 +11,7 @@ of the time this is an implementation detail, Zeep should offer the same API
 to the user independent of the underlying protocol.
 
 One of the first things you will do if you start developing an interface to a
-wsdl webservice is to get an overview of all available operations and their
+wsdl web service is to get an overview of all available operations and their
 call signatures. Zeep offers a command line interface to make this easy.
 
 

docs/plugins.rst

@@ -5,7 +5,7 @@ Plugins
 .. versionadded:: 0.15
 
 You can write plugins for zeep which can be used to process/modify data before
-it is send to the server (egress) and after it is received (ingress).
+it is sent to the server (egress) and after it is received (ingress).
 
 Writing a plugin is really simple and best explained via an example.
 

docs/transport.rst

@@ -5,7 +5,7 @@ need to create an instance of the Transport class yourself.
 
 SSL verification
 ----------------
-If you need to verficate the SSL connection (in case you have a self signed certificate for your host), the best way is to create a :class:`requests.Session` instance and add the information to that Session, so it keeps persistent:
+If you need to verify the SSL connection (in case you have a self-signed certificate for your host), the best way is to create a :class:`requests.Session` instance and add the information to that Session, so it keeps persistent:
 
 .. code-block:: python
 
@@ -21,9 +21,8 @@ If you need to verficate the SSL connection (in case you have a self signed cert
         transport=transport)
 
 .. HINT::
-
-    Make sure that the certificate you refer to is a CA_BUNDLE, meaning it contains a root CA and an intermediate CA.
-    Accepted are only X.509 ASCII files (file extension ``.pem``, sometimes ``crt``). If you have two different files, you must combine them manually into one.
+Make sure that the certificate you refer to is a CA_BUNDLE, meaning it contains a root CA and an intermediate CA.
+Accepted are only X.509 ASCII files (file extension ``.pem``, sometimes ``.crt``). If you have two different files, you must combine them manually into one. 
 
 Alternatively, instead of using ``session.verify`` you can use ``session.cert`` if you just want to use an SSL client certificate.
 

docs/wsa.rst

@@ -5,10 +5,10 @@ WS-Addressing (WSA)
 .. versionadded:: 0.15
 
 Zeep offers (experimental) support for the `ws-addressing specification`_. The
-specification defines a number of soap:Header elements which basically allows
+specification defines some soap:Header elements which basically allows
 advanced routing of the SOAP messages.
 
-If the WSDL documnt defines that WSA is required then Zeep will automatically
+If the WSDL document defines that WSA is required then Zeep will automatically
 add the required headers to the SOAP envelope. In case you want to customize
 this then you can add the :class:`~zeep.wsa.WsAddressPlugin` to the
 :attr:`Client.plugins` list.
@@ -29,7 +29,7 @@ For example:
 .. note::
 
     The support for ws-addressing is experimental. If you encounter any issues
-    then please don't hesistate to create an issue on the github repository.
+    then please don't hesitate to create an issue on the github repository.
 
 
 .. _ws-addressing specification: https://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/