doc: Typo fixes

7 files changed, 21 insertions, 21 deletions

diff --git a/doc/agent-api.txt b/doc/agent-api.txt
index d215b9be..b4b8a39d 100644
--- a/doc/agent-api.txt
+++ b/doc/agent-api.txt
@@ -31,8 +31,8 @@ Methods		void Release()
 
 			The return value should be a dictionary where the
 			keys are the field names and the values are the
-			actual fields. Alternative an error indicating that
-			the request got cannceled can be returned.
+			actual fields. Alternatively an error indicating that
+			the request got canceled can be returned.
 
 			Most common return field names are "Name" and of
 			course "Passphrase".
@@ -76,8 +76,8 @@ Arguments	string Type
 			Contains the requirement option. Valid values are
 			"mandatory", "optional" or "alternate".
 
-			The "alternate" specifies that this field can be
-			return as an alternative to another one. An example
+			The "alternate" value specifies that this field can be
+			returned as an alternative to another one. An example
 			would be the network name or SSID.
 
 			All "mandatory" fields must be returned, while the
diff --git a/doc/backtrace.txt b/doc/backtrace.txt
index 951aa06a..fdeee090 100644
--- a/doc/backtrace.txt
+++ b/doc/backtrace.txt
@@ -8,7 +8,7 @@ backtrace will be dumped to syslog.
 The ConnMan backtraces start with the following line:
 	++++++++ ConnMan backtrace ++++++++
 and will try to display function names if those can be resolved from the stack
-addresses. All static functions name will not appeared for example.
+addresses. All static functions name will not appear for example.
 
 For a more complete and useful stack frame output you can use the
 test/backtrace script. It takes the actual binary that crashed and the
diff --git a/doc/counter-api.txt b/doc/counter-api.txt
index 9ec5f21b..32411d57 100644
--- a/doc/counter-api.txt
+++ b/doc/counter-api.txt
@@ -27,7 +27,7 @@ Methods		void Release()
 			When "home" counter is active, then "roaming" counter
 			will contain an empty dictionary and vise-versa.
 
-			The dictionary argument contains following entries:
+			The dictionary argument contains the following entries:
 
 				RX.Packets
 
diff --git a/doc/ipconfig-api.txt b/doc/ipconfig-api.txt
index 179e86fc..080fdac5 100644
--- a/doc/ipconfig-api.txt
+++ b/doc/ipconfig-api.txt
@@ -5,7 +5,7 @@ IP configuration handling
 IP basics
 =========
 
-The core IP handling is designed around network interfaces or more precise
+The core IP handling is designed around network interfaces or more precisely
 what the Linux kernel handles as struct net_device. Via RTNL every interface
 is tracked and an IP device created for it.
 
diff --git a/doc/overview-api.txt b/doc/overview-api.txt
index 926f9ebe..92ce2b90 100644
--- a/doc/overview-api.txt
+++ b/doc/overview-api.txt
@@ -37,7 +37,7 @@ the order of services in this list.
 	| Other WiMAX      (strength 50)        |
 	+---------------------------------------+
 
-If non of the services has been used before the sorting order will be done
+If none of the services has been used before the sorting order will be done
 with these priorities:
 
 	1. Ethernet	(lower index numbers first)
@@ -63,12 +63,12 @@ before others since it is more likely they are selected first. The signal
 strength value is normalized to 0-100 (effectively a percentage) and allows
 an easy sorting.
 
-If the signal strength is identical than the WiMAX network should be shown
+If the signal strength is identical then the WiMAX network should be shown
 first since it is a licensed spectrum and more reliable. Also the number
 of WiMAX networks will be smaller than the number of WiFi since that operates
 in an unlicensed spectrum.
 
-WiFi networks with the same signal strength are then sorted by its security
+WiFi networks with the same signal strength are then sorted by their security
 setting. WPA2 encrypted networks should be preferred over WPA/WEP and also
 unencrypted ones. After that they will be sorted by the SSID in alphabetical
 order.
@@ -122,13 +122,13 @@ remove the favorite selection.
 	|                                       |
 
 This means that all services with an order > 0 have favorite=yes and all
-other have favorite=no setting. The favorite setting is exposed via a
+others have favorite=no setting. The favorite setting is exposed via a
 property over the service interface. As mentioned above, the order number
 is only used internally.
 
-Within Connection Manager many service can be connected at the same time and
+Within Connection Manager many services can be connected at the same time and
 also have an IP assignment. However only one can have the default route. The
-service with the the default route will always be sorted at the top of the
+service with the default route will always be sorted at the top of the
 list.
 
 	+---------------------------------------+
@@ -230,8 +230,8 @@ In case of WiFi this will be the SSID value. The SSID is a binary array and
 will be converted into printable form. Unprintable characters are replaced
 with spaces.
 
-For WiMAX networks the provide name like Clear or X-OHM will be used. This
-name either comes directly from the networks itself or from a provisioning
+For WiMAX networks the provider name like Clear or X-OHM will be used. This
+name either comes directly from the network itself or from a provisioning
 database of the WiMAX service.
 
 For Bluetooth the device alias is used. The alias is different since it
@@ -382,7 +382,7 @@ just telling it to actually connect:
 
 	service.Connect()  or  service.Disconnect()
 
-It is possible to connect multiple service if the underlying technology
+It is possible to connect multiple services if the underlying technology
 allows it. For example it would be possible to connect to a WiFi network
 and a Bluetooth service at the same time. Trying to connect to a second WiFi
 network with the same WiFi hardware would result in an automatic disconnect
@@ -393,7 +393,7 @@ can fail for one reason or another. Application should be able to handle
 such errors and will also be notified of changes via signals.
 
 In future versions Connection Manager will interact with an agent to confirm
-certain transaction with the user. This functionality is currently not
+certain transactions with the user. This functionality is currently not
 implemented.
 
 To monitor the current status of a service the state property can be used. It
@@ -403,6 +403,6 @@ gives detailed information about the current progress.
 
 	print properties["State"]
 
-All state changes are also send via the PropertyChanged signal on the
+All state changes are also sent via the PropertyChanged signal on the
 service interface. This allows asynchronous monitoring without having to poll
 Connection Manager for changes.
diff --git a/doc/plugin-api.txt b/doc/plugin-api.txt
index 696e2c16..b39c043a 100644
--- a/doc/plugin-api.txt
+++ b/doc/plugin-api.txt
@@ -7,7 +7,7 @@ Plugin basics
 
 The Connection Manager supports plugins for various actions. The basic plugin
 contains of plugin description via CONNMAN_PLUGIN_DEFINE and also init/exit
-callbacks definied through that description.
+callbacks defined through that description.
 
 #include <connman/plugin.h>
 
diff --git a/doc/service-api.txt b/doc/service-api.txt
index d3097364..aaddbfbb 100644
--- a/doc/service-api.txt
+++ b/doc/service-api.txt
@@ -132,7 +132,7 @@ Properties	string State [readonly]
 			The service error status details.
 
 			When error occur during connection or disconnection
-			the detailed information are represented in this
+			the detailed information is represented in this
 			property to help the user interface to present the
 			user with alternate options.
 
@@ -198,7 +198,7 @@ Properties	string State [readonly]
 			If the service type is WiFi, then this property
 			can be used to store a passphrase.
 
-			No PropertyChanged signals will be send for this
+			No PropertyChanged signals will be sent for this
 			property. The PassphraseRequired property should
 			be monitored instead.