[FAB-9523] Use American Spelling in Doc Consistently

Since labels in configuration file (configtx.yaml), standard
configuration directory (crypto-config/peerOrganizations) and many
identifiers in source codes use American spelling, it would be kind to a
reader if the document use American spelling consistently.

Change-Id: Ib59ee66453465abefb43ddbf8474e271258f0f3d
Signed-off-by: Yuta Namiki <y-namiki@ak.jp.nec.com>

Author: Yuta Namiki

docs/source/identity/identity.md

@@ -217,7 +217,7 @@ It's because CAs are so important that Fabric provides a built-in CA component t
 allow you to create CAs in the blockchain networks you form. This component -- known
 as **fabric-ca** is a private root CA provider capable of managing digital identities of
 Fabric participants that have the form of X.509 certificates.
-Because Fabric-CA is a custom CA targetting the Root CA needs of Fabric,
+Because Fabric-CA is a custom CA targeting the Root CA needs of Fabric,
 it is inherently not capable of providing SSL certificates for general/automatic use
 in browsers. However, because **some** CA must be used to manage identity
 (even in a test environment), fabric-ca can be used to provide and manage

docs/source/membership/membership.md

@@ -42,7 +42,7 @@ name the MSP after the organization, a convention you'll find adopted in most po
 configurations. For example, organization `ORG1` would have an MSP called `ORG1-MSP`.
 In some cases an organization may require multiple membership groups -- for example,
 where channels are used to perform very different business functions between
-organisations. In these cases it makes sense to have multiple MSPs and name them
+organizations. In these cases it makes sense to have multiple MSPs and name them
 accordingly, e.g., `ORG2-MSP-NATIONAL` and `ORG2-MSP-GOVERNMENT`, reflecting the
 different membership roots of trust within `ORG2` in the NATIONAL sales channel
 compared to the GOVERNMENT regulatory channel.

docs/source/msp-identity-validity-rules.rst

@@ -33,10 +33,10 @@ Notice that the validity of a certificate is also affected, in a similar
 way, if one or more organizational units are specified in the MSP configuration.
 Recall that an organizational unit is specified in an MSP configuration
 as a pair of two values, say (parent-cert, ou-string) representing the
-certificate authority that certifies that organisational unit, and the
-actual organisational unit identifier, respectively.
+certificate authority that certifies that organizational unit, and the
+actual organizational unit identifier, respectively.
 If a certificate C is signed by an iCA or rCA
-for which an organisational unit has been specified in the MSP configuration,
+for which an organizational unit has been specified in the MSP configuration,
 then C is considered valid if, among other requirements, it includes
 ou-string as part of its OU field.
 

docs/source/msp.rst

@@ -54,7 +54,7 @@ verification. These parameters are deduced by
   to request changes to this MSP configuration (e.g. root CAs, intermediate CAs)
 - A list of Organizational Units that valid members of this MSP should
   include in their X.509 certificate; this is an optional configuration
-  parameter, used when, e.g., multiple organisations leverage the same
+  parameter, used when, e.g., multiple organizations leverage the same
   root of trust, and intermediate CAs, and have reserved an OU field for
   their members
 - A list of certificate revocation lists (CRLs) each corresponding to
@@ -95,7 +95,7 @@ How to generate MSP certificates and their signing keys?
 --------------------------------------------------------
 
 To generate X.509 certificates to feed its MSP configuration, the application
-can use `Openssl <https://www.openssl.org/>`_. We emphasise that in Hyperledger
+can use `Openssl <https://www.openssl.org/>`_. We emphasize that in Hyperledger
 Fabric there is no support for certificates including RSA keys.
 
 Alternatively one can use ``cryptogen`` tool, whose operation is explained in
@@ -223,7 +223,7 @@ reject the system genesis block, if the latter includes two MSPs with the same
 identifier, and consequently the bootstrapping of the network would fail.
 
 For application channels, the verification components of only the MSPs that
-govern a channel need to reside in the channel's genesis block. We emphasise
+govern a channel need to reside in the channel's genesis block. We emphasize
 that it is **the responsibility of the application** to ensure that correct
 MSP configuration information is included in the genesis blocks (or the
 most recent configuration block) of a channel prior to instructing one or
@@ -261,7 +261,7 @@ considered:
   data with a set of peers that are members of the same subdivision, and NOT with
   the full set of providers constituting the actual organization.
 - **Multiple organizations using a single MSP.** This corresponds to a
-  case of a consortium of organisations that are governed by similar
+  case of a consortium of organizations that are governed by similar
   membership architecture. One needs to know here that peers would propagate
   organization-scoped messages to the peers that have an identity under the
   same MSP regardless of whether they belong to the same actual organization.
@@ -282,7 +282,7 @@ Two ways to handle this:
   a chaincode. A limitation of this approach is that gossip peers would
   consider peers with membership identities under their local MSP as
   members of the same organization, and would consequently gossip
-  with them organisation-scoped data (e.g. their status).
+  with them organization-scoped data (e.g. their status).
 - **Defining one MSP to represent each division**.  This would involve specifying for each
   division, a set of certificates for root CAs, intermediate CAs, and admin
   Certs, such that there is no overlapping certification path across MSPs.