Fixes issue 306: corrects capitalizations in index

source/sec_community_communication.ptx

@@ -222,7 +222,7 @@
                 <title>Wiki</title>
 
                 <definition xml:id="def-wiki">
-                  <idx>Wikis</idx>     
+                  <idx>wikis</idx>     
                     <statement>
                       <p>
                         Simply stated, a <term>wiki</term> is a hypertext publication where the pages are a user-editable, easy-to-use, asynchronous way of putting semi-permanent content on the web.

source/sec_dev_shell.ptx

@@ -49,7 +49,7 @@
   <li>
   <title>What is a <term>Command Line Interface (CLI)</term>?</title>
     <p>
-      <idx>Command Line Interface</idx>
+      <idx>command line interface</idx>
 <idx>CLI</idx>
       A <term>CLI</term> refers to any interface that works with text-based commands and text-based output. We will be using a <term>shell</term>, which is an example of a CLI.
     </p>

source/sec_docu_scope.ptx

@@ -90,7 +90,7 @@
 				<li>
 					<title> CHANGELOG</title>
 					<p>
-						<idx>CHANGELOG</idx>
+						<idx>changelog</idx>
 
 						Documenting changes to the project over time, the CHANGELOG usually includes a list of all releases and a summary of the changes that were made in each one.
 					</p>

source/sec_git_getting_started.ptx

@@ -43,7 +43,7 @@
 		</p>
 
 		<p>
-			<idx>Local VCS</idx>
+			<idx>local VCS</idx>
 			To deal with this issue, programmers long ago developed a more formal system of version control.  Local VCSs provide a more automatic, less error-prone and more structured way of keeping all the changes to files under revision control on the local computer.
 			Local VCSs typically operate quickly because they do not have to communicate with a remote server. With a local system, developers have access to the entire history of the codebase on their local machine, and they can work on the codebase offline, without an internet connection. 
 		</p>
@@ -61,7 +61,7 @@
 </p>
 
 		<p>
-		<idx>Centralized VCS</idx>
+		<idx>centralized VCS</idx>
 			Many developers need to collaborate with other developers on other systems. To deal with this, centralized VCSs were developed. These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients check out files from that central server. For many years, this was the standard for version control.
 		</p>
 
@@ -85,7 +85,7 @@
 
 </p>
 		<p>
-		<idx>Distributed VCS</idx>
+		<idx>distributed VCS</idx>
 			This is where distributed VCSs step in. In a distributed VCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.
 		</p>
 

source/sec_git_github.ptx

@@ -40,7 +40,7 @@
 
 <!-- div attr= class="paragraph"-->
 				<p>
-				<idx>Fork</idx>
+				<idx>fork</idx>
 					If you want to contribute to an existing project to which you don’t have write access (aka push access), you can <term>fork</term> the project. When you “fork” a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it.
 				</p><!--</div attr= class="paragraph">-->
 
@@ -807,7 +807,7 @@ How big are these slings and in particular, these arrows?</pre><!--</div attr= c
 
 <!-- div attr= class="paragraph"-->
 				<p>
-					<idx>README</idx>
+					<idx>readme</idx>
 					The <c>README</c> file explains your project, what it does, why it is useful, etc.
 					If GitHub detects a README file in your source, it will render it on the landing page of the project,
 					so this file is often the first item a visitor will see when visiting your repository.