[MANUAL] German:

- sync up to r21828

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

documentation/manual/de/module_specs/Zend_Controller-Request.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 20765 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.controller.request">
     <title>Das Request Objekt</title>
@@ -187,7 +187,7 @@
                     die benötigt wird, nicht <varname>$_SERVER['REQUEST_URI']</varname>. Wenn so ein
                     Setup verwendet wird und man ungültige Routen erhält, sollte man stattdessen die
                     <classname>Zend_Controller_Request_Apache404</classname> Klasse statt der
-                    standard Http Klasse für das Anfrage Objekt verwenden:
+                    standard <acronym>HTTP</acronym> Klasse für das Anfrage Objekt verwenden:
                 </para>
 
                 <programlisting language="php"><![CDATA[

documentation/manual/de/module_specs/Zend_Feed_Pubsubhubbub.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21823 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.feed.pubsubhubbub.introduction">
     <title>Zend_Feed_Pubsubhubbub</title>
@@ -27,14 +27,14 @@
 
         <para>
             Pubsubhubbub hat Aufmerksamkeit erlangt weil es ein Pubsub Protokoll ist das einfach zu
-            implementieren ist und über HTTP arbeitet. Seine Philosophie ist es das traditionelle
-            Modell zu ersetzen indem Blog Feeds mit einem regulären Interfall abgefragt werden um
-            Aktualisierungen zu erkennen und zu empfangen. Abhängig von der Frequenz der Abfrage
-            kann es viel Zeit in Anspruch nehmen Aktualisierungen an interessierte Menschen bei
-            Sammelstellen bis zu Desktop Lesern, bekannt zu machen. Mit der Verwendung eines
-            Pubsub Systems werden Aktualisierungen nicht einfach von Abonnenten abgefragt sondern
-            an die Abonnenten geschickt, was jegliche Verzögerung ausschaltet. Aus diesem Grund
-            fungiert Pubsubhubbub als Teil von dem was als Echt-Zeit Web bekannt ist.
+            implementieren ist und über <acronym>HTTP</acronym> arbeitet. Seine Philosophie ist es
+            das traditionelle Modell zu ersetzen indem Blog Feeds mit einem regulären Interfall
+            abgefragt werden um Aktualisierungen zu erkennen und zu empfangen. Abhängig von der
+            Frequenz der Abfrage kann es viel Zeit in Anspruch nehmen Aktualisierungen an
+            interessierte Menschen bei Sammelstellen bis zu Desktop Lesern, bekannt zu machen. Mit
+            der Verwendung eines Pubsub Systems werden Aktualisierungen nicht einfach von Abonnenten
+            abgefragt sondern an die Abonnenten geschickt, was jegliche Verzögerung ausschaltet. Aus
+            diesem Grund fungiert Pubsubhubbub als Teil von dem was als Echt-Zeit Web bekannt ist.
         </para>
 
         <para>
@@ -111,11 +111,12 @@
             Sammlung, oder sogar ein Webservice mit einer öffentlichen Feed basierenden
             <acronym>API</acronym> sein. Damit diese Aktualisierungen zu den Abonnenten geschickt
             werden können, muss der Publizist alle seine unterstützten Hubs darüber informieren das
-            eine Aktualisierung stattgefunden hat, indem eine einfache HTTP POST Anfrage verwendet
-            wird, welche die URI oder das aktualisierte Thema enthält (z.B. den aktualisierten RSS
-            oder Atom Feed). Der Hub bestätigt den Empfang der Benachrichtigung, holt den
-            aktualisierten Feed, und leitet alle Aktualisierungen an alle Abonnenten weiter welche
-            sich bei diesem Hub für Aktualisierungen für den relevanten Feed angemeldet haben.
+            eine Aktualisierung stattgefunden hat, indem eine einfache <acronym>HTTP</acronym> POST
+            Anfrage verwendet wird, welche die URI oder das aktualisierte Thema enthält (z.B. den
+            aktualisierten RSS oder Atom Feed). Der Hub bestätigt den Empfang der Benachrichtigung,
+            holt den aktualisierten Feed, und leitet alle Aktualisierungen an alle Abonnenten weiter
+            welche sich bei diesem Hub für Aktualisierungen für den relevanten Feed angemeldet
+            haben.
         </para>
 
         <para>
@@ -139,10 +140,11 @@
             enthält eine Anzahl von Fehlern welche die URLs des Hubs enthalten, damit
             Benachrichtigungen stäter wieder ausgeführt oder protokolliert werden können wenn
             irgendeine Benachrichtigung fehlschlägt. Jedes resultierende Fehlerarray enthält auch
-            einen "response" Schlüssel welche das betreffende HTTP Antwortobjekt enthält. In Falle
-            irgendeines Fehlers wird empfohlen die Operation für den fehlgeschlagenen Hub Endpunkt
-            in Zukunft zumindest noch einmal zu versuchen. Das kann die Verwendung einer geplanten
-            Aufgabe für diesen Zweck oder einer Job Queue wenn solche extra Schritte optional sind.
+            einen "response" Schlüssel welche das betreffende <acronym>HTTP</acronym> Antwortobjekt
+            enthält. In Falle irgendeines Fehlers wird empfohlen die Operation für den
+            fehlgeschlagenen Hub Endpunkt in Zukunft zumindest noch einmal zu versuchen. Das kann
+            die Verwendung einer geplanten Aufgabe für diesen Zweck oder einer Job Queue wenn solche
+            extra Schritte optional sind.
         </para>
 
         <programlisting language="php"><![CDATA[

documentation/manual/de/module_specs/Zend_Gdata_AuthSub.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 20779 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.gdata.authsub">
     <title>Authentifizierung mit AuthSub</title>
@@ -66,15 +66,15 @@
             Um den Token dann zu verwenden muß
             <methodname>Zend_Gdata_AuthSub::getHttpClient()</methodname> aufgerufen werden. Diese
             Funktion gibt eine Instanz von <classname>Zend_Http_Client</classname> zurück, mit
-            gültigen Headern gesetzt, sodas eine nachfolgende Anfrage der Anwendung, die diesen Http
-            Clienten verwenden, auch authentifiziert sind.
+            gültigen Headern gesetzt, sodas eine nachfolgende Anfrage der Anwendung, die diesen
+            <acronym>HTTP</acronym> Clienten verwenden, auch authentifiziert sind.
         </para>
 
         <para>
             Nachfolgend ist ein Beispiel von <acronym>PHP</acronym> Code für eine Web Anwendung um
             eine Authentifizierung zu erlangen damit der Google Calender Service verwendet werden
             kann, und der ein <classname>Zend_Gdata</classname> Client Objekt erstellt das diesen
-            authentifizierten Http Client verwendet.
+            authentifizierten <acronym>HTTP</acronym> Client verwendet.
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -134,10 +134,10 @@ if (isset($_GET['logout'])) {
             <title>Sicherheitshinweise</title>
 
             <para>
-                Das vermeiden der <varname>$php_self</varname> Variable im obigen Beispiel ist eine
+                Das Vermeiden der <varname>$php_self</varname> Variable im obigen Beispiel ist eine
                 generelle Sicherheits Richtlinie, die nicht nur für
-                <classname>Zend_Gdata</classname> gilt. Inhalt der zu Http Headern ausgegeben wird
-                sollte immer gefiltert werden.
+                <classname>Zend_Gdata</classname> gilt. Inhalt der zu <acronym>HTTP</acronym>
+                Headern ausgegeben wird sollte immer gefiltert werden.
             </para>
 
             <para>

documentation/manual/de/module_specs/Zend_Gdata_ClientLogin.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21815 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.gdata.clientlogin">
     <title>Authentifizieren mit ClientLogin</title>
@@ -7,7 +7,7 @@
     <para>
         Der ClientLogin Mechanismus erlaubt es <acronym>PHP</acronym> Anwendungen zu schreiben die
         Authentifizierungs-zugriff zu Google Services benötigen, durch die Spezifikation von
-        Benutzer Zugangsdaten im Http Client.
+        Benutzer Zugangsdaten im <acronym>HTTP</acronym> Client.
     </para>
 
     <para>
@@ -35,8 +35,8 @@
         <title>Erstellen eines ClientLogin autentifizierten Http Clienten</title>
 
         <para>
-            Der Prozess der Erstellung eines autentifizierten Http Clients durch Verwendung des
-            ClientLogin Mechanismus besteht darin die statische Funktion
+            Der Prozess der Erstellung eines autentifizierten <acronym>HTTP</acronym> Clients durch
+            Verwendung des ClientLogin Mechanismus besteht darin die statische Funktion
             <methodname>Zend_Gdata_ClientLogin::getHttpClient()</methodname> aufzurufen und die
             Google Account Zugangsdaten als reinen Text zu übergeben. Der Rückgabewert dieser
             Funktion ist ein Objekt der Klasse <classname>Zend_Http_Client</classname>.

documentation/manual/de/module_specs/Zend_Http_Client-Advanced.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21825 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.http.client.advanced">
     <title>Zend_Http_Client - Fortgeschrittende Nutzung</title>
@@ -14,14 +14,15 @@
         </para>
 
         <para>
-            Gemäß dem HTTP/1.1 RFC sollten HTTP 301 und 302 Antworten vom Client behandelt werden,
-            indem die selbe Anfrage erneut an die angebene Stelle versendet wird - unter Verwendung
-            der selben Anfragemethode. Allerdings haben dies die meisten Clients nicht
-            implementiert und verwenden beim Umleiten eine GET Anfrage. Standardmäßig macht
-            <classname>Zend_Http_Client</classname> genau dasselbe - beim Umleiten einer 301 oder
-            302 Antwort, werden alle GET und POST Parameter zurückgesetzt und eine GET Anfrage wird
-            an die neue Stelle versandt. Dieses Verhalten kann durch Setzen des 'strictredirects'
-            Konfigurationsparameters auf das boolesche <constant>TRUE</constant> geändert werden.
+            Gemäß dem <acronym>HTTP</acronym>/1.1 RFC sollten <acronym>HTTP</acronym> 301 und 302
+            Antworten vom Client behandelt werden, indem die selbe Anfrage erneut an die angebene
+            Stelle versendet wird - unter Verwendung der selben Anfragemethode. Allerdings haben
+            dies die meisten Clients nicht implementiert und verwenden beim Umleiten eine GET
+            Anfrage. Standardmäßig macht <classname>Zend_Http_Client</classname> genau dasselbe -
+            beim Umleiten einer 301 oder 302 Antwort, werden alle GET und POST Parameter
+            zurückgesetzt und eine GET Anfrage wird an die neue Stelle versandt. Dieses Verhalten
+            kann durch Setzen des 'strictredirects' Konfigurationsparameters auf das boolesche
+            <constant>TRUE</constant> geändert werden.
 
             <example id="zend.http.client.redirections.example-1">
                 <title>Strikte Umleitung von 301 und 302 Antworten nach RFC 2616 erzwingen</title>
@@ -164,11 +165,11 @@ $client->setHeaders(array(
         <title>Dateiuploads</title>
 
         <para>
-            Man kann Dateien über HTTP hochladen, indem man die setFileUpload Methode verwendet.
-            Diese Methode nimmt einen Dateinamen als ersten Parameter, einen Formularnamen als
-            zweiten Parameter und Daten als einen dritten, optionalen Parameter entgegen. Wenn der
-            dritte Parameter <constant>NULL</constant> ist, wird angenommen, dass der erste
-            Dateinamen Parameter auf eine echte Datei auf der Platte verweist, und
+            Man kann Dateien über <acronym>HTTP</acronym> hochladen, indem man die setFileUpload
+            Methode verwendet. Diese Methode nimmt einen Dateinamen als ersten Parameter, einen
+            Formularnamen als zweiten Parameter und Daten als einen dritten, optionalen Parameter
+            entgegen. Wenn der dritte Parameter <constant>NULL</constant> ist, wird angenommen, dass
+            der erste Dateinamen Parameter auf eine echte Datei auf der Platte verweist, und
             <classname>Zend_Http_Client</classname> wird versuchen die Datei zu lesen und
             hochzuladen. Wenn der Daten Parameter nicht <constant>NULL</constant> ist, wird der
             erste Dateinamen Parameter als der Dateiname versendet, aber die Datei muss nicht
@@ -263,8 +264,8 @@ $client->setRawData($xml)->setEncType('text/xml')->request('POST');
         <title>HTTP Authentifizierung</title>
 
         <para>
-            Derzeit unterstützt <classname>Zend_Http_Client</classname> nur die Basis HTTP
-            Authentifizierung. Diese Funktion kann durch Verwendung der
+            Derzeit unterstützt <classname>Zend_Http_Client</classname> nur die Basis
+            <acronym>HTTP</acronym> Authentifizierung. Diese Funktion kann durch Verwendung der
             <methodname>setAuth()</methodname> Methode oder durch Spezifikation von Benutzername und
             Passwort in der URI genutzt werden. Die <methodname>setAuth()</methodname> Methode nimmt
             3 Parameter entgegen: den Benutzernamen, das Passwort und einen optionalen
@@ -419,7 +420,8 @@ $client->setRawData($fp, 'application/zip')->request('PUT');
         </para>
 
         <para>
-            Aktuell unterstützen nur PUT Anfragen das Senden von Streams zum HTTP Server.
+            Aktuell unterstützen nur PUT Anfragen das Senden von Streams zum <acronym>HTTP</acronym>
+            Server.
         </para>
 
         <para>

documentation/manual/de/module_specs/Zend_Http_Client.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21821 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.http.client">
     <title>Einführung</title>
@@ -139,7 +139,8 @@ $client->setConfig($config);
                             <entry>httpversion</entry>
 
                             <entry>
-                                Version des HTTP Protokolls (normalerweise '1.1' oder '1.0')
+                                Version des <acronym>HTTP</acronym> Protokolls (normalerweise '1.1'
+                                oder '1.0')
                             </entry>
 
                             <entry>string</entry>
@@ -209,8 +210,9 @@ $client->setConfig($config);
         <title>Durchführen von einfachen HTTP Anfragen</title>
 
         <para>
-            Das Durchführen von einfachen HTTP Anfragen kann sehr leicht durch Verwendung der
-            request() Methode gemacht werden und benötigt selten mehr als drei Codezeilen:
+            Das Durchführen von einfachen <acronym>HTTP</acronym> Anfragen kann sehr leicht durch
+            Verwendung der request() Methode gemacht werden und benötigt selten mehr als drei
+            Codezeilen:
 
             <example id="zend.http.client.basic-requests.example-1">
                 <title>Durchführen einer einfache GET Anfrage</title>
@@ -222,8 +224,8 @@ $response = $client->request();
             </example>
 
             Die request() Methode akzeptiert einen optionalen Parameter - die Anfragemethode.
-            Diese kann GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS oder CONNECT sein, wie im HTTP
-            Protokoll definiert.
+            Diese kann GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS oder CONNECT sein, wie im
+            <acronym>HTTP</acronym> Protokoll definiert.
 
             <footnote>
                 <para>
@@ -260,14 +262,13 @@ $response = $client->request();
         <title>Hinzufügen von GET und POST Parametern</title>
 
         <para>
-            Das Hinzufügen von GET Parametern zu einer HTTP Anfrage ist recht einfach und kann
-            entweder über die Angabe als Teil der URL oder durch Verwendung der setParameterGet()
-            Methode erfolgen.
-            Diese Methode benötigt den Namen des GET Parameter als seinen ersten Parameter und den
-            Wert des GET Parameter als seinen zweiten Parameter. Zur Erleichterung akzeptiert die
-            setParameterGet() Methode auch ein einzelnes assoziatives Array mit GET Parameter als
-            Name => Wert Variablen, was beim setzen von mehreren GET Parametern komfortabler sein
-            kann.
+            Das Hinzufügen von GET Parametern zu einer <acronym>HTTP</acronym> Anfrage ist recht
+            einfach und kann entweder über die Angabe als Teil der URL oder durch Verwendung der
+            setParameterGet() Methode erfolgen. Diese Methode benötigt den Namen des GET Parameter
+            als seinen ersten Parameter und den Wert des GET Parameter als seinen zweiten Parameter.
+            Zur Erleichterung akzeptiert die setParameterGet() Methode auch ein einzelnes
+            assoziatives Array mit GET Parameter als Name => Wert Variablen, was beim setzen von
+            mehreren GET Parametern komfortabler sein kann.
 
             <example id="zend.http.client.parameters.example-1">
                 <title>Setzen von GET Parametern</title>

documentation/manual/de/module_specs/Zend_Http_Cookie-Handling.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21815 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.http.cookies">
     <title>Zend_Http_Cookie und Zend_Http_CookieJar</title>
@@ -177,10 +177,10 @@ $cookie = Zend_Http_Cookie::fromString('foo=bar; secure;',
 
         <para>
             Ein Cookie Objekt kann durch die magische __toString()-Methode zurück in einen String
-            umgewandelt werden. Diese Methode erstellt einen HTTP-Anfrage "Cookie"-Header String,
-            der den Namen sowie den Inhalt des Cookies enthält und durch ein Semikolon (';')
-            abgeschlossen ist. Der Inhalt wird URL-kodiert, wie es für einen Cookie-Header
-            vorgeschrieben ist:
+            umgewandelt werden. Diese Methode erstellt einen <acronym>HTTP</acronym>-Anfrage
+            "Cookie"-Header String, der den Namen sowie den Inhalt des Cookies enthält und durch ein
+            Semikolon (';') abgeschlossen ist. Der Inhalt wird URL-kodiert, wie es für einen
+            Cookie-Header vorgeschrieben ist:
 
             <example id="zend.http.cookies.cookie.instantiating.example-2">
                <title>Transformation eines Zend_Http_Cookie-Objekts zu einem String</title>

documentation/manual/de/module_specs/Zend_Http_Response.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21821 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.http.response">
     <title>Zend_Http_Response</title>
@@ -17,8 +17,9 @@
 
         <para>
             In den meisten Fällen wird ein <classname>Zend_Http_Response</classname> Objekt über die
-            fromString() Methode instanziert, die einen String liest, der eine HTTP Rückantwort
-            enthält und ein <classname>Zend_Http_Response</classname> Objekt zurückgibt.
+            fromString() Methode instanziert, die einen String liest, der eine
+            <acronym>HTTP</acronym> Rückantwort enthält und ein
+            <classname>Zend_Http_Response</classname> Objekt zurückgibt.
 
             <example id="zend.http.response.introduction.example-1">
                 <title>Ein Zend_Http_Response Object über die factory Methode instanzieren</title>

documentation/manual/de/module_specs/Zend_Oauth-GettingStarted.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21821 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect2 id="zend.oauth.introduction.getting-started">
     <title>Beginnen</title>
@@ -179,12 +179,13 @@ if (!empty($_GET) && isset($_SESSION['TWITTER_REQUEST_TOKEN'])) {
         Erfolg! Wir haben einen authorisierten Zugriffstoken - zu dieser Zeit verwenden wir schon
         die <acronym>API</acronym> von Twitter. Da dieser Zugriffstoken bei jeder einzelnen
         <acronym>API</acronym> Anfrage enthalten sein muss, bietet
-        <classname>Zend_Oauth_Consumer</classname> einen fix-fertigen HTTP Client an (eine Subklasse
-        von <classname>Zend_Http_Client</classname>) welcher entweder für sich verwendet werden,
-        oder der als eigener HTTP Client an eine andere Bibliothek oder Komponente übergeben werden
-        kann. Hier ist ein Beispiel für die eigenständige Verwendung. Das kann von überall aus der
-        Anwendung heraus getan werden, solange man Zugriff auf die OAuth Konfiguration hat, und den
-        endgültigen authorisierten Zugriffstoken empfangen kann.
+        <classname>Zend_Oauth_Consumer</classname> einen fix-fertigen <acronym>HTTP</acronym> Client
+        an (eine Subklasse von <classname>Zend_Http_Client</classname>) welcher entweder für sich
+        verwendet werden, oder der als eigener <acronym>HTTP</acronym> Client an eine andere
+        Bibliothek oder Komponente übergeben werden kann. Hier ist ein Beispiel für die
+        eigenständige Verwendung. Das kann von überall aus der Anwendung heraus getan werden,
+        solange man Zugriff auf die OAuth Konfiguration hat, und den endgültigen authorisierten
+        Zugriffstoken empfangen kann.
     </para>
 
     <programlisting language="php"><![CDATA[

documentation/manual/de/module_specs/Zend_Oauth-ProtocolWorkflow.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21819 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect2 id="zend.oauth.introduction.protocol-workflow">
     <title>Workflow des Protokolls</title>
@@ -32,13 +32,13 @@
 
     <para>
         In der Zwischenzeit was TweenExpress beschäftigt. Bevor das Einverständnis von Twitter
-        gegeben wird, hat es eine HTTP Anfrage an den Service von Twitter geschickt und nach einem
-        neuen unauthorisierten Anfrage Token gefragt. Dieser Token ist aus der Perspektive von
-        Twitter nicht Benutzerspezifisch, aber TweetExpress man Ihn spezifisch für den aktuellen
-        Benutzer verwenden und sollte Ihn mit seinem Account verknüpfen und Ihn für eine
-        künftige Verwendung speichern. TweetExpress leitet den Benutzer nun zu Twitter um damit er
-        den Zugriff von TweetExpress erlauben kann. Die URL für diese Umleitung wird signiert indem
-        das Konsumentengeheimnis von TweetExpress verwendet wird und Sie enthält den
+        gegeben wird, hat es eine <acronym>HTTP</acronym> Anfrage an den Service von Twitter
+        geschickt und nach einem neuen unauthorisierten Anfrage Token gefragt. Dieser Token ist aus
+        der Perspektive von Twitter nicht Benutzerspezifisch, aber TweetExpress man Ihn spezifisch
+        für den aktuellen Benutzer verwenden und sollte Ihn mit seinem Account verknüpfen und Ihn
+        für eine künftige Verwendung speichern. TweetExpress leitet den Benutzer nun zu Twitter um
+        damit er den Zugriff von TweetExpress erlauben kann. Die URL für diese Umleitung wird
+        signiert indem das Konsumentengeheimnis von TweetExpress verwendet wird und Sie enthält den
         unauthorisierten Anfrage Token als Parameter.
     </para>
 

documentation/manual/de/module_specs/Zend_Oauth-SecurityArchitecture.xml

@@ -1,15 +1,16 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21818 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect2 id="zend.oauth.introduction.security-architecture">
     <title>Architektur der Sicherheit</title>
 
     <para>
-        OAuth wurde speziell designt um über eine unsichere HTTP Verbindung zu arbeiten und deshalb
-        ist die Verwendung von HTTPS nicht notwendig obwohl es natürlich wünschenswert wäre wenn es
-        vorhanden ist. Sollte eine HTTPS Verbindung möglich sein bietet OAuth die Implementation
-        einer Signaturmethode an welche PLAINTEXT heißt und verwendet werden kann. Über eine
-        typische unsichere HTTP Verbindung muss die Verwendung von PLAINTEXT verhindert werden und
+        OAuth wurde speziell designt um über eine unsichere <acronym>HTTP</acronym> Verbindung zu
+        arbeiten und deshalb ist die Verwendung von <acronym>HTTPS</acronym> nicht notwendig obwohl
+        es natürlich wünschenswert wäre wenn es vorhanden ist. Sollte eine <acronym>HTTPS</acronym>
+        Verbindung möglich sein bietet OAuth die Implementation einer Signaturmethode an welche
+        PLAINTEXT heißt und verwendet werden kann. Über eine typische unsichere
+        <acronym>HTTP</acronym> Verbindung muss die Verwendung von PLAINTEXT verhindert werden und
         ein alternatives Schema wird verwendet. Die OAuth Spezifikation definiert zwei solcher
         Signaturmethoden: HMAC-SHA1 und RSA-SHA1. Beide werden von <classname>Zend_Oauth</classname>
         vollständig unterstützt.
@@ -17,14 +18,15 @@
 
     <para>
         Diese Signaturmethoden sind recht einfach zu verstehen. Wie man sich vorstellen kann macht
-        die PLAINTEXT Signaturmethode nichts das erwähnenswert wäre da Sie auf HTTPS aufsetzt. Wenn
-        man aber PLAINTEXT über HTTP verwenden würde, dann würde ein signifikantes Problem bestehen:
-        Es gibt keinen Weg um sicherzustellen das der Inhalt einer OAuth-aktivierten Anfrage (welche
-        einen OAuth Zugriffstoken enthalten würde) beim Routen verändert wurde. Das ist der Fall
-        weil unsichere HTTP Anfragen immer das Risiko des Lauschens, von Man In The Middle (MITM)
-        Attacken, oder andere Risiken haben können in denen eine Anfrage weiterbearbeitet werden
-        könnten und damit Arbeiten im Sinne des Angreifers ausgeführt werden indem sich dieser
-        als Originalanwendung maskiert ohne das dies vom Serviceprovider bemerkt wird.
+        die PLAINTEXT Signaturmethode nichts das erwähnenswert wäre da Sie auf
+        <acronym>HTTPS</acronym> aufsetzt. Wenn man aber PLAINTEXT über <acronym>HTTP</acronym>
+        verwenden würde, dann würde ein signifikantes Problem bestehen: Es gibt keinen Weg um
+        sicherzustellen das der Inhalt einer OAuth-aktivierten Anfrage (welche einen OAuth
+        Zugriffstoken enthalten würde) beim Routen verändert wurde. Das ist der Fall weil unsichere
+        <acronym>HTTP</acronym> Anfragen immer das Risiko des Lauschens, von Man In The Middle
+        (MITM) Attacken, oder andere Risiken haben können in denen eine Anfrage weiterbearbeitet
+        werden könnten und damit Arbeiten im Sinne des Angreifers ausgeführt werden indem sich
+        dieser als Originalanwendung maskiert ohne das dies vom Serviceprovider bemerkt wird.
     </para>
 
     <para>
@@ -82,11 +84,12 @@
 
     <para>
         Als letzter Punkt erwähnt, ist dies keine exzessive Ansicht der Sicherheitsarchitektur in
-        OAuth. Was passiert zum Beispiel wenn HTTP Anfragen welche sowohl den Zugriffstoken als auch
-        das Geheimnis des Konsumenten enthalten abgehört werden? Das System ist auf der einen Seite
-        von einer klaren Übermittlung von allem abhängig solange HTTPS nicht aktiv ist. Deshalb ist
-        die naheliegende Feststellung das HTTPS, dort wo es möglich ist zu bevorzugen ist und HTTP
-        nur an solchen Orten eingesetzt wird so es nicht anders möglich oder nicht erschwinglich
-        ist.
+        OAuth. Was passiert zum Beispiel wenn <acronym>HTTP</acronym> Anfragen welche sowohl den
+        Zugriffstoken als auch das Geheimnis des Konsumenten enthalten abgehört werden? Das System
+        ist auf der einen Seite von einer klaren Übermittlung von allem abhängig solange
+        <acronym>HTTPS</acronym> nicht aktiv ist. Deshalb ist die naheliegende Feststellung das
+        <acronym>HTTPS</acronym>, dort wo es möglich ist zu bevorzugen ist und
+        <acronym>HTTP</acronym> nur an solchen Orten eingesetzt wird so es nicht anders möglich oder
+        nicht erschwinglich ist.
     </para>
 </sect2>

documentation/manual/de/module_specs/Zend_View-Helpers-Currency.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21818 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect3 id="zend.view.helpers.initial.currency">
     <title>Currency Helfer</title>
@@ -47,9 +47,9 @@
         Es gibt verschiedene Wege die gewünschte Währung auszuwählen. Erstens kann man einfach einen
         Währungs-String übergeben; alternativ kann man ein Gebietsschema spezifizieren. Der
         vorgeschlagene Weg ist die Verwendung eines Gebietsschemas, da diese Information automatisch
-        erkannt und über den HTTP Client Header ausgewählt wird wenn ein Benutzer auf die Anwendung
-        zugreift. Und es stellt sicher das die angebotene Währung mit seinem Gebietsschema
-        übereinstimmt.
+        erkannt und über den <acronym>HTTP</acronym> Client Header ausgewählt wird wenn ein Benutzer
+        auf die Anwendung zugreift. Und es stellt sicher das die angebotene Währung mit seinem
+        Gebietsschema übereinstimmt.
     </para>
 
     <note>

documentation/manual/de/tutorials/multiuser-sessions.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21823 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="learning.multiuser.sessions">
     <title>User Session im Zend Framework managen</title>
@@ -8,11 +8,12 @@
         <title>Einführung in Sessions</title>
 
         <para>
-            Der Erfolg des Webs ist tief verwurzelt im Protokoll welches das Web antreibt: HTTP.
-            HTTP über TCP ist von seiner Natur her Statuslos, was bedeutet dass auch das Web selbst
-            Statuslos ist. Wärend dieser Aspekt einer der dominierenden Faktoren dafür ist warum das
-            Web ein so populäres Medium geworden ist, verursacht es auch einige interessante
-            Probleme für Entwickler welche das Web als Anwendungsplattform verwenden wollen.
+            Der Erfolg des Webs ist tief verwurzelt im Protokoll welches das Web antreibt:
+            <acronym>HTTP</acronym>. <acronym>HTTP</acronym> über TCP ist von seiner Natur her
+            Statuslos, was bedeutet dass auch das Web selbst Statuslos ist. Wärend dieser Aspekt
+            einer der dominierenden Faktoren dafür ist warum das Web ein so populäres Medium
+            geworden ist, verursacht es auch einige interessante Probleme für Entwickler welche das
+            Web als Anwendungsplattform verwenden wollen.
         </para>
 
         <para>

documentation/manual/de/tutorials/quickstart-create-project.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 21823 -->
+<!-- EN-Revision: 21826 -->
 <!-- Reviewed: no -->
 <sect1 id="learning.quickstart.create-project">
     <title>Das Projekt erstellen</title>
@@ -239,9 +239,9 @@ phpSettings.display_errors = 1
         <para>
             Typischerweise benötigt man immer einen <classname>IndexController</classname>, der ein
             Fallback Controller ist und auch als Homepage der Site arbeitet, und einen
-            <classname>ErrorController</classname> der verwendet wird um Dinge wie HTTP 404 Fehler
-            zu zeigen (wenn der Controller oder die Action nicht gefunden wird) und HTTP 500 Fehler
-            (Anwendungsfehler).
+            <classname>ErrorController</classname> der verwendet wird um Dinge wie
+            <acronym>HTTP</acronym> 404 Fehler zu zeigen (wenn der Controller oder die Action nicht
+            gefunden wird) und <acronym>HTTP</acronym> 500 Fehler (Anwendungsfehler).
         </para>
 
         <para>