Various typos and link cleanup related to sharding/replication work

Author: Ed Costello

source/applications/replication.txt

@@ -25,7 +25,7 @@ Write concern issues the :dbcommand:`getLastError` command after write
 operations to return an object with error information or confirmation
 that there are no errors.
 
-The after the  :doc:`driver write concern change </release-notes/drivers-write-concern>` all officially
+After the :doc:`driver write concern change </release-notes/drivers-write-concern>` all officially
 supported MongoDB drivers enable write concern by default.
 
 When enabled by default, write concern confirms write operations only on the primary.
@@ -88,6 +88,11 @@ The :data:`~local.system.replset.settings.getLastErrorDefaults` setting affects
    <replica-set-failover>`. Always ensure that your operations have
    specified the required write concern for your application.
 
+.. seealso::
+
+      * :ref:`write-operations-write-concern`
+      * :ref:`connections-write-concern`
+
 .. index:: read preference
 .. index:: slaveOk
 
@@ -206,10 +211,10 @@ behavior <replica-set-read-preference-behavior>`. See also the
    This is the default. If the primary is unavailable,
    read operations produce an error or throw an exception.
 
-   :readmode:`primary` read preference modes are not compatible with
-   read preferences mode that use :ref:`tag sets
+   The :readmode:`primary` read preference mode is not compatible with
+   read preference modes that use :ref:`tag sets
    <replica-set-read-preference-tag-sets>`. If you specify a tag set
-   with :readmode:`primary`, the driver produces an error.
+   with :readmode:`primary`, the driver will produce an error.
 
 .. readmode:: primaryPreferred
 
@@ -387,7 +392,7 @@ All interfaces use the same :ref:`member selection logic
 member to which to direct read operations, basing the choice on read
 preference mode and tag sets.
 
-For more information on how read preferences :ref:`modes
+For more information on how read preference :ref:`modes
 <replica-set-read-preference-modes>` interact with tag sets, see the
 documentation for each read preference mode.
 
@@ -422,7 +427,7 @@ As a result, MongoDB drivers and :program:`mongos`:
   connection is *pinned* to this :program:`mongod`.
 
 - Attempt to reconnect to a new member, obeying existing :ref:`read
-  preference modes <replica-set-read-preference-modes>`, if connection
+  preference modes <replica-set-read-preference-modes>`, if the connection
   to :program:`mongod` is lost.
 
   Reconnections are transparent to the application itself. If
@@ -498,8 +503,8 @@ Member Selection
 ````````````````
 
 Clients, by way of their drivers, and :program:`mongos` instances for
-sharded clusters periodically update their view of the set's state: which
-members are up or down, which is primary, and the latency to each
+sharded clusters periodically update their view of the replica set's state:
+which members are up or down, which member is primary, and the latency to each
 :program:`mongod` instance.
 
 For any operation that targets a member *other* than the
@@ -605,10 +610,10 @@ preferences; clients send all commands to shards' primaries. See
 Uses for non-Primary Read Preferences
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-You must exercise care when specifying read preference: modes other
+You must exercise care when specifying read preferences: modes other
 than :readmode:`primary` can *and will* return stale data. These
 secondary queries will not
-include most recent write operations to the replica set's
+include the most recent write operations to the replica set's
 :term:`primary`. Nevertheless, there are several common use cases for
 using non-:readmode:`primary` read preference modes:
 

source/core/write-operations.txt

@@ -89,15 +89,15 @@ Consider the following levels of conceptual write concern:
   Before the releases outlined in :ref:`driver-write-concern-change`,
   this was the default write concern.
 
-.. _write-concern-acknowledged: 
+.. _write-concern-acknowledged:
 
 - receipt *acknowledged*: The :program:`mongod` will confirm the
   receipt of the write operation, allowing the client to catch
   network, duplicate key, and other exceptions. After the releases
   outlined in :ref:`driver-write-concern-change`, this is the default
   write concern. [#default-write-concern]_
 
-.. _write-concern-replica-journaled: 
+.. _write-concern-replica-journaled:
 
 - *journaled*: The :program:`mongod` will confirm the write
   operation only after it has written the operation to the
@@ -111,7 +111,7 @@ Consider the following levels of conceptual write concern:
   is not fully durable. Require *journaled* as part of the write
   concern to provide this durability guarantee.
 
-.. _write-concern-replica-acknowledged: 
+.. _write-concern-replica-acknowledged:
 
 :term:`Replica sets <replica set>` present an additional layer of
 consideration for write concern. Basic write concern level affect the
@@ -132,8 +132,8 @@ of a replica set. See the :ref:`Write Concern for Replica Sets
 .. [#default-write-concern] The default write concern is to call
    :dbcommand:`getLastError` with no arguments. For replica sets, you
    can define the default write concern settings in the
-   :data:`getLastErrorDefaults <settings.getLastErrorDefaults>`. If
-   :data:`getLastErrorDefaults <settings.getLastErrorDefaults>` does
+   :data:`~local.system.replset.settings.getLastErrorDefaults`
+   If :data:`~local.system.replset.settings.getLastErrorDefaults` does
    not define a default write concern setting,
    :dbcommand:`getLastError` defaults to basic receipt acknowledgment.
 
@@ -155,8 +155,9 @@ document's ``err`` field contains either:
 
 The definition of a "successful write" depends on the arguments
 specified to :dbcommand:`getLastError`, or in replica sets, the
-configuration of :data:`getLastErrorDefaults
-<settings.getLastErrorDefaults>`. When deciding the level of write
+configuration of
+:data:`~local.system.replset.settings.getLastErrorDefaults`.
+When deciding the level of write
 concern for your application, become familiar with the
 :ref:`write-concern-considerations`.
 
@@ -365,15 +366,15 @@ they do, adds a :data:`~collStats.paddingFactor` so that the documents have room
 to grow on subsequent writes. The :data:`~collStats.paddingFactor` indicates the
 padding for new inserts and moves.
 
-.. versionadded:: 2.2 
+.. versionadded:: 2.2
    You can use the :dbcommand:`collMod` command
    with the :collflag:`usePowerOf2Sizes` flag so that MongoDB
    allocates document space in sizes that are powers of 2. This helps
    ensure that MongoDB can efficiently reuse the space freed as a
    result of deletions or document relocations. As with all padding,
    using document space allocations with power of 2 sizes minimizes,
    but does not eliminate, document movements.
-   
+
 To check the current :data:`~collStats.paddingFactor` on a collection, you can
 run the :dbcommand:`db.collection.stats()` command in the
 :program:`mongo` shell, as in the following example:
@@ -389,7 +390,7 @@ example:
 
 .. code-block:: none
 
-   padding size = (paddingFactor - 1) * <document size>. 
+   padding size = (paddingFactor - 1) * <document size>.
 
 For example, a :data:`~collStats.paddingFactor` of ``1.0`` specifies no padding
 whereas a paddingFactor of ``1.5`` specifies a padding size of ``0.5`` or 50
@@ -408,10 +409,10 @@ until you perform a :dbcommand:`compact` or a
 
 .. note::
 
-   The following operations remove padding: 
-   
+   The following operations remove padding:
+
    - :dbcommand:`compact`,
-   - :dbcommand:`repairDatabase`, and 
+   - :dbcommand:`repairDatabase`, and
    - initial replica sync operations.
 
    However, with the :dbcommand:`compact` command, you can run the
@@ -437,8 +438,8 @@ until you perform a :dbcommand:`compact` or a
 .. seealso::
 
    - :ref:`faq-developers-manual-padding`
-   
-   - `Fast Updates with MongoDB with in-place Updates <http://blog.mongodb.org/post/248614779/fast-updates-with-mongodb-update-in-place>`_ (blog post) 
+
+   - `Fast Updates with MongoDB with in-place Updates <http://blog.mongodb.org/post/248614779/fast-updates-with-mongodb-update-in-place>`_ (blog post)
 
 Architecture
 ------------

source/reference/connection-string.txt

@@ -208,13 +208,15 @@ connecting to the MongoDB deployment.
    connection to become available. For default values, see the
    :doc:`/applications/drivers` documentation.
 
+.. _connections-write-concern:
+
 Write Concern Options
 ~~~~~~~~~~~~~~~~~~~~~
 
 :ref:`Write concern <write-concern>` describes the kind of assurances
-:that the program:`mongod` and the driver provide to the application
-:regarding the success and durability of the write operation. For a
-:full explanation of write concern and write operations in general see
+that the program:`mongod` and the driver provide to the application
+regarding the success and durability of the write operation. For a
+full explanation of write concern and write operations in general see
 the: :doc:`/core/write-operations`:
 
 .. data:: uri.w
@@ -243,7 +245,7 @@ the: :doc:`/core/write-operations`:
       Provides basic acknowledgment of write operations.
 
       By specifying ``1``, you require that a standalone
-      :program:`mongod` instance, or a the primary for :term:`replica
+      :program:`mongod` instance, or the primary for :term:`replica
       sets <replica set>`, acknowledge all write operations. For drivers released
       after the :doc:`default write concern change
       </release-notes/drivers-write-concern>`, this is the default

source/release-notes/drivers-write-concern.txt

@@ -44,8 +44,9 @@ drivers:
    :dbcommand:`getLastError` without arguments, which is logically
    equivalent to the ``w: 1`` option; however, this operation allows
    :term:`replica set` users to override the default write concern
-   with the :data:`getLastErrorDefaults
-   <settings.getLastErrorDefaults>` setting in the
+   with the
+   :data:`getLastErrorDefaults <~local.system.replset.settings.getLastErrorDefaults>`
+   setting in the
    :doc:`/reference/replica-configuration`.
 
 .. _write-concern-change-releases: