Index: openacs-4/packages/acs-core-docs/www/style-guide.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/style-guide.html,v
diff -u -r1.28.2.10 -r1.28.2.11
--- openacs-4/packages/acs-core-docs/www/style-guide.html	21 Jun 2016 07:44:36 -0000	1.28.2.10
+++ openacs-4/packages/acs-core-docs/www/style-guide.html	23 Jun 2016 08:32:46 -0000	1.28.2.11
@@ -15,7 +15,7 @@
       procedures, about 2,000 functional pages, and about 3,200 tcl
       procedures.
     </p><p>
-      When confronted by this much complexity it's important to be
+      When confronted by this much complexity it&#39;s important to be
       able to make sense of it without having to wade through it all.
       Things should be coherent, things should be named predictably
       and behave like you would expect, and your guess about what
@@ -35,7 +35,7 @@
             scripts and tcl library files must be named properly to be
             used), while some are suggestions (the
             <span class="emphasis"><em>object-verb</em></span> naming convention) which
-            if ignored won't break anything, but if you follow the
+            if ignored won&#39;t break anything, but if you follow the
             rules people will be able to understand your package much
             more easily.
           </p></li><li class="listitem"><p><b>Be literate in your programming. </b>
@@ -59,16 +59,16 @@
           </p></li><li class="listitem"><p><b>Follow the code formatting guidelines. </b>
             The code base is very large and if things are formatted
             consistently it is easier to read.  Also, if it conforms
-            to the standard it won't be reformatted (which can mask
+            to the standard it won&#39;t be reformatted (which can mask
             the change history and making tracking down bugs much
             harder).  Using spaces rather than tabs makes patches
             easier to read and manage and does not force other
             programmers to decipher what tab settings you had in place
             in your editor.
           </p></li><li class="listitem"><p><b>Use the standard APIs. </b>
-            Don't reinvent the wheel.  Prefer extending an existing
+            Don&#39;t reinvent the wheel.  Prefer extending an existing
             core API to creating your own.  If something in the core
-            does not meet your particular needs it probably won't meet
+            does not meet your particular needs it probably won&#39;t meet
             others as well and fleshing out the core API's makes the
             toolkit more useful for everyone and more easily extended.
           </p></li><li class="listitem"><p><b>Make sure your datamodel create/drop scripts work. </b>
@@ -83,7 +83,7 @@
             patch and bug numbers in your commit messages.
           </p><p>
           Create bug tracker tickets for things you are going to work
-          on yourself (just in case you don't get to it and to act as
+          on yourself (just in case you don&#39;t get to it and to act as
           a pointer for others who might encounter the same problem).
         </p></li><li class="listitem"><p><b>Solicit code reviews. </b>
             Ask others to look over your code and provide feedback and do