DOCS-120 build fixes

Author: Sam Kleinman

source/administration/operational-segregation.txt

@@ -2,8 +2,6 @@
 Location and Operational Segregation in MongoDB Operations and Deployments
 ==========================================================================
 
-.. rename this file /administration/operational-segregation.txt
-
 .. default-domain:: mongodb
 
 Operational Overview
@@ -33,7 +31,7 @@ Specifically, with MongoDB, you can:
 - ensure that specific members of a replica set respond to queries.
 
 - ensure that specific ranges of your :term:`shard key` balance onto and
-  reside on specific :term:`shards`.
+  reside on specific :term:`shard`.
 
 - combine the above features in a single distributed deployment, on a
   per-operation (for read and write operations) and collection (for
@@ -65,19 +63,21 @@ documentation in the MongoDB Manual:
    Before adding operational segregation features to your application
    and MongoDB deployment, become familiar with all documentation of
    :doc:`replication </replication>` and :doc:`sharding </sharding>`,
-   particularly :doc:`/core/replication` and :doc:`/core/sharding`.
+   particularly :doc:`/core/replication` and :doc:`/core/sharded-clusters`.
+
+.. TODO uncomment this section when we can write content for it:
 
-Examples of Operational Segregation
------------------------------------
+   Examples of Operational Segregation
+   -----------------------------------
 
-Increase Data Locality in Geographically Distributed Cluster
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   Increase Data Locality in Geographically Distributed Cluster
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Functional Segregation for Reporting and Backups
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   Functional Segregation for Reporting and Backups
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Increase Read Locality for Distributed Applications
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   Increase Read Locality for Distributed Applications
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Ensure Geographical Redundancy for Write Operations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+   Ensure Geographical Redundancy for Write Operations
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

source/administration/tag-aware-sharding.txt

@@ -56,8 +56,8 @@ shard.
    - :term:`Shard key` values between ``100`` and ``200`` have tags to
      direct corresponding chunks on shards tagged ``NYC``.
 
-   - Shard Key values between ``200`` and
-   ``300`` have tags to direct corresponding chunks on shards tagged ``SFO``.
+   - Shard Key values between ``200`` and ``300`` have tags to direct
+     corresponding chunks on shards tagged ``SFO``.
 
    In this cluster, the balancer will migrate a chunk with shard key
    values ranging between ``150`` and ``220`` to a shard tagged

source/reference/replica-configuration.txt

@@ -562,7 +562,7 @@ replica set as follows in the :program:`mongo` shell:
    :data:`~local.system.replset.settings.getLastErrorModes` valuie to
    require two different values of both ``dc.va`` and ``dc.gto``:
 
-   .. code-block::
+   .. code-block:: javascript
 
       conf.settings = { getLastErrorModes: { MultipleDC : { "dc.va": 2, "dc.gto": 2}}
 
@@ -662,4 +662,3 @@ to at least one instance with an SSD.
 .. [#read-and-write-tags] Since read preferences and write concerns
    use the value of fields in tag sets differently, for larger
    deployments will have some redundancy.
-.