[DOCUMENTATION] German:

- sync up to r17429

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

documentation/manual/de/module_specs/Zend_Db_Select.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17408 -->
+<!-- EN-Revision: 17409 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.db.select">
 
@@ -656,7 +656,7 @@ $select = $db->select()
                         der Zeilen im Ergebnissatz gleich dem Produkt der Zeilenanzahlen der beiden
                         Tabellen. Der Ergebnissatz kann mit Bedingungen einer WHERE Bedingung
                         gefiltert werden. Ein Cross Join ist ähnlich der alten
-                        <acronym>SQL</acronym>-89 JOIN Syntax.
+                        SQL-89 JOIN Syntax.
                     </para>
 
                     <para>

documentation/manual/de/module_specs/Zend_Json-Server.xml

@@ -1,8 +1,8 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17232 -->
+<!-- EN-Revision: 17410 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.json.server">
-    <title>Zend_Json_Server - JSON-RPC server</title>
+    <title>Zend_Json_Server - JSON-RPC Server</title>
 
     <para>
         <classname>Zend_Json_Server</classname> ist eine
@@ -19,8 +19,8 @@
     </para>
 
     <para>
-        <acronym>JSON</acronym>-RPC ist ein leichgewichtiges Remoce Procedure Call Protokoll das
-        <acronym>JSON</acronym> für seine Nachrichten verwendet. Diese <acronym>JSON</acronym>-RPC
+        JSON-RPC ist ein leichgewichtiges Remoce Procedure Call Protokoll das
+        <acronym>JSON</acronym> für seine Nachrichten verwendet. Diese JSON-RPC
         Implementierung folgt <acronym>PHP</acronym>'s <ulink
             url="http://us.php.net/manual/en/function.soap-soapserver-construct.php">SoapServer</ulink>
         <acronym>API</acronym>. Das bedeutet das in einer typischen Situation einfach folgendes
@@ -68,7 +68,7 @@
 
     <para>
         <classname>Zend_Json_Server</classname> hört aktuell nur auf POST Anfragen; glücklicherweise
-        bieten die meisten <acronym>JSON</acronym>-RPC Client Implementierungen die zur aktuell
+        bieten die meisten JSON-RPC Client Implementierungen die zur aktuell
         vorhanden sind nur POST Anfragen. Das macht es einfach den gleichen Endpunkt des Servers so
         zu verwenden das er beide Anfragen behandelt sowie die Service SMD liefert, wie im nächsten
         Beispiel gezeigt.
@@ -78,7 +78,7 @@
         <title>Zend_Json_Server Verwendung</title>
 
         <para>
-            Zuerst müssen wir eine Klasse definieren die wir über den <acronym>JSON</acronym>-RPC
+            Zuerst müssen wir eine Klasse definieren die wir über den JSON-RPC
             Server ausliefern wollen. Wir nennen die Klasse 'Calculator', und definieren die
             Methoden 'add', 'substract', 'multiple', und 'divide':
         </para>
@@ -163,7 +163,7 @@ $server->handle();
 
         <para>
             Trotzdem behandelt das noch immer nicht das Problem der Rückgabe eines SMD damit der
-            <acronym>JSON</acronym>-RPC Client die Methoden selbstständig erkennen kann. Das kann
+            JSON-RPC Client die Methoden selbstständig erkennen kann. Das kann
             getan werden indem die <acronym>HTTP</acronym> Anfragemethode erkannt wird, und
             anschließend einige Metadaten des Servers spezifiziert werden:
         </para>
@@ -190,7 +190,7 @@ $server->handle();
 ]]></programlisting>
 
         <para>
-            Wenn der <acronym>JSON</acronym>-RPC Server mit dem Dojo Toolkit verwendet wird muß auch
+            Wenn der JSON-RPC Server mit dem Dojo Toolkit verwendet wird muß auch
             ein spezielles Kompatibilitätsflag gesetzt werden um sicherzustellen das die zwei
             korrekt miteinander arbeiten:
         </para>
@@ -230,7 +230,7 @@ $server->handle();
 
             <para>
                 <classname>Zend_Json_Server</classname> ist die Kernklasse von
-                <acronym>JSON</acronym>-RPC; die bearbeitet alle Anfragen und gibt den Antwort
+                JSON-RPC; die bearbeitet alle Anfragen und gibt den Antwort
                 Payload zurück. Sie hat die folgenden Methoden:
             </para>
 
@@ -245,7 +245,7 @@ $server->handle();
                     <para>
                         <methodname>setClass($class)</methodname>: Spezifiziert eine Klasse oder ein
                         Objekt das dem Server hinzugefügt werden soll; alle öffentlichen Methoden
-                        dieses Elemente werden als <acronym>JSON</acronym>-RPC Methoden
+                        dieses Elemente werden als JSON-RPC Methoden
                         bekanntgegeben.
                     </para>
                 </listitem>
@@ -259,7 +259,7 @@ $server->handle();
                 <listitem>
                     <para>
                         <methodname>handle($request = false)</methodname>: Behandelt eine
-                        <acronym>JSON</acronym>-RPC Anfrage; optional kann ein
+                        JSON-RPC Anfrage; optional kann ein
                         <classname>Zend_Json_Server_Request</classname> Objekt für die Anpassung
                         übergeben werden (standardmäßig wird eines erstellt).
                     </para>
@@ -321,10 +321,10 @@ $server->handle();
             <title>Zend_Json_Server_Request</title>
 
             <para>
-                Die <acronym>JSON</acronym>-RPC Anfrageumgebung ist in ein
+                Die JSON-RPC Anfrageumgebung ist in ein
                 <classname>Zend_Json_Server_Request</classname> Objekt eingekapselt. Diese Objekt
-                erlaubt es die notwendigen Teile der <acronym>JSON</acronym>-RPC Anfrage zu setzen,
-                inklusive der Anfrage ID, Parametern, und der <acronym>JSON</acronym>-RPC
+                erlaubt es die notwendigen Teile der JSON-RPC Anfrage zu setzen,
+                inklusive der Anfrage ID, Parametern, und der JSON-RPC
                 spezifischen Version. Es hat die Möglichkeit sich selbst über
                 <acronym>JSON</acronym> zu laden oder ein Set von Optionen, und kann sich selbst
                 über die <methodname>toJson()</methodname> Methode als <acronym>JSON</acronym>
@@ -407,14 +407,14 @@ $server->handle();
                 <listitem>
                     <para>
                         <methodname>setVersion($version)</methodname>: Setzt die Version der
-                        <acronym>JSON</acronym>-RPC Spezifikation der die Anfrage entspricht. Kann
+                        JSON-RPC Spezifikation der die Anfrage entspricht. Kann
                         entweder '1.0' oder '2.0' sein.
                     </para>
                 </listitem>
                 <listitem>
                     <para>
                         <methodname>getVersion()</methodname>: Empfängt die Version der
-                        <acronym>JSON</acronym>-RPC Spezifikation die von der Anfrage verwendet
+                        JSON-RPC Spezifikation die von der Anfrage verwendet
                         wird.
                     </para>
                 </listitem>
@@ -445,10 +445,10 @@ $server->handle();
             <title>Zend_Json_Server_Response</title>
 
             <para>
-                Der <acronym>JSON</acronym>-RPC Antwort Payload ist in ein
+                Der JSON-RPC Antwort Payload ist in ein
                 <classname>Zend_Json_Server_Response</classname> Objekt gekapselt. Diese Objekt
                 erlaubt es den Rückgabewert der Anfrage zu setzen, ob die Antwort ein Fehler ist
-                oder nicht, den Anfrageindentifikator, die Version der <acronym>JSON</acronym>-RPC
+                oder nicht, den Anfrageindentifikator, die Version der JSON-RPC
                 Spezifikation der die Antwort entspricht, und optional die Servicemap.
             </para>
 
@@ -500,13 +500,13 @@ $server->handle();
                 <listitem>
                     <para>
                         <methodname>setVersion($version)</methodname>: Setzt die
-                        <acronym>JSON</acronym>-RPC Version der die Antwort entspricht.
+                        JSON-RPC Version der die Antwort entspricht.
                     </para>
                 </listitem>
                 <listitem>
                     <para>
                         <methodname>getVersion()</methodname>: Empfängt die
-                        <acronym>JSON</acronym>-RPC Version der die Antwort entspricht.
+                        JSON-RPC Version der die Antwort entspricht.
                     </para>
                 </listitem>
                 <listitem>
@@ -542,7 +542,7 @@ $server->handle();
             <title>Zend_Json_Server_Error</title>
 
             <para>
-                <acronym>JSON</acronym>-RPC hat ein spezielles Format für das Melden von
+                JSON-RPC hat ein spezielles Format für das Melden von
                 Fehlerzuständen. Alle Fehler müssen mindestens, eine Fehlermeldung und einen
                 Fehlercode anbieten; optional können Sie zusätzliche Daten, wie ein Backtrace,
                 anbieten.
@@ -551,7 +551,7 @@ $server->handle();
             <para>
                 Fehlercodes sind von jenen abgeleitet die vom
                 <ulink url="http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php">vom
-                    <acronym>XML</acronym>-RPC EPI Projekt</ulink> empfohlen werden.
+                    XML-RPC EPI Projekt</ulink> empfohlen werden.
                 <classname>Zend_Json_Server</classname> fügt den richtigen Code basierend auf der
                 Fehlerkondition zu. Für Anwendungsausnahmen wird der Code '-32000' verwendet.
             </para>
@@ -564,7 +564,7 @@ $server->handle();
                 <listitem>
                     <para>
                         <methodname>setCode($code)</methodname>: Setzt den Fehlercode: Wenn der Code
-                        nicht im akzeptierten Bereich der <acronym>XML</acronym>-RPC Fehlercodes
+                        nicht im akzeptierten Bereich der XML-RPC Fehlercodes
                         ist, wird -32000 hinzugefügt.
                     </para>
                 </listitem>
@@ -605,7 +605,7 @@ $server->handle();
                 <listitem>
                     <para>
                         <methodname>toJson()</methodname>: Weist den Fehler einer
-                        <acronym>JSON</acronym>-RPC Fehlerrepräsentation zu.
+                        JSON-RPC Fehlerrepräsentation zu.
                     </para>
                 </listitem>
             </itemizedlist>
@@ -620,7 +620,7 @@ $server->handle();
                 Zeit wie das geschrieben wurde, wurde die <ulink
                     url="http://groups.google.com/group/json-schema/web/service-mapping-description-proposal">Spezifikation</ulink>
                 noch nicht formell ratifiziert, aber Sie ist bereits im Dojo Toolkit in Verwendung
-                sowie in anderen <acronym>JSON</acronym>-RPC Kundenclients.
+                sowie in anderen JSON-RPC Kundenclients.
             </para>
 
             <para>
@@ -628,7 +628,7 @@ $server->handle();
                 (POST, GET, <acronym>TCP</acronym>/IP, usw.), den Envelopetyp der Anfrage
                 (normalerweise basierend auf dem Protokoll des Servers), die Ziel
                 <acronym>URL</acronym> des Service Providers, und eine Mappe der vorhandenen
-                Services. Im FAll von <acronym>JSON</acronym>-RPC ist die Service Mappe eine Liste
+                Services. Im Fall von JSON-RPC ist die Service Mappe eine Liste
                 von vorhandenen Methoden wobei jede Methode die vorhandenen Parameter und deren
                 Typen beschreibt, sowie den erwarteten Typ des Rückgabewerts.
             </para>
@@ -752,7 +752,7 @@ $server->handle();
                         <methodname>setDojoCompatible($flag)</methodname>: Setzt ein Flag das
                         indiziert ob das SMD mit dem Dojo Toolkit kompatibel ist oder nicht. Wenn es
                         true ist, dann ist das erzeugte <acronym>JSON</acronym> SMD so formatiert
-                        das es dem Format entspricht das Dojo's <acronym>JSON</acronym>-RPC Client
+                        das es dem Format entspricht das Dojo's JSON-RPC Client
                         erwartet.
                     </para>
                 </listitem>

documentation/manual/de/module_specs/Zend_Search_Lucene-IndexCreation.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17232 -->
+<!-- EN-Revision: 17409 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.search.lucene.index-creation">
     <title>Indexerstellung</title>
@@ -219,7 +219,7 @@ $index->optimize();
                 <code>$index->setMaxMergeDocs($maxMergeDocs)</code>.
             </para>
             <para>
-                Standardwert ist <acronym>PHP</acronym>_INT_MAX.
+                Standardwert ist PHP_INT_MAX.
             </para>
         </sect3>
 

documentation/manual/de/module_specs/Zend_Search_Lucene-Overview.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17175 -->
+<!-- EN-Revision: 17409 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.search.lucene.overview">
     <title>Überblick</title>
@@ -326,7 +326,7 @@ $index->addDocument($doc);
             Der dritte Parameter der <methodname>loadHTML()</methodname> und
             <methodname>loadHTMLFile()</methodname> Methoden spezifiziert optional die Kodierung des
             Quell- HTML Dokuments. Er wird verwendet wenn die Kodierung nicht durch die Angabe des
-            Content-type MetaTags <acronym>HTTP</acronym>-EQUIV spezifiziert ist.
+            Content-type MetaTags HTTP-EQUIV spezifiziert ist.
         </para>
 
         <para>

documentation/manual/de/module_specs/Zend_Search_Lucene-Searching.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17175 -->
+<!-- EN-Revision: 17409 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.search.lucene.searching">
     <title>Einen Index durchsuchen</title>
@@ -466,7 +466,7 @@ highlightedHTML = $query->highlightMatches($sourceHTML);
         <para>
             Der optionale zweite Parameter ist die standardmäßige Kodierung des HTML Dokuments.
             Er wird verwendet wenn die Kodierung nicht, durch die Verwendung des Content-type
-            MetaTags <acronym>HTTP</acronym>-EQUIV, spezifiziert ist.
+            MetaTags HTTP-EQUIV, spezifiziert ist.
         </para>
         <para>
             Der optionale dritte Parameter ist ein Highlighter Objekt welches das

documentation/manual/de/module_specs/Zend_Service_Akismet.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17232 -->
+<!-- EN-Revision: 17409 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.service.akismet">
     <title>Zend_Service_Akismet</title>
@@ -112,7 +112,7 @@ if ($akismet->verifyKey($apiKey) {
 
             <listitem>
                 <para>
-                    <code>referrer</code>, der Inhalt des <acronym>HTTP</acronym>_REFERER Headers
+                    <code>referrer</code>, der Inhalt des HTTP_REFERER Headers
                     zur Zeit der Übertragung. (Beachte die Schreibweise; sie folgt nicht dem Header
                     Namen)
                 </para>

documentation/manual/de/module_specs/Zend_View-Scripts.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17175 -->
+<!-- EN-Revision: 17409 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.view.scripts">
 
@@ -129,7 +129,7 @@ echo $view->render(...);
 
             <para>
                 Ein Viewskript kann verwendet werden, um ein separats Templateobjekt zu instanzieren
-                und anzupassen, z.B. für eine <acronym>PHP</acronym>LIB-style Template. Das
+                und anzupassen, z.B. für eine PHPLIB-style Template. Das
                 Viewskript für solch eine Aufgabe könnte so aussehen:
             </para>
             <programlisting language="php"><![CDATA[

documentation/manual/de/module_specs/Zend_XmlRpc_Server.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17175 -->
+<!-- EN-Revision: 17409 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.xmlrpc.server">
     <title>Zend_XmlRpc_Server</title>
@@ -9,7 +9,7 @@
 
         <para>
             <classname>Zend_XmlRpc_Server</classname> ist als vollständiger
-            <acronym>XML</acronym>-RPC Server geplant, der den <ulink
+            XML-RPC Server geplant, der den <ulink
                 url="http://www.xmlrpc.com/spec">Spezifikationen auf www.xmlrpc.com</ulink> folgt.
             Des Weiteren implementiert er die Methode system.multicall(), welche dem Entwickler
             erlaubt, mehrere Anfragen aufzureihen.
@@ -60,7 +60,7 @@ echo $server->handle();
             auszuführen. Es wird entweder ein <classname>Zend_XmlRpc_Response</classname>-
             oder ein <classname>Zend_XmlRpc_Server_Fault</classname>-Objekt zurückgegeben.
             Beide Objekte besitzen eine Methode <methodname>__toString()</methodname>, die eine
-            valide <acronym>XML</acronym>-RPC Antwort im <acronym>XML</acronym>-Format zurückgibt,
+            valide XML-RPC Antwort im <acronym>XML</acronym>-Format zurückgibt,
             die direkt ausgegeben werden kann.
         </para>
     </sect2>
@@ -69,18 +69,18 @@ echo $server->handle();
         <title>Konventionen</title>
         <para>
             <classname>Zend_XmlRpc_Server</classname> ermöglicht es dem Entwickler, Funktionen und
-            Methodenaufrufe als ausführbare <acronym>XML</acronym>-RPC Methoden anzufügen. Durch
+            Methodenaufrufe als ausführbare XML-RPC Methoden anzufügen. Durch
             <classname>Zend_Server_Reflection</classname> wird die Überwachung aller angefügten
             Methoden - durch Nutzung der DocBlocks der Methoden und Funktionen
             werden deren Hilfstexte und Signaturen ermittelt - ermöglicht.
         </para>
 
         <para>
-            <acronym>XML</acronym>-RPC Typen werden nicht zwingend 1:1 zu <acronym>PHP</acronym>
+            XML-RPC Typen werden nicht zwingend 1:1 zu <acronym>PHP</acronym>
             Typen konvertiert. Dennoch wird versucht, einen passenden Typ, anhand der in
             @param- und @return-Zeilen enthaltenen Werte, zu ermitteln. Einige
-            <acronym>XML</acronym>-RPC-Typen besitzen jedoch kein direktes Äquivalent und sollten
-            deshalb mittels <acronym>PHP</acronym>doc auf einen <acronym>XML</acronym>-RPC-Typen
+            XML-RPC-Typen besitzen jedoch kein direktes Äquivalent und sollten
+            deshalb mittels <acronym>PHP</acronym>doc auf einen XML-RPC-Typen
             hinweisen. Diese beinhalten:
         </para>
 
@@ -119,7 +119,7 @@ function myFunc($val1, $val2, $val3)
 
         <para>
             Es ist genauso gut möglich, mehrere Werte als Parameter oder für
-            die Rückgabe anzugeben; die <acronym>XML</acronym>-RPC Spezifikation schlägt sogar
+            die Rückgabe anzugeben; die XML-RPC Spezifikation schlägt sogar
             vor, dass system.methodeSignatur ein Array, das alle möglichen
             Methodensignaturen (d.h. jegliche Kombination aus Parametern und
             Rückgabewerten) enthält, zurückgibt. Um dies zu erreichen, kann
@@ -144,7 +144,7 @@ function myFunc($val1, $val2, $val3)
         <para>
             Dennoch eine Anmerkung: Das Erlaubung von vielen Signaturen kann
             zu Verwirrung für Entwickler führen, die diese Services nutzen;
-            man sollte einer <acronym>XML</acronym>-RPC Methode deshalb nur eine Signatur zuweisen.
+            man sollte einer XML-RPC Methode deshalb nur eine Signatur zuweisen.
         </para>
     </sect2>
 
@@ -152,11 +152,11 @@ function myFunc($val1, $val2, $val3)
         <title>Nutzen von Namensräumen</title>
 
         <para>
-            <acronym>XML</acronym>-RPC besitzt ein Konzept für Namensräume; Grundlegend erlaubt es
-            das Gruppieren von <acronym>XML</acronym>-RPC-Methoden durch Punkt-separierte
+            XML-RPC besitzt ein Konzept für Namensräume; Grundlegend erlaubt es
+            das Gruppieren von XML-RPC-Methoden durch Punkt-separierte
             Namensräume. Dies hilft, Namenkollisionen zwischen Methoden, die durch verschiedene
             Klassen offeriert werden, zu verhindern. Beispielsweise kann der
-            <acronym>XML</acronym>-RPC-Server mehrere Methoden im 'system'-Namensraum nutzen:
+            XML-RPC-Server mehrere Methoden im 'system'-Namensraum nutzen:
         </para>
 
         <itemizedlist>
@@ -192,13 +192,13 @@ $server->addFunction('somefunc', 'funcs');
             Die meiste Zeit wird man einfach den Standard-Anfragetyp
             <classname>Zend_XmlRpc_Request_Http</classname>, welcher im
             <classname>Zend_XmlRpc_Server</classname> enthalten ist, nutzen. Jedoch gibt es
-            gelegentlich Fälle, in denen <acronym>XML</acronym>-RPC über die Kommandozeile (CLI),
+            gelegentlich Fälle, in denen XML-RPC über die Kommandozeile (CLI),
             ein grafisches Benutzerinterface (GUI), eine andere Umgebung oder beim Protokollieren
             von ankommenden Anfragen erreichbar sein muss. Um dies zu bewerkstelligen, muss man ein
             eigenes Anfrage-Objekt kreieren, das <classname>Zend_XmlRpc_Request</classname>
             erweitert. Die wichtigste Sache, die man sich merken muss, ist sicherzustellen, dass die
             Methoden getMethod() und getParams() implementiert sind, so dass der
-            <acronym>XML</acronym>-RPC-Server Informationen erhält, die er für das Abfertigen einer
+            XML-RPC-Server Informationen erhält, die er für das Abfertigen einer
             Anfrage benötigt.
         </para>
     </sect2>
@@ -210,7 +210,7 @@ $server->addFunction('somefunc', 'funcs');
             Ähnlich wie bei den Anfrage-Objekten, kann der <classname>Zend_XmlRpc_Server</classname>
             auch eigene Antwortobjekte ausliefern; standardmäßig ist dies ein
             <classname>Zend_XmlRpc_Response_Http-Objekt</classname>, das einen passenden
-            Content-Type <acronym>HTTP</acronym>-Header sendet, der für <acronym>XML</acronym>-RPC
+            Content-Type <acronym>HTTP</acronym>-Header sendet, der für XML-RPC
             genutzt wird. Mögliche Nutzungen eines eigenen Objekts sind z.B. das Protokollieren von
             Antworten oder das Senden der Antworten zu STDOUT.
         </para>
@@ -227,7 +227,7 @@ $server->addFunction('somefunc', 'funcs');
 
         <para>
             <classname>Zend_XmlRpc_Server</classname> fängt die, durch eine ausgeführte Methode
-            erzeugten, Exceptions and generiert daraus einen <acronym>XML</acronym>-RPC-Fehler als
+            erzeugten, Exceptions and generiert daraus einen XML-RPC-Fehler als
             Antwort, wenn eine Exception gefangen wurde. Normalerweise werden die
             Exceptionnachrichten und -codes nicht in der Fehler-Antwort genutzt. Dies ist eine
             gewollte Entscheidung um den Code zu schützen; viele Exceptions entblößen mehr
@@ -264,7 +264,7 @@ Zend_XmlRpc_Server_Fault::attachFaultException('My_Project_Exception');
     <sect2 id="zend.xmlrpc.server.caching">
         <title>Zwischenspeichern von Serverdefinitionen zwischen den Anfragen</title>
         <para>
-            Das Hinzufügen einer Vielzahl von Klassen zu einer <acronym>XML</acronym>-RPC-Server
+            Das Hinzufügen einer Vielzahl von Klassen zu einer XML-RPC-Server
             Instanz kann zu einem großen Ressourcenverbrauch führen; jede Klasse muss via Reflection
             <acronym>API</acronym> (<classname>Zend_Server_Reflection</classname>) inspiziert
             werden, welche eine Liste von allen möglichen Signaturen, die der Server verwenden kann,
@@ -324,7 +324,7 @@ echo $server->handle();
 
             <para>
                 Folgendes Beispiel fügt eine Funktion als ausführbare
-                <acronym>XML</acronym>-RPC-Methode hinzu und verarbeitet eingehende Aufrufe.
+                XML-RPC-Methode hinzu und verarbeitet eingehende Aufrufe.
             </para>
 
             <programlisting language="php"><![CDATA[
@@ -350,7 +350,7 @@ echo $server->handle();
 
             <para>
                 Das nächste Beispiel illustriert, wie man die öffentlichen Methoden
-                eienr Klasse als ausführbare <acronym>XML</acronym>-RPC-Methoden hinzufügt.
+                eienr Klasse als ausführbare XML-RPC-Methoden hinzufügt.
             </para>
 
             <programlisting language="php"><![CDATA[

documentation/manual/de/ref/installation.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17325 -->
+<!-- EN-Revision: 17427 -->
 <!-- Reviewed: no -->
 <sect1 id="introduction.installation">
 

documentation/manual/de/ref/overview.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17325 -->
+<!-- EN-Revision: 17427 -->
 <!-- Reviewed: no -->
 <sect1 id="introduction.overview">
 

documentation/manual/de/ref/requirements.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 17327 -->
+<!-- EN-Revision: 17428 -->
 <!-- Reviewed: no -->
 <appendix id="requirements" xmlns:xi="http://www.w3.org/2001/XInclude">