[DOCUMENTATION] English:

- manual fixes

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@16565 44c647ce-9c0f-0410-b52a-842ac1e357ba

documentation/manual/en/ref/performance-database.xml

@@ -5,7 +5,8 @@
 
     <para>
         <classname>Zend_Db</classname> is a database abstraction layer, and is intended to
-        provide a common API for SQL operations. <classname>Zend_Db_Table</classname> is a
+        provide a common <acronym>API</acronym> for <acronym>SQL</acronym> operations.
+        <classname>Zend_Db_Table</classname> is a
         Table Data Gateway, intended to abstract common table-level database
         operations. Due to their abstract nature and the "magic" they do under
         the hood to perform their operations, they can sometimes introduce
@@ -73,22 +74,23 @@
             <title>Write your own tuned SQL</title>
 
             <para>
-                The only real answer is to write your own SQL;
+                The only real answer is to write your own <acronym>SQL</acronym>;
                 <classname>Zend_Db</classname> does not require the usage of
-                <classname>Zend_Db_Select</classname>, so providing your own, tuned SQL
-                select statements is a perfectly legitimate approach,
+                <classname>Zend_Db_Select</classname>, so providing your own, tuned
+                <acronym>SQL</acronym> select statements is a perfectly legitimate approach,
             </para>
             <para>
                 Run <constant>EXPLAIN</constant> on your queries, and test a variety of
                 approaches until you can reliably hit your indices in the most
-                performant way -- and then hardcode the SQL as a class property
+                performant way -- and then hardcode the <acronym>SQL</acronym> as a class property
                 or constant.
             </para>
 
             <para>
-                If the SQL requires variable arguments, provide placeholders in
-                the SQL, and utilize a combination of <methodname>vsprintf()</methodname> and
-                <methodname>array_walk()</methodname> to inject the values into the SQL:
+                If the <acronym>SQL</acronym> requires variable arguments, provide placeholders in
+                the <acronym>SQL</acronym>, and utilize a combination of
+                <methodname>vsprintf()</methodname> and <methodname>array_walk()</methodname> to
+                inject the values into the <acronym>SQL</acronym>:
             </para>
 
             <programlisting language="php"><![CDATA[

documentation/manual/en/ref/performance-localization.xml

@@ -27,7 +27,7 @@
 
             <para>
                 Zend Framework ships with a variety of translation adapters.
-                Fully half of them utilize an XML format, incurring memory and
+                Fully half of them utilize an <acronym>XML</acronym> format, incurring memory and
                 performance overhead. Fortunately, there are several adapters
                 that utilize other formats that can be parsed much more
                 quickly. In order of speed, from fastest to slowest, they are:
@@ -36,30 +36,31 @@
             <itemizedlist>
                 <listitem><para>
                     <emphasis>Array</emphasis>: this is the fastest, as it is,
-                    by definition, parsed into a native PHP format immediately
+                    by definition, parsed into a native <acronym>PHP</acronym> format immediately
                     on inclusion.
                 </para></listitem>
 
                 <listitem><para>
-                    <emphasis>CSV</emphasis>: uses <methodname>fgetcsv()</methodname> to
-                    parse a CSV file and transform it into a native PHP format.
+                    <emphasis><acronym>CSV</acronym></emphasis>: uses
+                    <methodname>fgetcsv()</methodname> to parse a CSV file and transform it into a
+                    native PHP format.
                 </para></listitem>
 
                 <listitem><para>
-                    <emphasis>INI</emphasis>: uses
-                    <methodname>parse_ini_file()</methodname> to parse an INI file and
-                    transform it into a native PHP format. This and the CSV
-                    adapter are roughly equivalent performance-wise.
+                    <emphasis><acronym>INI</acronym></emphasis>: uses
+                    <methodname>parse_ini_file()</methodname> to parse an <acronym>INI</acronym>
+                    file and transform it into a native <acronym>PHP</acronym> format. This and the
+                    <acronym>CSV</acronym> adapter are roughly equivalent performance-wise.
                 </para></listitem>
 
                 <listitem><para>
-                    <emphasis>Gettext</emphasis>: the Zend Framework gettext
-                    adapter does <emphasis>not</emphasis> use the gettext
+                    <emphasis>Gettext</emphasis>: The gettext adapter from Zend Framework
+                    does <emphasis>not</emphasis> use the gettext
                     extension as it is not thread safe and does not allow
                     specifying more than one locale per server. As a result, it
                     is slower than using the gettext extension directly, but,
                     because the gettext format is binary, it's faster to parse
-                    than XML.
+                    than <acronym>XML</acronym>.
                 </para></listitem>
             </itemizedlist>
 
@@ -74,7 +75,7 @@
         <title>How can I make translation and localization even faster?</title>
 
         <para>
-            Maybe, for business reasons, you're limited to an XML-based
+            Maybe, for business reasons, you're limited to an <acronym>XML</acronym>-based
             translation adapter. Or perhaps you'd like to speed things up even
             more. Or perhaps you want to make l10n operations faster. How can
             you do this?