Use consistant spelling in documentation

behavior -> behaviour
initialize -> initialse
initialization -> initialisation

doc/zmq.txt

@@ -55,7 +55,7 @@ Individual 0MQ 'sockets' are _not_ thread safe except in the case where full
 memory barriers are issued when migrating a socket from one thread to another.
 In practice this means applications can create a socket in one thread with
 _zmq_socket()_ and then pass it to a _newly created_ thread as part of thread
-initialization, for example via a structure passed as an argument to
+initialisation, for example via a structure passed as an argument to
 _pthread_create()_.
 
 

doc/zmq_ctx_destroy.txt

@@ -33,7 +33,7 @@ Context termination is performed in the following steps:
      peer, or the socket's linger period set with the _ZMQ_LINGER_ socket
      option has expired.
 
-For further details regarding socket linger behavior refer to the _ZMQ_LINGER_
+For further details regarding socket linger behaviour refer to the _ZMQ_LINGER_
 option in linkzmq:zmq_setsockopt[3].
 
 This function is deprecated by linkzmq:zmq_ctx_term[3].

doc/zmq_ctx_term.txt

@@ -33,7 +33,7 @@ Context termination is performed in the following steps:
      peer, or the socket's linger period set with the _ZMQ_LINGER_ socket
      option has expired.
 
-For further details regarding socket linger behavior refer to the _ZMQ_LINGER_
+For further details regarding socket linger behaviour refer to the _ZMQ_LINGER_
 option in linkzmq:zmq_setsockopt[3].
 
 This function replaces the deprecated function linkzmq:zmq_term[3].

doc/zmq_ipc.txt

@@ -41,7 +41,7 @@ socket option. See linkzmq:zmq_getsockopt[3] for details.
 
 NOTE: any existing binding to the same endpoint shall be overridden. That is,
 if a second process binds to an endpoint already bound by a process, this
-will succeed and the first process will lose its binding. In this behavior,
+will succeed and the first process will lose its binding. In this behaviour,
 the 'ipc' transport is not consistent with the 'tcp' or 'inproc' transports.
 
 NOTE: the endpoint pathname must be writable by the process. When the endpoint

doc/zmq_msg_copy.txt

@@ -16,7 +16,7 @@ DESCRIPTION
 -----------
 The _zmq_msg_copy()_ function shall copy the message object referenced by 'src'
 to the message object referenced by 'dest'. The original content of 'dest', if
-any, shall be released. You must initialize 'dest' before copying to it.
+any, shall be released. You must initialise 'dest' before copying to it.
 
 CAUTION: The implementation may choose not to physically copy the message
 content, rather to share the underlying buffer between 'src' and 'dest'. Avoid

doc/zmq_msg_init.txt

@@ -22,7 +22,7 @@ CAUTION: Never access 'zmq_msg_t' members directly, instead always use the
 _zmq_msg_ family of functions.
 
 CAUTION: The functions _zmq_msg_init()_, _zmq_msg_init_data()_ and
-_zmq_msg_init_size()_ are mutually exclusive. Never initialize the same
+_zmq_msg_init_size()_ are mutually exclusive. Never initialise the same
 'zmq_msg_t' twice.
 
 

doc/zmq_msg_init_data.txt

@@ -36,7 +36,7 @@ will not be freed, and this may cause a memory leak.
 
 
 CAUTION: The functions _zmq_msg_init()_, _zmq_msg_init_data()_ and
-_zmq_msg_init_size()_ are mutually exclusive. Never initialize the same
+_zmq_msg_init_size()_ are mutually exclusive. Never initialise the same
 'zmq_msg_t' twice.
 
 

doc/zmq_msg_init_size.txt

@@ -26,7 +26,7 @@ CAUTION: Never access 'zmq_msg_t' members directly, instead always use the
 _zmq_msg_ family of functions.
 
 CAUTION: The functions _zmq_msg_init()_, _zmq_msg_init_data()_ and
-_zmq_msg_init_size()_ are mutually exclusive. Never initialize the same
+_zmq_msg_init_size()_ are mutually exclusive. Never initialise the same
 'zmq_msg_t' twice.
 
 

doc/zmq_setsockopt.txt

@@ -73,7 +73,7 @@ The 'ZMQ_CONNECT_RID' option sets the peer id of the next host connected
 via the zmq_connect() call, and immediately readies that connection for 
 data transfer with the named id.  This option applies only to the first
 subsequent call to zmq_connect(), calls thereafter use default connection 
-behavior. 
+behaviour. 
 
 Typical use is to set this socket option ahead of each zmq_connect() attempt 
 to a new host. Each connection MUST be assigned a unique name. Assigning a 
@@ -530,7 +530,7 @@ Applicable socket types:: all, when using multicast transports
 
 ZMQ_REQ_CORRELATE: match replies with requests
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The default behavior of REQ sockets is to rely on the ordering of messages to
+The default behaviour of REQ sockets is to rely on the ordering of messages to
 match requests and responses and that is usually sufficient. When this option
 is set to 1, the REQ socket will prefix outgoing messages with an extra frame
 containing a request id. That means the full message is (request id, 0,
@@ -583,7 +583,7 @@ Applicable socket types:: ZMQ_ROUTER
 
 ZMQ_ROUTER_MANDATORY: accept only routable messages on ROUTER sockets
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Sets the ROUTER socket behavior when an unroutable message is encountered. A
+Sets the ROUTER socket behaviour when an unroutable message is encountered. A
 value of `0` is the default and discards the message silently when it cannot be
 routed or the peers SNDHWM is reached.  A value of `1` returns an
 'EHOSTUNREACH' error code if the message cannot be routed or 'EAGAIN' error
@@ -770,7 +770,7 @@ Applicable socket types:: ZMQ_SUB
 
 ZMQ_XPUB_VERBOSE: provide all subscription messages on XPUB sockets
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Sets the 'XPUB' socket behavior on new subscriptions and unsubscriptions.
+Sets the 'XPUB' socket behaviour on new subscriptions and unsubscriptions.
 A value of '0' is the default and passes only new subscription messages to
 upstream. A value of '1' passes all subscription messages upstream.