[MANUAL] English:

- manual fixes

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

documentation/manual/en/module_specs/Zend_Service_Flickr.xml

@@ -136,8 +136,9 @@ echo "<a href=\"$image->clickUri\">Click for Image</a>\n";
             <para>Represents a set of Results from a Flickr search.</para>
             <note>
                 <para>
-                    Implements the <code>SeekableIterator</code> interface for easy iteration (e.g., using
-                    <code>foreach</code>), as well as direct access to a specific result using <methodname>seek()</methodname>.
+                    Implements the <classname>SeekableIterator</classname> interface for easy
+                    iteration (e.g., using <methodname>foreach()</methodname>), as well as direct
+                    access to a specific result using <methodname>seek()</methodname>.
                 </para>
             </note>
             <sect4 id="zend.service.flickr.classes.resultset.properties">

documentation/manual/en/module_specs/Zend_Service_Yahoo.xml

@@ -151,10 +151,11 @@ foreach ($results as $result) {
     <sect2 id="zend.service.yahoo.classes">
         <title>Zend_Service_Yahoo Classes</title>
         <para>
-            The following classes are all returned by the various Yahoo! searches. Each search type returns a
-            type-specific result set which can be easily iterated, with each result being contained in a type result
-            object. All result set classes implement the <code>SeekableIterator</code> interface, allowing for easy
-            iteration and seeking to a specific result.
+            The following classes are all returned by the various Yahoo! searches. Each search type
+            returns a type-specific result set which can be easily iterated, with each result being
+            contained in a type result object. All result set classes implement the
+            <classname>SeekableIterator</classname> interface, allowing for easy iteration and
+            seeking to a specific result.
             <itemizedlist>
                 <listitem><para><link linkend="zend.service.yahoo.classes.resultset"><classname>Zend_Service_Yahoo_ResultSet</classname></link></para></listitem>
                 <listitem><para><link linkend="zend.service.yahoo.classes.webresultset"><classname>Zend_Service_Yahoo_WebResultSet</classname></link></para></listitem>

documentation/manual/en/module_specs/Zend_Test-PHPUnit-Bootstrapping.xml

@@ -7,7 +7,7 @@
         As noted in the <link linkend="zend.test.phpunit.loginexample">Login
             example</link>, all <acronym>MVC</acronym> test cases should extend
         <classname>Zend_Test_PHPUnit_ControllerTestCase</classname>. This class in turn
-        extends <code>PHPUnit_Framework_TestCase</code>, and gives you all the
+        extends <classname>PHPUnit_Framework_TestCase</classname>, and gives you all the
         structure and assertions you'd expect from PHPUnit -- as well as some
         scaffolding and assertions specific to Zend Framework's <acronym>MVC</acronym>
         implementation.
@@ -107,7 +107,7 @@ class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
         environment to a clean request state, resetting any plugins and
         helpers, resetting the front controller instance, and creating new
         request and response objects. Once this is done, it will then either
-        <code>include</code> the file specified in <varname>$bootstrap</varname>, or
+        <methodname>include()</methodname> the file specified in <varname>$bootstrap</varname>, or
         call the callback specified.
     </para>
 

documentation/manual/en/module_specs/Zend_Test-PHPUnit.xml

@@ -15,7 +15,7 @@
 
         <para>
             The following is a simple test case for a
-            <code>UserController</code> to verify several things:
+            <classname>UserController</classname> to verify several things:
         </para>
 
         <itemizedlist>

documentation/manual/en/module_specs/Zend_TimeSync-Working.xml

@@ -34,13 +34,14 @@ print $server->getDate()->getIso();
 ]]></programlisting>
 
         <para>
-            So what is happening in the background of <classname>Zend_TimeSync</classname>? First the syntax of the
-            time server is checked. In our example, '<code>0.pool.ntp.org</code>' is checked and
-            recognised as a possible address for a time server. Then when calling
-            <methodname>getDate()</methodname> the actual set time server is requested and it will return its own
-            time. <classname>Zend_TimeSync</classname> then calculates the difference to the actual time of the
-            server running the script and returns a <classname>Zend_Date</classname> object with the
-            correct time.
+            So what is happening in the background of <classname>Zend_TimeSync</classname>? First
+            the syntax of the time server is checked. In our example,
+            '<emphasis>0.pool.ntp.org</emphasis>' is checked and recognised as a possible address
+            for a time server. Then when calling <methodname>getDate()</methodname> the actual set
+            time server is requested and it will return its own time.
+            <classname>Zend_TimeSync</classname> then calculates the difference to the actual time
+            of the server running the script and returns a <classname>Zend_Date</classname> object
+            with the correct time.
         </para>
 
         <para>

documentation/manual/en/module_specs/Zend_TimeSync.xml

@@ -101,7 +101,7 @@
         <title>What is NTP ?</title>
 
         <para>
-            The <code>Network Time Protocol</code> (<emphasis>NTP</emphasis>) is a protocol
+            The Network Time Protocol (<emphasis>NTP</emphasis>) is a protocol
             for synchronizing multiple systems' clocks over packet-switched, variable-latency data
             networks. NTP uses UDP port 123 as its transport layer. See the
             <ulink url="http://en.wikipedia.org/wiki/Network_Time_Protocol">wikipedia article</ulink>
@@ -115,7 +115,7 @@
         <title>What is SNTP?</title>
 
         <para>
-            The <code>Simple Network Time Protocol</code> (<emphasis>SNTP</emphasis>) is a
+            The Simple Network Time Protocol (<emphasis>SNTP</emphasis>) is a
             protocol synchronizing multiple systems' clocks over packet-switched, variable-latency
             data networks. SNTP uses UDP port 37 as its transport layer. It is closely related to the
             Network Time Protocol, but simpler.
@@ -188,7 +188,7 @@
         <para>
             See <ulink url="http://www.pool.ntp.org">pool.ntp.org</ulink> to find your nearest
             server pool. For example, if your server is located within Germany you can connect to
-            <code>0.europe.pool.ntp.org</code>.
+            <emphasis>0.europe.pool.ntp.org</emphasis>.
         </para>
 
     </sect2>

documentation/manual/en/module_specs/Zend_Tool_Framework-WritingProviders.xml

@@ -137,8 +137,9 @@ Hello from my provider!
         <para>
             As discussed in the architecture section Zend Tool allows to hook different clients for
             using your Zend Tool providers. To keep compliant with different clients you should
-            use the response object to return messages from your providers instead of using <code>echo</code>
-            or a similiar output mechanism. Rewritting our hello provider with this knowledge it looks like:
+            use the response object to return messages from your providers instead of using
+            <methodname>echo()</methodname> or a similiar output mechanism. Rewritting our hello
+            provider with this knowledge it looks like:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -342,9 +343,10 @@ class My_Component_HelloProvider
 ]]></programlisting>
 
             <para>
-                The returned configuration is of the type <classname>Zend_Tool_Framework_Client_Config</classname>
-                but internally the <code>__get</code> and <code>__set</code> magic methods proxy to a
-                <classname>Zend_Config</classname> of the given configuration type.
+                The returned configuration is of the type
+                <classname>Zend_Tool_Framework_Client_Config</classname> but internally the
+                <methodname>__get()</methodname> and <methodname>__set()</methodname> magic methods
+                proxy to a <classname>Zend_Config</classname> of the given configuration type.
             </para>
 
             <para>

documentation/manual/en/module_specs/Zend_Validate-Hostname.xml

@@ -31,7 +31,7 @@ if ($validator->isValid($hostname)) {
 ]]></programlisting>
 
         This will match the hostname <varname>$hostname</varname> and on failure populate
-        <code>$validator->getMessages()</code> with useful error messages.
+        <methodname>getMessages()</methodname> with useful error messages.
 
     </para>
 
@@ -93,8 +93,8 @@ $validator = new Zend_Validate_Hostname(Zend_Validate_Hostname::ALLOW_DNS |
     <para>
         To match an IDN domain it's as simple as just using the standard Hostname validator since
         IDN matching is enabled by default. If you wish to disable IDN validation this can be done
-        by either passing a parameter to the <classname>Zend_Validate_Hostname</classname> constructor or via the
-        <code>$validator->setValidateIdn()</code> method.
+        by either passing a parameter to the <classname>Zend_Validate_Hostname</classname>
+        constructor or via the <methodname>setValidateIdn()</methodname> method.
     </para>
 
     <para>
@@ -112,7 +112,7 @@ $validator =
 ]]></programlisting>
 
         Alternatively you can either pass TRUE or FALSE to
-        <code>$validator->setValidateIdn()</code> to enable or disable IDN validation.
+        <methodname>setValidateIdn()</methodname> to enable or disable IDN validation.
         If you are trying to match an IDN hostname which isn't currently supported it is likely
         it will fail validation if it has any international characters in it. Where a ccTLD file
         doesn't exist in Zend/Validate/Hostname specifying the additional characters a normal
@@ -145,7 +145,7 @@ $validator =
 ]]></programlisting>
 
         Alternatively you can either pass TRUE or FALSE to
-        <code>$validator->setValidateTld()</code> to enable or disable TLD validation.
+        <methodname>setValidateTld()</methodname> to enable or disable TLD validation.
     </para>
 
     <para>

documentation/manual/en/module_specs/Zend_XmlRpc_Client.xml

@@ -107,9 +107,9 @@ $result = $client->call('test.sayHello', array($arg1, $arg2));
             <para>
                 Parameters may be passed to <methodname>call()</methodname> as native
                 <acronym>PHP</acronym> variables, meaning as a <type>String</type>,
-                <code>integer</code>, <code>float</code>,
+                <type>Integer</type>, <type>Float</type>,
                 <type>Boolean</type>, <type>Array</type>, or an
-                <code>object</code>. In this case, each <acronym>PHP</acronym> native type will
+                <type>Object</type>. In this case, each <acronym>PHP</acronym> native type will
                 be auto-detected and converted into one of the <acronym>XML-RPC</acronym> types
                 according to this table:
             </para>
@@ -172,14 +172,14 @@ $result = $client->call('test.sayHello', array($arg1, $arg2));
                     as it could represent either an array or a struct.
                     <classname>Zend_XmlRpc_Client</classname> detects such conditions and
                     makes a request to the server's
-                    <code>system.methodSignature</code> method to determine the
+                    <command>system.methodSignature</command> method to determine the
                     appropriate <acronym>XML-RPC</acronym> type to cast to.
                 </para>
 
                 <para>
                     However, this in itself can lead to issues. First off,
                     servers that do not support
-                    <code>system.methodSignature</code> will log failed
+                    <command>system.methodSignature</command> will log failed
                     requests, and <classname>Zend_XmlRpc_Client</classname> will resort to
                     casting the value to an <acronym>XML-RPC</acronym> array type. Additionally,
                     this means that any call with array arguments will result in
@@ -217,8 +217,8 @@ $result = $client->call('foo.bar', array(array()));
                     </listitem>
                     <listitem>
                         <para>
-                            When the procedure requires <code>base64</code> or
-                            <code>dateTime.iso8601</code> type (which doesn't exists as a
+                            When the procedure requires <property>base64</property> or
+                            <property>dateTime.iso8601</property> type (which doesn't exists as a
                             <acronym>PHP</acronym> native type)
                         </para>
                     </listitem>
@@ -351,7 +351,7 @@ $result = $client->call('foo.bar', array(array()));
                         <acronym>PHP</acronym> casting. For example, if a string is given as a
                         value to the <classname>Zend_XmlRpc_Value_Integer</classname>
                         object, it will be converted using
-                        <code>(int)$value</code>.
+                        <command>(int)$value</command>.
                     </para>
                 </note>
             </para>
@@ -391,7 +391,7 @@ $hello = $server->test->sayHello(1, 2);  // test.Hello(1, 2) returns "hello"
             The <methodname>getProxy()</methodname> method receives an optional argument
             specifying which namespace of the remote server to proxy. If it
             does not receive a namespace, the default namespace will be
-            proxied. In the next example, the <code>test</code> namespace
+            proxied. In the next example, the 'test' namespace
             will be proxied:
         </para>
 
@@ -410,8 +410,8 @@ $hello = $test->sayHello(1, 2);         // test.Hello(1,2) returns "hello"
             If the remote server supports nested namespaces of any depth,
             these can also be used through the server proxy. For example, if
             the server in the example above had a method
-            <code>test.foo.bar()</code>, it could be called as
-            <code>$test->foo->bar()</code>.
+            <command>test.foo.bar()</command>, it could be called as
+            <command>$test->foo->bar()</command>.
         </para>
     </sect2>
 
@@ -429,7 +429,7 @@ $hello = $test->sayHello(1, 2);         // test.Hello(1,2) returns "hello"
 
             <para>
                 If any <acronym>HTTP</acronym> error occurs, such as the remote
-                <acronym>HTTP</acronym> server returns a <code>404 Not Found</code>, a
+                <acronym>HTTP</acronym> server returns a <emphasis>404 Not Found</emphasis>, a
                 <classname>Zend_XmlRpc_Client_HttpException</classname> will be thrown.
             </para>
 
@@ -522,7 +522,7 @@ try {
         <title>Server Introspection</title>
         <para>
             Some <acronym>XML-RPC</acronym> servers support the de facto introspection methods
-            under the <acronym>XML-RPC</acronym> <code>system.</code> namespace.
+            under the <acronym>XML-RPC</acronym> <emphasis>system.</emphasis> namespace.
             <classname>Zend_XmlRpc_Client</classname> provides special support for servers with
             these capabilities.
         </para>