[DOCUMENTATION] German:

- sync up to r16733

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

documentation/manual/de/manual.xml.in

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 16590 -->
+<!-- EN-Revision: 16718 -->
 <!-- Reviewed: no -->
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
     "@DOCBOOK_DTD@"
@@ -170,6 +170,7 @@
         <xi:include href="module_specs/Zend_Dojo-Data.xml" />
         <xi:include href="module_specs/Zend_Dojo-View.xml" parse="xml" />
         <xi:include href="module_specs/Zend_Dojo-Form.xml" parse="xml" />
+        <xi:include href="module_specs/Zend_Dojo-BuildLayers.xml" />
     </chapter>
 
     <chapter id="zend.dom">
@@ -193,6 +194,7 @@
         <xi:include href="module_specs/Zend_Feed-ConsumingAtomSingle.xml" />
         <xi:include href="module_specs/Zend_Feed-ModifyingFeed.xml" />
         <xi:include href="module_specs/Zend_Feed-CustomFeed.xml" />
+        <xi:include href="module_specs/Zend_Feed_Reader.xml" />
     </chapter>
 
     <chapter id="zend.file">

documentation/manual/de/module_specs/Zend_Application-QuickStart.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 16652 -->
+<!-- EN-Revision: 16727 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.application.quick-start">
     <title>Zend_Application Quick Start</title>

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

@@ -8,20 +8,20 @@
         <title>Einführung</title>
         <para>
             <classname>Zend_Controller_Action</classname> ist eine abstrakte Klasse die verwendet
-            werden kann um Aktion Kontroller zu implementieren die mit dem Front Kontroller
+            werden kann um Aktion Controller zu implementieren die mit dem Front Controller
             verwendet werden können um eine WebSeite zu erstellen die auf dem Model-View-Controller
             (<acronym>MVC</acronym>) Pattern basiert.
         </para>
 
         <para>
             Um <classname>Zend_Controller_Action</classname> zu verwenden, muß von dieser in der
-            eigenen aktuellen Aktions Kontroller Klasse ererbt werden (oder von dieser erben um eine
-            eigene Basisklasse für Aktion Kontroller zu erstellen). Die grundsätzlichste Operation
+            eigenen aktuellen Aktions Controller Klasse ererbt werden (oder von dieser erben um eine
+            eigene Basisklasse für Aktion Controller zu erstellen). Die grundsätzlichste Operation
             ist es von Ihr zu erben und Aktions Methoden zu erstellen die den verschiedenen Aktionen
-            entsprechen die der Kontroller der eigenen Seite handhaben soll. Das Handhaben von
+            entsprechen die der Controller der eigenen Seite handhaben soll. Das Handhaben von
             Routen und Dispatchen des <classname>Zend_Controller</classname>'s wird automatisch
             jegliche Methode die in der eigenen Klasse auf 'Action' endet, als potentielle
-            Kontroller Aktion herausfinden.
+            Controller Aktion herausfinden.
         </para>
 
         <para>
@@ -44,7 +44,7 @@ class FooController extends Zend_Controller_Action
 ]]></programlisting>
 
         <para>
-            Die obige <emphasis>FooController</emphasis> Klasse (Kontroller
+            Die obige <emphasis>FooController</emphasis> Klasse (Controller
             <emphasis>foo</emphasis>)´definiert zwei Aktionen, <emphasis>bar</emphasis> und
             <emphasis>baz</emphasis>.
         </para>
@@ -53,7 +53,7 @@ class FooController extends Zend_Controller_Action
             Da gibt es viel mehr das damit getan werden kann als das, wie eigene Initialisierungs
             Aktionen, Standardaktionen die aufgerufen werden wenn keine Aktion (oder eine ungültige
             Aktion) spezifiziert wird, pre- und post Dispatch Hooks, und eine Vielzahl von Helfer
-            Methoden. Dieses Kapitel arbeitet als eine Übersicht der Aktion Kontroller
+            Methoden. Dieses Kapitel arbeitet als eine Übersicht der Aktion Controller
             Funktionalitäten.
         </para>
 
@@ -62,10 +62,10 @@ class FooController extends Zend_Controller_Action
 
             <para>
                 Standardmäßig aktiviert der <link linkend="zend.controller.front">Front
-                Kontroller</link> den Aktion Helfer des <link
+                Controller</link> den Aktion Helfer des <link
                     linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>'s.
-                Dieser Helfer übernimmt das Einfügen des View Objekts in den Kontroller, sowie das
-                automatische Darstellen der View. Er kann innerhalb des Aktion Kontrollers mit einer
+                Dieser Helfer übernimmt das Einfügen des View Objekts in den Controller, sowie das
+                automatische Darstellen der View. Er kann innerhalb des Aktion Controllers mit einer
                 der folgenden Methoden ausgeschaltet werden:
             </para>
 
@@ -74,7 +74,7 @@ class FooController extends Zend_Controller_Action
 {
     public function init()
     {
-        // Lokal nur bei diesem Kontroller; beeinflußt alle Aktionen die mit
+        // Lokal nur bei diesem Controller; beeinflußt alle Aktionen die mit
         // init geladen wurden:
         $this->_helper->viewRenderer->setNoRender(true);
 
@@ -82,7 +82,7 @@ class FooController extends Zend_Controller_Action
         $this->_helper->removeHelper('viewRenderer');
 
         // Auch global, muß aber in Verbindung mit der Lokalen Version sein um
-        // für diesen Kontroller zu gelten:
+        // für diesen Controller zu gelten:
         Zend_Controller_Front::getInstance()
             ->setParam('noViewRenderer', true);
     }
@@ -117,11 +117,11 @@ class FooController extends Zend_Controller_Action
             <para>
                 Der primäre Grund um den <emphasis>ViewRenderer</emphasis> auszuschalten ist, wenn
                 einfach kein View Objekt benötigt wird, oder wenn nicht über ein View Skript
-                gerendert werden soll (zum Beispiel wenn ein Aktion Kontroller verwendet wird um
+                gerendert werden soll (zum Beispiel wenn ein Aktion Controller verwendet wird um
                 Web Service Protokolle wie <acronym>SOAP</acronym>, <acronym>XML-RPC</acronym> oder
                 <acronym>REST</acronym> anzubieten. In den meisten Fällen wird man den
                 <emphasis>ViewRenderer</emphasis> nie global ausschalten müssen, nur selektiv
-                innerhalb einzelner Kontroller oder Aktionen.
+                innerhalb einzelner Controller oder Aktionen.
             </para>
         </note>
     </sect2>
@@ -130,10 +130,10 @@ class FooController extends Zend_Controller_Action
         <title>Objekt Initialisierung</title>
 
         <para>
-            Wärend man immer den Konstruktor des Aktion Kontroller's überschreiben kann ist das
+            Wärend man immer den Konstruktor des Aktion Controller's überschreiben kann ist das
             nicht notwendig. <methodname>Zend_Controller_Action::__construct()</methodname> führt
             einige wichtige Aufgabe aus, wie das registrieren der Anfrage und Antwort Objekte, sowie
-            alle eigene einleitenden Argumente die von Front Kontroller übergeben wurden. Wenn der
+            alle eigene einleitenden Argumente die von Front Controller übergeben wurden. Wenn der
             Konstruktor überschrieben werden muß, muß sichergestellt sein das
             <methodname>parent::__construct($request, $response, $invokeArgs)</methodname>
             aufgerufen wird.
@@ -207,8 +207,8 @@ $this->getResponse()->appendBody($content);
 
             <listitem>
                 <para>
-                    <emphasis>Aufgerufene Argumente</emphasis>: Der Front Kontroller kann Parameter
-                    in den Router, Dispatcher und Aktion Kontroller einfügen. Um diese zu erhalten
+                    <emphasis>Aufgerufene Argumente</emphasis>: Der Front Controller kann Parameter
+                    in den Router, Dispatcher und Aktion Controller einfügen. Um diese zu erhalten
                     kann <methodname>getInvokeArg($key)</methodname> verwendet werden; alternativ
                     kann man die komplette Liste mit <methodname>getInvokeArgs()</methodname>
                     erhalten.
@@ -318,7 +318,7 @@ applicationOrModule/
                 <filename>/views/</filename> Unterverzeichnis weitere Funktionalitäten enthält
                 (helpers, filters). Wenn der Name und der Pfad des View Skripts ermittelt wird,
                 wird das <filename>/views/scripts/</filename> Verzeichnis als Basispfad verwendet,
-                mit einem Verzeichnis das nach dem individuellen Kontroller benannt ist und eine
+                mit einem Verzeichnis das nach dem individuellen Controller benannt ist und eine
                 Hierarchie von View Skripten bietet.
             </para>
         </sect3>
@@ -353,7 +353,7 @@ string render(string $action = null,
             </para>
 
             <note><para>
-                    Da Kontroller- und Aktionsnamen Wort Begrenzer Zeichen enthalten können wie
+                    Da Controller- und Aktionsnamen Wort Begrenzer Zeichen enthalten können wie
                     z.B. '_', '.' und '-', normalisiert <methodname>render()</methodname> diese
                     zu '-' wenn der Skript Name eruiert wird. Intern werden die Wort- und
                     Pfadbegrenzer vom Dispatcher verwendet um die Normalisierung durchzuführen.
@@ -443,7 +443,7 @@ class MyController extends Zend_Controller_Action
                         </para>
 
                         <para>
-                            Diese Option kann global im Kontroller gesetzt werden indem der
+                            Diese Option kann global im Controller gesetzt werden indem der
                             <methodname>setRedirectExit()</methodname> Zugriff verwendet wird.
                         </para>
                     </listitem>
@@ -456,7 +456,7 @@ class MyController extends Zend_Controller_Action
                         </para>
 
                         <para>
-                            Diese Option kann gobal im Kontroller gesetzt werden indem der
+                            Diese Option kann gobal im Controller gesetzt werden indem der
                             <methodname>setRedirectPrependBase()</methodname> Zugriff verwendet
                             wird.
                         </para>
@@ -471,7 +471,7 @@ class MyController extends Zend_Controller_Action
                         </para>
 
                         <para>
-                            Diese Option kann global im Kontroller gesetzt werden indem der
+                            Diese Option kann global im Controller gesetzt werden indem der
                             <methodname>setRedirectCode()</methodname> Zugriff verwendet wird.
                         </para>
                     </listitem>
@@ -481,19 +481,19 @@ class MyController extends Zend_Controller_Action
     </sect2>
 
     <sect2 id="zend.controller.action.subclassing">
-        <title>Erweitern des Aktion Kontrollers</title>
+        <title>Erweitern des Aktion Controllers</title>
 
         <para>
             Vom Design her muß <classname>Zend_Controller_Action</classname> erweitert werden um
-            einen Aktion Kontroller zu erstellen. Als Minimum, muß eine Aktions Methode definiert
-            werden die der Kontroller aufrufen kann.
+            einen Aktion Controller zu erstellen. Als Minimum, muß eine Aktions Methode definiert
+            werden die der Controller aufrufen kann.
         </para>
 
         <para>
             Neben dem erstellen von nützlichen Funktionalitäten für Web Anwendungen, wird auch die
             Notwendigkeit bestehen das vom gleichen Setup oder von den nützlichen Funktionen vieles
-            in verschiedenen Kontrollern wiederholt wird; wenn dem so ist, löst die Erstellung einer
-            gemeinsamen Basis Kontroller Klasse die <classname>Zend_Controller_Action</classname>
+            in verschiedenen Controllern wiederholt wird; wenn dem so ist, löst die Erstellung einer
+            gemeinsamen Basis Controller Klasse die <classname>Zend_Controller_Action</classname>
             erweitert zu einer Lösung dieser Redundanz.
         </para>
 
@@ -501,7 +501,7 @@ class MyController extends Zend_Controller_Action
             <title>Behandeln nicht-vorhandener Aktionen</title>
 
             <para>
-                Wenn eine Anfrage an einen Kontroller durchgeführt wird die eine undefinierte
+                Wenn eine Anfrage an einen Controller durchgeführt wird die eine undefinierte
                 Aktions Methode enthält, kommt
                 <methodname>Zend_Controller_Action::__call()</methodname> zum Einsatz.
                 <methodname>__call()</methodname> ist natürlich <acronym>PHP</acronym>'s magische
@@ -511,7 +511,7 @@ class MyController extends Zend_Controller_Action
             <para>
                 Standardmäßig wirft diese Methode eine
                 <classname>Zend_Controller_Action_Exception</classname> die anzeigt das die
-                angefragte Aktion nicht im Kontroller gefunden werden konnte. Wenn die angefragte
+                angefragte Aktion nicht im Controller gefunden werden konnte. Wenn die angefragte
                 Methode mit 'Action' endet, wird angenommen das eine Aktion angefragt wurde die
                 nicht existiert; solch ein Fehler resultiert in einer Ausnahme mit dem Code 404.
                 Alle anderen Methoden resultieren in einer Ausnahme mit dem Code 500. Das erlaubt
@@ -546,7 +546,7 @@ class MyController extends Zend_Controller_Action
 ]]></programlisting>
 
             <para>
-                Eine andere Möglichkeit ist, dass man zu einer standardmäßigen Kontroller Seiten
+                Eine andere Möglichkeit ist, dass man zu einer standardmäßigen Controller Seiten
                 weiterleiten will:
             </para>
 
@@ -579,7 +579,7 @@ class MyController extends Zend_Controller_Action
         <para>
             Neben dem überschreiben von <methodname>__call()</methodname>, kann jede der
             Initialisierungs-, Utility-, Zugriffs-, View- und Dispatch-Hook Methoden die vorher in
-            diesem Kapitel beschrieben wurden, überschrieben werden um eigene Kontroller
+            diesem Kapitel beschrieben wurden, überschrieben werden um eigene Controller
             anzupassen. Wenn man, als Beispiel, die View Objekte in der Registry speichert, kann es
             gewünscht sein die <methodname>initView()</methodname> Methode mit Code zu Ändern der
             das folgende zusammensetzt:

documentation/manual/de/module_specs/Zend_Controller-ActionHelpers-ActionStack.xml

@@ -7,7 +7,7 @@
     <para>
         Der <emphasis>ActionStack</emphasis> Helfer erlaubt das Verschieben von Anfragen zum <link
             linkend="zend.controller.plugins.standard.actionstack">ActionStack</link> Front
-        Kontroller Plugin, welches effektiv hilft um eine Queue von Aktionen zu erstellen die wärend
+        Controller Plugin, welches effektiv hilft um eine Queue von Aktionen zu erstellen die wärend
         der Anfrage ausgeführt wird. Der Helfer erlaubt das hinzufügen von Aktionen entweder durch
         Spezifikation von neuen Anfrage Objekten oder Aktion - Controller - Modul Sets.
     </para>
@@ -25,11 +25,11 @@
 
     <example id="zend.controller.actionhelpers.actionstack.simple">
         <title>
-            Eine Aufgabe hinzufügen indem Aktion, Kontroller und Modulnamen verwendet werden
+            Eine Aufgabe hinzufügen indem Aktion, Controller und Modulnamen verwendet werden
         </title>
 
         <para>
-            Oft ist es am einfachsten, einfach die Aktion, den Kontroller und das Modul (und
+            Oft ist es am einfachsten, einfach die Aktion, den Controller und das Modul (und
             optionale Anfrage Parameter) zu spezifizieren, wie wenn
             <methodname>Zend_Controller_Action::_forward()</methodname> aufgerufen werden würde:
         </para>
@@ -73,7 +73,7 @@ class FooController extends Zend_Controller_Action
         // Aufruf zu /foo/baz/bar/baz hinzufügen
         // (FooController::bazAction() mit der Anfrage var bar == baz)
         $request = clone $this->getRequest();
-        // Kontroller oder Modul nicht setzen, verwende aktuelle Werte
+        // Controller oder Modul nicht setzen, verwende aktuelle Werte
         $request->setActionName('baz')
                 ->setParams(array('bar' => 'baz'));
         $this->_helper->actionStack($request);

documentation/manual/de/module_specs/Zend_Controller-ActionHelpers-AutoComplete.xml

@@ -145,7 +145,7 @@ $this->_helper->autoCompleteDojo($data);
             <para>
                 AutoCompletion mit Dojo, über Zend <acronym>MVC</acronym>, benötigt verschiedene
                 Dinge: Erstellung eines Form Objekts für die Kombobox bei der man AutoCompletion
-                will, eine Kontroller Action für das anbieten der AutoCompletion Ergebnisse,
+                will, eine Controller Action für das anbieten der AutoCompletion Ergebnisse,
                 Erstellung eines eigenen QueryReadSote um die AutoCompletion Aktion damit zu
                 verbinden, und Erstellung des Javascripts das zur Initialisierung der
                 AutoCompletion auf der Serverseite zu verwenden ist.

documentation/manual/de/module_specs/Zend_Controller-ActionHelpers-ContextSwitch.xml

@@ -13,7 +13,7 @@
     </para>
 
     <para>
-        Um einen von Ihnen zu aktivieren, muß der Kontroller darauf hingewiesen werden welche
+        Um einen von Ihnen zu aktivieren, muß der Controller darauf hingewiesen werden welche
         Aktion zu welchem Kontext antworten kann. Wenn eine hereinkommende Anfrage einen gültigen
         Kontext für eine gegebene Aktion indiziert, dann wird der Helfer:
     </para>
@@ -39,7 +39,7 @@
     </itemizedlist>
 
     <para>
-        Als Beispiel wird der folgende Kontroller angenommen:
+        Als Beispiel wird der folgende Controller angenommen:
     </para>
 
     <programlisting language="php"><![CDATA[
@@ -295,7 +295,7 @@ $this->_helper->contextSwitch()->setAutoJsonSerialization(false);
 
         <para>
             Es gibt zwei Mechanismen für das Setzen vorhandener Kontexte. Es kann entweder manuell
-            ein Array im Kontroller erstellt werden, oder es können verschiedene Methoden in
+            ein Array im Controller erstellt werden, oder es können verschiedene Methoden in
             <emphasis>ContextSwitch</emphasis> verwendet werden um Sie zu bauen.
         </para>
 
@@ -689,7 +689,7 @@ $contextSwitch->initContext();
         </para>
 
         <para>
-            Zuerst, verwendet es eine andere Action Kontroller Eigenschaft
+            Zuerst, verwendet es eine andere Action Controller Eigenschaft
             <varname>$ajaxable</varname> um Kontexte festzustellen. Damit kann man verschiedene
             Kontexte verwenden für <acronym>AJAX</acronym> gegenüber normalen
             <acronym>HTTP</acronym> Anfragen. Die verschiedenen

documentation/manual/de/module_specs/Zend_Controller-ActionHelpers-ViewRenderer.xml

@@ -15,8 +15,8 @@
         <itemizedlist>
             <listitem>
                 <para>
-                    Entfernen der Notwendigkeit View Objekte innerhalb der Kontroller zu
-                    instanzieren; View Objekte werden automatisch mit dem Kontroller registriert.
+                    Entfernen der Notwendigkeit View Objekte innerhalb der Controller zu
+                    instanzieren; View Objekte werden automatisch mit dem Controller registriert.
                 </para>
             </listitem>
 
@@ -30,14 +30,14 @@
 
             <listitem>
                 <para>
-                    Ein global vorhandenes View Objekt für alle bearbeitenden Kontroller und
+                    Ein global vorhandenes View Objekt für alle bearbeitenden Controller und
                     Aktionen erstellen.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    Dem Entwickler erlauben das Standard View Rendering Optionen für alle Kontroller
+                    Dem Entwickler erlauben das Standard View Rendering Optionen für alle Controller
                     gesetzt werden.
                 </para>
             </listitem>
@@ -70,7 +70,7 @@
         <note>
             <para>
                 Der <emphasis>ViewRenderer</emphasis> ist standardmäßig aktiviert. Man kann Ihn
-                über den Parameter <emphasis>noViewRenderer</emphasis> des Frontkontrollers
+                über den Parameter <emphasis>noViewRenderer</emphasis> des Frontcontrollers
                 deaktivieren (<command>$front->setParam('noViewRenderer', true);</command>)
                 oder den Helfer vom Helfer Broker Stack entfernen
                 (<methodname>Zend_Controller_Action_HelperBroker::removeHelper('viewRenderer')</methodname>).
@@ -78,7 +78,7 @@
 
             <para>
                 Wenn man Einstellungen vom <code>ViewRenderer</code> vor der Ausführung des Front
-                Kontrollers ändern will, kann das auf zwei Wegen getan werden:
+                Controllers ändern will, kann das auf zwei Wegen getan werden:
             </para>
 
             <itemizedlist>
@@ -129,11 +129,11 @@ Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
 ]]></programlisting>
 
         <para>
-            Das erste Mal wenn ein Aktion Kontroller instanziert wird, triggert er den
+            Das erste Mal wenn ein Aktion Controller instanziert wird, triggert er den
             <emphasis>ViewRenderer</emphasis> ein View Objekt zu instanzieren. Jedes Mal wenn ein
-            Kontroller Instanziert wird, wird die <methodname>init()</methodname> Methode des
+            Controller Instanziert wird, wird die <methodname>init()</methodname> Methode des
             <emphasis>ViewRenderer</emphasis>'s aufgerufen, was dazu führt das er die view
-            Eigenschaft des Aktion Kontrollers setzt, und <methodname>addScriptPath()</methodname>,
+            Eigenschaft des Aktion Controllers setzt, und <methodname>addScriptPath()</methodname>,
             mit einem Pfad relativ zum aktuellen Modul, aufruft; das wird mit einem Klassenprefix
             aufgerufen der nach dem aktuellen Modul benannt ist, was effektiv für alle Helfer und
             Filterklassen die im Modul definiert werden den Namensraum setzt.
@@ -149,7 +149,7 @@ Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
         </para>
 
         <programlisting language="php"><![CDATA[
-// Eine Kontroller Klasse, foo Modul:
+// Eine Controller Klasse, foo Modul:
 class Foo_BarController extends Zend_Controller_Action
 {
     // Rendert standardmäßig bar/index.phtml; keine Aktion benötigt
@@ -190,9 +190,9 @@ $this->foo(); // Foo_View_Helper_Foo::foo() aufrufen
                 <para>
                     <methodname>setNeverRender($flag = true)</methodname> kann verwendet werden um
                     das automatische rendern global ein- oder auszuschalten, z.B. für alle
-                    Kontroller. Wenn er auf <constant>TRUE</constant> gesetzt wird, ruft
+                    Controller. Wenn er auf <constant>TRUE</constant> gesetzt wird, ruft
                     <methodname>postDispatch()</methodname> nicht automatisch
-                    <methodname>render()</methodname> im aktuellen Kontroller auf.
+                    <methodname>render()</methodname> im aktuellen Controller auf.
                     <methodname>getNeverRender()</methodname> empfängt den aktuellen Wert.
                 </para>
             </listitem>
@@ -203,9 +203,9 @@ $this->foo(); // Foo_View_Helper_Foo::foo() aufrufen
                     automatische rendern ein- oder auszuschalten. Wenn er auf
                     <constant>TRUE</constant> gesetzt wird, wird
                     <methodname>postDispatch()</methodname> <methodname>render()</methodname>
-                    im aktuellen Kontroller nicht automatisch aufrufen. Diese Einstellung wird
+                    im aktuellen Controller nicht automatisch aufrufen. Diese Einstellung wird
                     jedesmal zurückgesetzt wenn <methodname>preDispatch()</methodname> aufgerufen
-                    wird (z.B. muß dieses Flag für jeden Kontroller gesetzt werden für den das
+                    wird (z.B. muß dieses Flag für jeden Controller gesetzt werden für den das
                     automatische rendern nicht automatisch stattfinden soll).
                     <methodname>getNoRender()</methodname> empfängt den aktuellen Wert.
                 </para>
@@ -215,7 +215,7 @@ $this->foo(); // Foo_View_Helper_Foo::foo() aufrufen
                 <para>
                     <methodname>setNoController($flag = true)</methodname> kann verwendet werden um
                     <methodname>render()</methodname> zu sagen das für Aktion Skripts nicht in
-                    einem Unterverzeichnis gesucht werden soll das nach dem Kontroller benannt ist
+                    einem Unterverzeichnis gesucht werden soll das nach dem Controller benannt ist
                     (was das Standardverhalten ist). <methodname>getNoController()</methodname>
                     empfängt den aktuellen Wert.
                 </para>
@@ -235,7 +235,7 @@ $this->foo(); // Foo_View_Helper_Foo::foo() aufrufen
                     <methodname>setScriptAction($name)</methodname> kann verwendet werden um das
                     Aktion Skript zu spezifizieren das gerendert werden soll.
                     <varname>$name</varname> sollte der Name des Skripts sein, ohne den Datei
-                    Suffix (und ohne das Kontroller Unterverzeichnis, ausser wenn
+                    Suffix (und ohne das Controller Unterverzeichnis, ausser wenn
                     <emphasis>noController</emphasis> eingeschaltet wurde). Wenn nicht
                     spezifiziert, wird nach einem View Skript gesucht das nach der Aktion in
                     Anfrage Objekt benannt ist. <methodname>getScriptAction()</methodname> empfängt
@@ -271,14 +271,14 @@ $this->foo(); // Foo_View_Helper_Foo::foo() aufrufen
                     <emphasis>responseSegment</emphasis>, oder <emphasis>noController</emphasis>
                     in einem Schritt zu übergeben. <methodname>direct()</methodname> ist ein
                     Alias für diese Methode, und erlaubt es diese Methode einfach vom eigenen
-                    Kontroller aus aufzurufen:
+                    Controller aus aufzurufen:
                 </para>
 
                 <programlisting language="php"><![CDATA[
 // Rendert 'foo' statt dem aktuellen Aktion Skript
 $this->_helper->viewRenderer('foo');
 
-// Rendert form.phtml zum 'html' Antwort Segment, ohne einen Kontroller aus dem
+// Rendert form.phtml zum 'html' Antwort Segment, ohne einen Controller aus dem
 // Unterverzeichnis des View Skripts zu verwenden:
 $this->_helper->viewRenderer('form', 'html', true);
 ]]></programlisting>
@@ -318,7 +318,7 @@ $viewRenderer =
             <listitem>
                 <para>
                     <emphasis>:moduleDir</emphasis> zeigt auf das aktuelle Modul Basisverzeichnis
-                    (von der Konvention her das Elternverzeicnis des Kontroller Verzeichnisses des
+                    (von der Konvention her das Elternverzeicnis des Controller Verzeichnisses des
                     Moduls).
                 </para>
             </listitem>
@@ -331,7 +331,7 @@ $viewRenderer =
 
             <listitem>
                 <para>
-                    <emphasis>:controller</emphasis> zeigt auf den aktuellen Kontrollernamen.
+                    <emphasis>:controller</emphasis> zeigt auf den aktuellen Controllernamen.
                 </para>
             </listitem>
 
@@ -539,8 +539,8 @@ $viewRenderer =
                 </para>
 
                 <para>
-                    Wortbegrenzer die in Modul-, Kontroller- oder Aktionsnamen vorkommen werden mit
-                    Bindestrichen ('-') ersetzt. Deshalb resultiert, wenn der Kontrollername
+                    Wortbegrenzer die in Modul-, Controller- oder Aktionsnamen vorkommen werden mit
+                    Bindestrichen ('-') ersetzt. Deshalb resultiert, wenn der Controllername
                     'foo.bar' und die Aktion 'baz:bat' ist, die Verwendung der standard Pfad
                     Spezifikation einen View Skript Pfad von
                     '<filename>foo-bar/baz-bat.phtml</filename>'.
@@ -617,7 +617,7 @@ Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
 
 ...
 
-// 'foo' Modul, 'bar' Kontroller:
+// 'foo' Modul, 'bar' Controller:
 class Foo_BarController extends Zend_Controller_Action
 {
     // Rendert standardmäßig bar/index.phtml; keine Aktion benötigt
@@ -650,13 +650,13 @@ class Foo_BarController extends Zend_Controller_Action
         </example>
 
         <note>
-            <title>Benamungs Konventionen: Wort Begrenzer in Kontroller- und Aktionnamen</title>
+            <title>Benamungs Konventionen: Wort Begrenzer in Controller- und Aktionnamen</title>
             <para>
-                Wenn der Kontroller- oder Aktionsname aus mehreren Wörtern aufgebaut ist, müssen
+                Wenn der Controller- oder Aktionsname aus mehreren Wörtern aufgebaut ist, müssen
                 diese, da der Dispatcher das benötigt, seperiert sein durch die
                 <acronym>URL</acronym> nach spezifischem Pfad und Wort Begrenzer Zeichen. Der
                 <emphasis>ViewRenderer</emphasis> ersetzt jeden Pfad Begrenzer den er im
-                Kontrollernamen findet mit einem aktuellen Pfad Begrenzer ('/'), und jeden Wort
+                Controllernamen findet mit einem aktuellen Pfad Begrenzer ('/'), und jeden Wort
                 Begrenzer der gefunden wird mit einem Bindestrich ('-') wenn Pfade erstellt werden.
                 Deshalb würde ein Aufruf der Aktion <filename>/foo.bar/baz.bat</filename> zu
                 <methodname>FooBarController::bazBatAction()</methodname> in
@@ -671,10 +671,10 @@ class Foo_BarController extends Zend_Controller_Action
 
             <para>
                 Es ist zu beachten das im zweiten Beispiel, das Modul noch immer das Standardmodul
-                ist, aber das der Kontroller, wegen der Existenz eines Pfad Separators, den Namen
+                ist, aber das der Controller, wegen der Existenz eines Pfad Separators, den Namen
                 <classname>Bar_BazController</classname> in
                 <filename>Bar/BazController.php</filename> empfängt. Der ViewRenderer emuliert die
-                Kontroller Verzeichnis Hierarchie.
+                Controller Verzeichnis Hierarchie.
             </para>
         </note>
 
@@ -682,7 +682,7 @@ class Foo_BarController extends Zend_Controller_Action
             <title>Automatisches rendern ausschalten</title>
 
             <para>
-                Für einige Aktionen oder Kontroller, kann es gewünscht sein das automatische Rendern
+                Für einige Aktionen oder Controller, kann es gewünscht sein das automatische Rendern
                 auszuschalten -- zum Beispiel, wenn eine andere Art von Ausgabe
                 (<acronym>XML</acronym>, <acronym>JSON</acronym>, etc)
                 ausgegeben werden soll, oder wenn man einfach nichts ausgeben will. Es gibt zwei
@@ -692,7 +692,7 @@ class Foo_BarController extends Zend_Controller_Action
             </para>
 
             <programlisting language="php"><![CDATA[
-// Baz Kontroller Klasse, bar Modul:
+// Baz Controller Klasse, bar Modul:
 class Bar_BazController extends Zend_Controller_Action
 {
     public function fooAction()
@@ -702,12 +702,12 @@ class Bar_BazController extends Zend_Controller_Action
     }
 }
 
-// Bat Kontroller Klasse, Bar Modul:
+// Bat Controller Klasse, Bar Modul:
 class Bar_BatController extends Zend_Controller_Action
 {
     public function preDispatch()
     {
-        // Die Aktionen dieses Kontroller nie automatisch Rendern
+        // Die Aktionen dieses Controller nie automatisch Rendern
         $this->_helper->viewRenderer->setNoRender();
     }
 }
@@ -728,7 +728,7 @@ class Bar_BatController extends Zend_Controller_Action
 
             <para>
                 Einige Situationen erfordern das ein anderes Skript, als das nach der Aktion
-                benannte, ausgeführt wird. Zum Beispiel, wenn man einen Kontroller hat der Aktionen
+                benannte, ausgeführt wird. Zum Beispiel, wenn man einen Controller hat der Aktionen
                 sowohl hinzufügen als auch bearbeiten kann, und beide mit der selben 'form' View
                 angezeigt werden, aber mit unterschiedlichen Werten gesetzt werden. Der Skript Name
                 kann ganz einfach geändert werden. Entweder mit
@@ -738,7 +738,7 @@ class Bar_BatController extends Zend_Controller_Action
             </para>
 
             <programlisting language="php"><![CDATA[
-// Bar Kontroller Klasse, foo Modul:
+// Bar Controller Klasse, foo Modul:
 class Foo_BarController extends Zend_Controller_Action
 {
     public function addAction()
@@ -775,13 +775,13 @@ class Foo_BarController extends Zend_Controller_Action
             <para>
                 Was wenn ein View Objekt modifiziert werden soll -- zum Beispiel, die Helfer Pfade
                 ändern, oder die Kodierung? Das kann durch Modifikation des View Objekts, das im
-                Kontroller gesetzt ist, gemacht werden, oder durch herausnehmen des View Objekts
+                Controller gesetzt ist, gemacht werden, oder durch herausnehmen des View Objekts
                 aus dem <emphasis>ViewRenderer</emphasis>; beide referenzieren auf das gleiche
                 Objekt.
             </para>
 
             <programlisting language="php"><![CDATA[
-// Bar Kontroller Klasse, foo Modul:
+// Bar Controller Klasse, foo Modul:
 class Foo_BarController extends Zend_Controller_Action
 {
     public function preDispatch()

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

@@ -8,9 +8,9 @@
         <title>Einführung</title>
         <para>
             Aktion Helfer erlauben Entwicklern Runtime und/oder On-Demand Funktionalität in jeden
-            Aktion Kontroller zu inizieren der <classname>Zend_Controller_Action</classname>
-            erweitert. Aktion Kontroller versuchen den Notwendigkeit zu minimieren, den abstrakten
-            Aktion Kontroller zu erweitern um damit normale Aktion Kontroller Funktionen inizieren.
+            Aktion Controller zu inizieren der <classname>Zend_Controller_Action</classname>
+            erweitert. Aktion Controller versuchen den Notwendigkeit zu minimieren, den abstrakten
+            Aktion Controller zu erweitern um damit normale Aktion Controller Funktionen inizieren.
         </para>
 
         <para>
@@ -20,7 +20,7 @@
                 linkend="zend.controller.plugins">Zend_Controller_Plugin</link>. Aktion Helfer
             <classname>Zend_View_Helper</classname>) können bei Bedarf geladen und aufgerufen
             werden, oder Sie können wärend der Anfragezeit (Bootstrap) instanziert werden oder
-            wären der Erstellungszeit des Aktion Kontrollers (<methodname>init()</methodname>). Um
+            wären der Erstellungszeit des Aktion Controllers (<methodname>init()</methodname>). Um
             Sie näher zu verstehen, betrachten wir Ihre Verwendung in der folgenden Sektion.
         </para>
     </sect2>
@@ -86,7 +86,7 @@ $this->_helper->FlashMessenger('Wir haben in der letzten Anfrage etwas getan');
 
         <para>
             Man kann Helfer auch explizit instanzieren. Das kann gewollt sein wenn der Helfer
-            ausserhalb eines Aktion Kontrollers verwendet werden soll, oder wenn ein Helfer an einen
+            ausserhalb eines Aktion Controllers verwendet werden soll, oder wenn ein Helfer an einen
             Helfer Broker übergeben wird um Ihn durch irgendeine Aktion zu verwenden. Instanziert
             wird er wie jede andere <acronym>PHP</acronym> Klasse.
         </para>
@@ -149,7 +149,7 @@ Zend_Controller_Action_HelperBroker::addPath('./Plugins/Helpers',
         </itemizedlist>
 
         <para>
-            Da diese Methoden statisch sind, können Sie zu jeder Zeit in der Kontrollerkette
+            Da diese Methoden statisch sind, können Sie zu jeder Zeit in der Controllerkette
             aufgerufen werden um Helfer dynamisch hinzuzufügen wenn es notwendig wird.
         </para>
 
@@ -233,7 +233,7 @@ if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
             Antworten; einen <emphasis>Redirector</emphasis>, um verschiedene Implementationen, für
             das Umleiten zu internen und externen Seiten, für die Anwendung bereitzustellen und
             einen <emphasis>ViewRenderer</emphasis> um den Prozess des Setzens eines View Objekts
-            im Kontroller und dem Rendern von Views zu automatisieren.
+            im Controller und dem Rendern von Views zu automatisieren.
         </para>
 
         <xi:include href="Zend_Controller-ActionHelpers-ActionStack.xml" />
@@ -258,7 +258,7 @@ if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
             <listitem>
                 <para>
                     <methodname>setActionController()</methodname> wird verwendet um den aktuellen
-                    Aktion Kontroller zu setzen.
+                    Aktion Controller zu setzen.
                 </para>
             </listitem>
 
@@ -266,7 +266,7 @@ if (Zend_Controller_Action_HelperBroker::hasHelper('redirector')) {
                 <para>
                     <methodname>init()</methodname>, wird vom Helfer Broker wärend der
                     Instanzierung ausgeführt und kann verwendet werden um den Status zu resetieren
-                    wenn mehrere Kontroller den gleichen Helfer in einer verketteten Aktion
+                    wenn mehrere Controller den gleichen Helfer in einer verketteten Aktion
                     verwenden.
                 </para>
             </listitem>

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

@@ -131,13 +131,13 @@
                     <para>
                         Da Menschen grundsätzlich inkonsistent sind im Behandeln und der
                         Gründlichkeit beim Tippen von Links, normalisiert Zend Framework die Pfad
-                        Informationen zur Kleinschreibung. Das beeinflut natürlich wie Kontroller
+                        Informationen zur Kleinschreibung. Das beeinflut natürlich wie Controller
                         und Aktionen benannt werden ... oder wie auf diese in Links referiert werden
                         kann.
                     </para>
 
                     <para>
-                        Wenn es gewünscht ist das die eigene Kontrollerklasse oder
+                        Wenn es gewünscht ist das die eigene Controllerklasse oder
                         Aktionsmethodenname mehrfache MixedCasedWörter oder camelCasedWörter
                         enthält, dann müssen diese zu getrennten Wörtern in der URL seperiert
                         werden, entweder mit einem '-' oder '.' (das zu verwendende Zeichen kann

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

@@ -138,7 +138,7 @@ if ($response->isException()) {
                     Der primäre Vorteil die diese Methode über
                     <methodname>Zend_Controller_Front::throwExceptions()</methodname> bietet ist,
                     das Sie es erlaubt die Antwort wahlweise darzustellen nachdem die Ausnahme
-                    behandelt wurde. Das fängt jede Ausnahme in der Kontrollerkette, im Gegensatz
+                    behandelt wurde. Das fängt jede Ausnahme in der Controllerkette, im Gegensatz
                     zum Error Handler Plugin.
                 </para>
             </listitem>
@@ -303,7 +303,7 @@ class My_Controller_Dispatcher extends Zend_Controller_Dispatcher
                         <para>
                             Durch das Erstellen einer Subklasse von
                             <classname>Zend_Controller_Action</classname> und dem modifizieren von
-                            <methodname>preDispatch()</methodname>, können alle eigenen Kontroller
+                            <methodname>preDispatch()</methodname>, können alle eigenen Controller
                             geändert werden damit Sie an andere Aktionen weiterleiten oder umleiten
                             bevor die Aktion letztendlich dargestellt wird. Der Code hierfür schaut
                             ähnlich wie der Code für das Überschreiben von

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

@@ -184,7 +184,7 @@ $inflector->setFilterRule(':action', array(
             <listitem>
                 <para>
                     Die am wenigsten zu empfehlende Option: Man kann den Dispatcher dazu zwingen
-                    camelCase Aktionsnamen mit einem neuen Front Kontroller Flag
+                    camelCase Aktionsnamen mit einem neuen Front Controller Flag
                     <property>useCaseSensitiveActions</property> zu bearbeiten:
                 </para>
 
@@ -224,9 +224,9 @@ $front->setParam('useCaseSensitiveActions', true);
         <para>
             Der <classname>ErrorHandler</classname> Plugin läuft wärend der
             <methodname>postDispatch()</methodname> Prüfung auf Ausnahmen, und leitet zu einem
-            spezifizierten Fehlerhandler Kontroller weiter. Solch ein Kontroller sollte in der
+            spezifizierten Fehlerhandler Controller weiter. Solch ein Controller sollte in der
             eigenen Anwendung inkludiert werden. Er kann deaktiviert werden durch das setzen des
-            Frontkontroller Parameters <property>noErrorHandler</property>:
+            Frontcontroller Parameters <property>noErrorHandler</property>:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -235,7 +235,7 @@ $front->setParam('noErrorHandler', true);
 
         <para>
             Der <classname>ViewRenderer</classname> Aktionhelfer automatisiert die Injizierung der
-            View in den Aktionkontroller genauso wie das autorendern von Viewskripten basierend auf
+            View in den Aktioncontroller genauso wie das autorendern von Viewskripten basierend auf
             die aktuelle Aktion. Das primäre Problem dem man begegnen kann ist, wenn man Aktionen
             hat die keine View Skripte rendern und weder vorwärts- noch weiterleiten, da der
             <classname>ViewRenderer</classname> versucht ein View Skript zu Rendern basierend auf
@@ -245,7 +245,7 @@ $front->setParam('noErrorHandler', true);
         <para>
             Es gibt verschiedene Strategien die man anwenden kann um den eigenen Code upzudaten. In
             kurzer Form, kann man global den <classname>ViewRenderer</classname> im eigenen
-            Frontkontroller Bootstrap vor dem Abarbeiten ausschalten:
+            Frontcontroller Bootstrap vor dem Abarbeiten ausschalten:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -261,7 +261,7 @@ $front->setParam('noViewRenderer', true);
         <para>
             Wenn man bereit ist damit zu beginnen die <classname>ViewRenderer</classname>
             Funktionalität zu verwenden, gibt es verschiedene Dinge die man im eigenen
-            Kontrollercode beachten muß. Zuerst muß auf die Aktionmethoden (die Methoden die mit
+            Controllercode beachten muß. Zuerst muß auf die Aktionmethoden (die Methoden die mit
             'Action' enden) geachtet werden, und ausgesucht werden was eine jede machen soll. Wenn
             nichts vom folgenden passiert, muß man Änderungen durchführen:
         </para>

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

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 16165 -->
+<!-- EN-Revision: 16705 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.controller.modular">
     <title>Eine konventionelle modulare Verzeichnis Struktur verwenden</title>
@@ -7,9 +7,10 @@
     <sect2 id="zend.controller.modular.introduction">
         <title>Einführung</title>
         <para>
-            Eine konventionelle modulare Verzeichnisstruktur erlaubt es verschiedene MVC Anwendungen
-            in selbst-enthaltene Einheiten zu teilen, und diese mit verschiedenen Front Kontrollern
-            wiederzuverwenden. Um so eine Verzeichnisstruktur zu zeigen:
+            Eine konventionelle modulare Verzeichnisstruktur erlaubt es verschiedene
+            <acronym>MVC</acronym> Anwendungen in selbst-enthaltene Einheiten zu teilen, und diese
+            mit verschiedenen Front Controllern wiederzuverwenden. Um so eine Verzeichnisstruktur
+            zu zeigen:
         </para>
 
         <programlisting language="txt"><![CDATA[
@@ -50,38 +51,41 @@ application/
 ]]></programlisting>
 
         <para>
-            In diesem Paradigma arbeitet der Modulname als Prefix für den Kontroller den er enthält.
-            Das obige Beispiel enthält drei Modul Kontroller, 'Blog_IndexController',
-            'News_IndexController', und 'News_ListController'. Zwei gloale Kontroller,
-            'IndexController' und 'FooController' werden auch definiert; keiner von diesen ist in
-            einem Namensraum. Diese Verzeichnisstruktur wird für die Beispiele in diesem Kapitel
-            verwendet.
+            In diesem Paradigma arbeitet der Modulname als Prefix für den Controller den er enthält.
+            Das obige Beispiel enthält drei Modul Controller,
+            '<classname>Blog_IndexController</classname>',
+            '<classname>News_IndexController</classname>', und
+            '<classname>News_ListController</classname>'. Zwei gloale Controller,
+            '<classname>IndexController</classname>' und '<classname>FooController</classname>'
+            werden auch definiert; keiner von diesen ist in einem Namensraum. Diese
+            Verzeichnisstruktur wird für die Beispiele in diesem Kapitel verwendet.
         </para>
 
         <note>
             <title>Keine Verwendung von Namensräumen im Standard Modul</title>
             <para>
-                Es ist zu beachten das Kontroller, im Standardmodul, keinen Prefix für den
-                Namensraum benötigen. Deshalb benötigt der Kontroller, im obigen Beispiel, den
+                Es ist zu beachten das Controller, im Standardmodul, keinen Prefix für den
+                Namensraum benötigen. Deshalb benötigt der Controller, im obigen Beispiel, den
                 Prefix 'Default_' nicht -- sie werden einfach dispatched gemäß dem Namen des Basis
-                Kontrollers: 'IndexController' und 'FooController'. Ein Prefix für den Namensraum
+                Controllers: '<classname>IndexController</classname>' und
+                '<classname>FooController</classname>'. Ein Prefix für den Namensraum
                 wird trotzdem in allen anderen Modulen verwendet.
             </para>
         </note>
 
         <para>
-            Also, wie kann solch ein Verzeichnislayout mit den MVC Komponenten des Zend Frameworks
-            implementiert werden?
+            Also, wie kann solch ein Verzeichnislayout mit den <acronym>MVC</acronym> Komponenten
+            des Zend Frameworks implementiert werden?
         </para>
     </sect2>
 
     <sect2 id="zend.controller.modular.directories">
-        <title>Verzeichnisse für Modul Kontroller spezifizieren</title>
+        <title>Verzeichnisse für Modul Controller spezifizieren</title>
 
         <para>
             Der erste Schritt um Module zu verwenden ist es, die Art der Spezifizierung der
-            Kontroller Verzeichnis Liste im Front Kontroller, zu Ändern. In der grundsätzlichen MVC
-            Serie, kann entweder ein Array oder ein String an
+            Controller Verzeichnis Liste im Front Controller, zu Ändern. In der grundsätzlichen
+            <acronym>MVC</acronym> Serie, kann entweder ein Array oder ein String an
             <methodname>setControllerDirectory()</methodname>, oder ein Pfad an
             <methodname>addControllerDirectory()</methodname> übergeben werden. Wenn Module
             verwendet werden, müssen die Aufrufe dieser Methoden leicht geändert werden.
@@ -89,11 +93,11 @@ application/
 
         <para>
             Mit <methodname>setControllerDirectory()</methodname>, muß ein assoziatives Array
-            übergeben und Schlüssel/Werte Paare von Modul Namen/Verzeichnis Pfaden übergeben
-            werden. Der spezielle Schlüssel <code>default</code> wird für globale Kontroller
-            verwenden (diejenigen die keinen Modul Namensraum benötigen). Alle Einträge sollten
-            einen String Schlüssel enthalten der zu einem einzelnen Pfad zeigt, und der
-            <code>default</code> Schlüssel muß vorhanden sein. Als Beispiel:
+            übergeben und Schlüssel und Werte Paare von Modul Namen und Verzeichnis Pfaden
+            übergeben werden. Der spezielle Schlüssel <property>default</property> wird für globale
+            Controller verwenden (diejenigen die keinen Modul Namensraum benötigen). Alle Einträge
+            sollten einen String Schlüssel enthalten der zu einem einzelnen Pfad zeigt, und der
+            <property>default</property> Schlüssel muß vorhanden sein. Als Beispiel:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -106,8 +110,8 @@ $front->setControllerDirectory(array(
         <para>
             <methodname>addControllerDirectory()</methodname> nimmt ein optionales zweites
             Argument. Wenn Module verwendet werden, kann der Modulname als zweites Argument
-            übergeben werden; wenn nicht spezifiziert, wird der Pfad zum <code>default</code>
-            Namensraum hinzugefügt. Als Beispiel:
+            übergeben werden; wenn nicht spezifiziert, wird der Pfad zum
+            <emphasis>default</emphasis> Namensraum hinzugefügt. Als Beispiel:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -138,19 +142,20 @@ $front->addModuleDirectory('/path/to/application/modules');
 ]]></programlisting>
 
         <para>
-            Das obige Beispiel definiert die <code>default</code>, <code>foo</code>, und
-            <code>bar</code> Module, die alle zum Unterverzeichnis <code>controllers</code> zeigen
-            und zu Ihrem betreffenden Modul.
+            Das obige Beispiel definiert die <emphasis>default</emphasis>,
+            <emphasis>foo</emphasis>, und <emphasis>bar</emphasis> Module, die alle zum
+            Unterverzeichnis <filename>controllers/</filename> zeigen und zu Ihrem betreffenden
+            Modul.
         </para>
 
         <para>
-            Das Unterverzeichnis für den Kontroller kann angepasst werden um diesen in eigenen
+            Das Unterverzeichnis für den Controller kann angepasst werden um diesen in eigenen
             Modulen mit <methodname>setModuleControllerDirectoryName()</methodname> verwenden:
         </para>
 
         <programlisting language="php"><![CDATA[
 /**
- * Das Kontroller Unterverzeichnis ändern damit es 'con' ist
+ * Das Controller Unterverzeichnis ändern damit es 'con' ist
  * application/
  *     modules/
  *         default/
@@ -165,7 +170,7 @@ $front->addModuleDirectory('/path/to/application/modules');
 ]]></programlisting>
 
         <note><para>
-            Man kann angeben das kein Kontroller Unterverzeichnis für die eigenen Module verwendet
+            Man kann angeben das kein Controller Unterverzeichnis für die eigenen Module verwendet
             wird, indem ein leerer Wert an
             <methodname>setModuleControllerDirectoryName()</methodname> übergeben wird.
         </para></note>
@@ -181,34 +186,34 @@ $front->addModuleDirectory('/path/to/application/modules');
         </para>
 
         <itemizedlist>
-            <listitem><para><code>:module/:controller/:action/*</code></para></listitem>
-            <listitem><para><code>:controller/:action/*</code></para></listitem>
+            <listitem><para><filename>:module/:controller/:action/*</filename></para></listitem>
+            <listitem><para><filename>:controller/:action/*</filename></para></listitem>
         </itemizedlist>
 
         <para>
-            In anderen Worten, wird jeder Kontroller und jede Aktion durch sich selbst entsprechen
+            In anderen Worten, wird jeder Controller und jede Aktion durch sich selbst entsprechen
             oder mit einem vorangestellten Modul. Diese Regeln für die Entsprechung spezifizieren,
             das ein Modul nur dann entspricht, wenn ein Schlüssel mit dem gleichen Namen im
-            Kontroller Verzeichnis Array existiert, das dem Front Kontroller und Dispatcher
+            Controller Verzeichnis Array existiert, das dem Front Controller und Dispatcher
             übergeben wird.
         </para>
     </sect2>
 
     <sect2 id="zend.controller.modular.defaultcontroller">
-        <title>Modul oder globaler Standard Kontroller</title>
+        <title>Modul oder globaler Standard Controller</title>
 
         <para>
-            Im Standardrouter wird der Standardkontroller verwendet
-            (<emphasis>IndexController</emphasis>, solange nicht anders angefragt), wenn kein
-            Kontroller in der URL spezifiziert wurde. Bei modularen Kontrollern wird der Dispatcher
-            zuerst für diesen Standardkontroller im Modulpfad nachsehen, wenn ein Modul aber kein
-            Kontroller spezifiziert wurde, und fällt dann auf den Standardcontroller zurück, der im
-            globalen 'default' Namensraum gefunden wird.
+            Im Standardrouter wird der StandardController verwendet
+            (<classname>IndexController</classname>, solange nicht anders angefragt), wenn kein
+            Controller in der <acronym>URL</acronym> spezifiziert wurde. Bei modularen Controllern
+            wird der Dispatcher zuerst für diesen Standardcontroller im Modulpfad nachsehen, wenn
+            ein Modul aber kein Controller spezifiziert wurde, und fällt dann auf den
+            Standardcontroller zurück, der im globalen 'default' Namensraum gefunden wird.
         </para>
 
         <para>
             Wenn immer auf den globalen Namensraum zurückgefallen werden soll, muß der
-            <varname>$useDefaultControllerAlways</varname> im Front Kontroller gesetzt werden:
+            <varname>$useDefaultControllerAlways</varname> im Front Controller gesetzt werden:
         </para>
 
         <programlisting language="php"><![CDATA[

documentation/manual/de/module_specs/Zend_Controller-Plugins-ActionStack.xml

@@ -1,21 +1,22 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 16178 -->
+<!-- EN-Revision: 16705 -->
 <!-- Reviewed: no -->
 <sect3 id="zend.controller.plugins.standard.actionstack">
     <title>ActionStack</title>
 
     <para>
         Das <emphasis>ActionStack</emphasis> Plugin erlaubt es einen Stack von Anfragen zu
-        verwalten, und operiert als <code>postDispatch</code> Plugin. Wenn eine Weiterleitung (z.B.
-        ein Aufruf zu einer anderen Aktion) bereits im aktuellen Anfrage Objekt gefunden wurde,
-        führt es nicht durch. Trotzdem, wenn nicht, prüft es seinen Stack und entfernt den obersten
-        Teil von Ihm und leitet diesen zu der Aktion weiter die in dieser Anfrage spezifiziert ist.
-        Der Stack wird in der LIFO Reihenfolge bearbeitet.
+        verwalten, und operiert als <emphasis>postDispatch</emphasis> Plugin. Wenn eine
+        Weiterleitung (z.B. ein Aufruf zu einer anderen Aktion) bereits im aktuellen Anfrage Objekt
+        gefunden wurde, führt es nicht durch. Trotzdem, wenn nicht, prüft es seinen Stack und
+        entfernt den obersten Teil von Ihm und leitet diesen zu der Aktion weiter die in dieser
+        Anfrage spezifiziert ist. Der Stack wird in der <acronym>LIFO</acronym> Reihenfolge
+        bearbeitet.
     </para>
 
     <para>
-        Das Plugin kann jederzeit vom Front Kontroller empfangen werden indem
-        <classname>Zend_Controller_Front::getPlugin('Zend_Controller_Plugin_ActionStack')</classname>
+        Das Plugin kann jederzeit vom Front Controller empfangen werden indem
+        <methodname>Zend_Controller_Front::getPlugin('Zend_Controller_Plugin_ActionStack')</methodname>
         verwendet wird. Sobald das Plugin Objekt vorliegt, gibt es eine Anzahl von Mechanisman die
         verwendet werden können, um es zu manipulieren.
     </para>
@@ -36,7 +37,7 @@
                 <methodname>getRegistryKey()</methodname> und
                 <methodname>setRegistryKey()</methodname>. Diese können verwendet werden um
                 anzuzeigen welcher Registryschlüssel verwendet wird wenn der Stack herausgenommen
-                wird. Der Standardwert ist 'Zend_Controller_Plugin_ActionStack'.
+                wird. Der Standardwert ist '<classname>Zend_Controller_Plugin_ActionStack</classname>'.
             </para>
         </listitem>
 
@@ -58,7 +59,7 @@
 
     <para>
         Eine zusätzliche Methode, <methodname>forward()</methodname>, erwartet ein Anfrageobjekt,
-        und setzt den Status des aktellen Anfrageobjektes im Front Kontroller auf den Status des
+        und setzt den Status des aktellen Anfrageobjektes im Front Controller auf den Status des
         angegebenen Anfrageobjekts, und markiert dieses als unerledigt (das forciert einen weiteren
         Durchlauf der Dispatch Schleife).
     </para>

documentation/manual/de/module_specs/Zend_Controller-Plugins-ErrorHandler.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 16178 -->
+<!-- EN-Revision: 16705 -->
 <!-- Reviewed: no -->
 <sect3 id="zend.controller.plugins.standard.errorhandler">
     <title>Zend_Controller_Plugin_ErrorHandler</title>
@@ -7,7 +7,7 @@
     <para>
         <classname>Zend_Controller_Plugin_ErrorHandler</classname> bietet ein Plugin für die
         Handhabung von Ausnahmen die von der Anwendung geworfen werden, inklusive denen die aus
-        fehlenden Kontrollern oder Aktionen resultieren; das ist eine Alternative zu den Methoden
+        fehlenden Controllern oder Aktionen resultieren; das ist eine Alternative zu den Methoden
         die in der <link linkend="zend.controller.exceptions">Sektion MVC Ausnahmen</link>
         aufgeführt sind.
     </para>
@@ -19,12 +19,12 @@
     <itemizedlist>
         <listitem>
             <para>
-                Abfangen von Ausnahmen die durch fehlende Kontroller oder Aktionsmethoden auftreten
+                Abfangen von Ausnahmen die durch fehlende Controller oder Aktionsmethoden auftreten
             </para>
         </listitem>
 
         <listitem>
-            <para>Abfangen von Ausnahmen die innerhalb von Kontrollern aufrufen</para>
+            <para>Abfangen von Ausnahmen die innerhalb von Controllern aufrufen</para>
         </listitem>
     </itemizedlist>
 
@@ -45,21 +45,21 @@
     <itemizedlist>
         <listitem>
             <para>
-                <methodname>setErrorHandlerModule()</methodname> setzt das Kontroller Modul das
+                <methodname>setErrorHandlerModule()</methodname> setzt das Controller Modul das
                 verwendet werden soll.
             </para>
         </listitem>
 
         <listitem>
             <para>
-                <methodname>setErrorHandlerController()</methodname> setzt den Kontroller der
+                <methodname>setErrorHandlerController()</methodname> setzt den Controller der
                 verwendet werden soll.
             </para>
         </listitem>
 
         <listitem>
             <para>
-                <methodname>setErrorHandlerAction()</methodname> setzt die Kontroller Aktion die
+                <methodname>setErrorHandlerAction()</methodname> setzt die Controller Aktion die
                 verwendet werden soll.
             </para>
         </listitem>
@@ -87,7 +87,7 @@
 
     <para>
         Wenn eine Ausnahme wärend der Abarbeitung des Error Handlers auftritt, teilt das Plugin dem
-        Front Kontroller mit das eine Ausnahme geworfen werden muß, und die letzte registrierte
+        Front Controller mit das eine Ausnahme geworfen werden muß, und die letzte registrierte
         Ausnahme im Antwort Objekt wird nocheinmal geworfen.
     </para>
 
@@ -96,15 +96,15 @@
 
         <para>
             Da das <emphasis>ErrorHandler</emphasis> Plugin nicht nur Anwendungsfehler erfasst,
-            sondern auch Fehler in der Kontroller Kette die durch fehlende Kontroller Klassen
+            sondern auch Fehler in der Controller Kette die durch fehlende Controller Klassen
             und/oder Aktions Methoden auftreten, kann es als 404 Handler verwendet werden. Hierfür
-            muß der eigene Fehler Kontroller den Typ der Ausnahme prüfen.
+            muß der eigene Fehler Controller den Typ der Ausnahme prüfen.
         </para>
 
         <para>
             Aufgefangene Ausnahmen werden in einem in der Anfrage registrierten Objekt geloggt. Um
             dieses zu empfangen kann
-            <classname>Zend_Controller_Action::_getParam('error_handler')</classname> verwendet
+            <methodname>Zend_Controller_Action::_getParam('error_handler')</methodname> verwendet
             werden:
         </para>
 
@@ -119,27 +119,27 @@
 
         <para>
             Sobald das Fehler Objekt vorhanden ist, kann man es über den Typ mit
-            <varname>$errors->type</varname> erhalten. Es wird eines der folgenden sein:
+            <command>$errors->type;</command> erhalten. Es wird eines der folgenden sein:
         </para>
 
         <itemizedlist>
             <listitem>
                 <para>
-                    <classname>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER</classname>,
-                    zeigt das der Kontroller nicht gefunden wurde.
+                    <constant>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER</constant>,
+                    zeigt das der Controller nicht gefunden wurde.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    <classname>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION</classname>,
+                    <constant>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION</constant>,
                     zeigt das die angefragte Aktion nicht gefunden wurde.
                 </para>
             </listitem>
 
             <listitem>
                 <para>
-                    <classname>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_OTHER</classname>,
+                    <constant>Zend_Controller_Plugin_ErrorHandler::EXCEPTION_OTHER</constant>,
                     zeigt andere Ausnahmen.
                 </para>
             </listitem>
@@ -159,7 +159,7 @@ class ErrorController extends Zend_Controller_Action
         switch ($errors->type) {
             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
-                // 404 Fehler -- Kontroller oder Aktion nicht gefunden
+                // 404 Fehler -- Controller oder Aktion nicht gefunden
                 $this->getResponse()
                      ->setRawHeader('HTTP/1.1 404 Not Found');
 
@@ -176,8 +176,8 @@ class ErrorController extends Zend_Controller_Action
 
         <para>
             Letztendlich kann die Anwendung die den Fehler Handler verursacht hat, empfangen werden
-            indem die <code>exception</code> Eigenschaft des <code>error_handler</code> Objektes
-            genommen wird:
+            indem die <property>exception</property> Eigenschaft des
+            <emphasis>error_handler</emphasis> Objektes genommen wird:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -188,7 +188,7 @@ public function errorAction()
         switch ($errors->type) {
             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
-                // 404 Fehler -- Kontroller oder Aktion nicht gefunden
+                // 404 Fehler -- Controller oder Aktion nicht gefunden
                 $this->getResponse()
                      ->setRawHeader('HTTP/1.1 404 Not Found');
 
@@ -274,10 +274,10 @@ $front->registerPlugin($plugin);
     </sect4>
 
     <sect4 id="zend.controller.plugins.standard.errorhandler.controllerexamples">
-        <title>Beispiel für den Fehler Kontroller</title>
+        <title>Beispiel für den Fehler Controller</title>
 
         <para>
-            Um das Fehler Handler Plugin zu verwenden, benötigt man einen Fehler Kontroller.
+            Um das Fehler Handler Plugin zu verwenden, benötigt man einen Fehler Controller.
             Nachfolgend ist ein einfaches Beispiel.
         </para>
 
@@ -291,7 +291,7 @@ class ErrorController extends Zend_Controller_Action
         switch ($errors->type) {
             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_CONTROLLER:
             case Zend_Controller_Plugin_ErrorHandler::EXCEPTION_NO_ACTION:
-                // 404 Fehler -- Kontroller oder Aktion nicht gefunden
+                // 404 Fehler -- Controller oder Aktion nicht gefunden
                 $this->getResponse()->setRawHeader('HTTP/1.1 404 Not Found');
 
                 $content =<<<EOH

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

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 16595 -->
+<!-- EN-Revision: 16705 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.controller.plugins" xmlns:xi="http://www.w3.org/2001/XInclude">
     <title>Plugins</title>
@@ -53,7 +53,7 @@
                     aufgerufen, bevor eine Aktion verarbeitet wird. Dieser Callback erlaubt ein
                     Proxy oder Filter Verhalten. Durch Verändern des Requests und Zurücksetzen
                     des Verarbeitungsstatus (mittels
-                    <classname>Zend_Controller_Request_Abstract::setDispatched(false)</classname>)
+                    <methodname>Zend_Controller_Request_Abstract::setDispatched(false)</methodname>)
                     kann die aktuelle Aktion abgebrochen oder ersetzt werden.
                 </para>
             </listitem>
@@ -65,7 +65,7 @@
                     aufgerufen, nachdem eine Aktion verarbeitet wurde. Dieser Callback erlaubt ein
                     Proxy oder Filter Verhalten. Durch Verändern des Requests und Zurücksetzen
                     des Verarbeitungsstatus (mittels
-                    <classname>Zend_Controller_Request_Abstract::setDispatched(false)</classname>)
+                    <methodname>Zend_Controller_Request_Abstract::setDispatched(false)</methodname>)
                     kann eine neue Aktion für die Verarbeitung angegeben werden.
                 </para>
             </listitem>
@@ -114,9 +114,10 @@ class MyPlugin extends Zend_Controller_Plugin_Abstract
         <title>Plugins verwenden</title>
 
         <para>
-            Plugin Klassen werden mit <classname>Zend_Controller_Front::registerPlugin()</classname>
-            registriert und können jederzeit registriert werden. Der folgende Schnipsel zeigt,
-            wie ein Plugin in der Controllerkette verwendet werden kann:
+            Plugin Klassen werden mit
+            <methodname>Zend_Controller_Front::registerPlugin()</methodname> registriert und können
+            jederzeit registriert werden. Der folgende Schnipsel zeigt, wie ein Plugin in der
+            Controllerkette verwendet werden kann:
         </para>
 
         <programlisting language="php"><![CDATA[
@@ -184,7 +185,7 @@ $front->dispatch();
 
         <note>
             <para>
-                Plugins können jederzeit wärend der Ausführung des Frontkontrollers registriert
+                Plugins können jederzeit wärend der Ausführung des Frontcontrollers registriert
                 werden. Wenn trotzdem ein Event ausgeführt wurde für das das Plugin eine
                 registrierte Eventmethode enthält, wird diese Methode nicht getriggert.
             </para>
@@ -196,15 +197,15 @@ $front->dispatch();
 
         <para>
             Fallweise kann es notwendig sein ein Plugin zu entfernen oder empfangen. Die folgenden
-            Methoden des Frontkontrollers erlauben dies:
+            Methoden des Frontcontrollers erlauben dies:
         </para>
 
         <itemizedlist>
             <listitem><para>
                     <methodname>getPlugin($class)</methodname> erlaubt es ein Plugin durch den
-                    Klassennamen zu empfangen. Wenn kein Plugin entspricht, wird false
-                    zurückgegeben. Wenn mehr als ein Plugin dieser Klasse registriert ist, wird ein
-                    Array zurückgegeben.
+                    Klassennamen zu empfangen. Wenn kein Plugin entspricht, wird
+                    <constant>FALSE</constant> zurückgegeben. Wenn mehr als ein Plugin dieser
+                    Klasse registriert ist, wird ein Array zurückgegeben.
             </para></listitem>
 
             <listitem><para>

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

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<!-- EN-Revision: 16178 -->
+<!-- EN-Revision: 16705 -->
 <!-- Reviewed: no -->
 <sect1 id="zend.controller.quickstart">
     <title>Zend_Controller Schnellstart</title>
@@ -7,14 +7,15 @@
     <sect2 id="zend.controller.quickstart.introduction">
         <title>Einführung</title>
         <para>
-            <classname>Zend_Controller</classname> ist das Herz des MVC-Systems des Zend Framework.
-            MVC bedeutet <ulink
+            <classname>Zend_Controller</classname> ist das Herz des <acronym>MVC</acronym> Systems
+            des Zend Frameworks. <acronym>MVC</acronym> bedeutet <ulink
                 url="http://de.wikipedia.org/wiki/Model_View_Controller">Model-View-Controller</ulink>
             und ist ein Entwurfsmuster, das darauf abzielt, Anwendungslogik von Anzeigelogik zu trennen.
             <classname>Zend_Controller_Front</classname> implementiert ein <ulink
                 url="http://www.martinfowler.com/eaaCatalog/frontController.html">Front-Controller</ulink>-Entwurfsmuster,
             das vorschreibt, dass alle Anfragen vom Front-Controller abgefangen und abhängig von der
-            angeforderten URL an individuelle Action-Controller weitergeleitet werden.
+            angeforderten <acronym>URL</acronym> an individuelle Action-Controller weitergeleitet
+            werden.
         </para>
         <para>
             Das <classname>Zend_Controller</classname> System wurde im Sinne der
@@ -66,7 +67,8 @@ html/
 
             <para>
                 Der Webserver ist so zu konfigurieren, dass das Wurzelverzeichnis (Document Root)
-                des Webservers im <code>html</code>-Verzeichnis der obigen Ordnerstruktur liegt.
+                des Webservers im <filename>html/</filename>-Verzeichnis der obigen Ordnerstruktur
+                liegt.
             </para>
         </sect3>
 
@@ -101,7 +103,8 @@ RewriteRule ^.*$ index.php [NC,L]
             </note>
 
             <para>
-                Wenn man IIS 7.0 verwendet, sollte man die folgende Rewrite Konfiguration verwenden:
+                Wenn man <acronym>IIS</acronym> 7.0 verwendet, sollte man die folgende Rewrite
+                Konfiguration verwenden:
             </para>
 
             <programlisting language="xml"><![CDATA[
@@ -171,16 +174,17 @@ Zend_Controller_Front::run('/path/to/app/controllers');
 
             <para>
                 Bevor wir von Action-Controllern reden, sollte erst verstanden werden, wie Anfragen
-                im Zend Framework behandelt werden. Standardmäßig zeigt das erste Segment eines URL
-                auf einen Controller und das zweite Segment auf eine Aktion, die dieser Controller
-                ausführen soll. Als Beispiel sei der URL
+                im Zend Framework behandelt werden. Standardmäßig zeigt das erste Segment eines
+                <acronym>URL</acronym> auf einen Controller und das zweite Segment auf eine Aktion,
+                die dieser Controller ausführen soll. Als Beispiel sei der <acronym>URL</acronym>
                 <filename>http://framework.zend.com/roadmap/components</filename> gegeben. Der Pfad
                 ist <filename>/roadmap/components</filename>, was die Anfrage zum Controller
-                <code>roadmap</code> und dort in die Aktion <code>components</code> leitet. Wenn
-                keine Aktion angegeben wird, wird <code>index</code> als Standard-Aktion angenommen,
-                und wenn kein Controller angegeben wird, wird auch <code>index</code> als
-                Standard-Controller angenommen. (Das folgt der Apache-Konvention, die einen
-                <code>DirectoryIndex</code> automatisch findet).
+                <emphasis>roadmap</emphasis> und dort in die Aktion <emphasis>components</emphasis>
+                leitet. Wenn keine Aktion angegeben wird, wird <emphasis>index</emphasis> als
+                Standard-Aktion angenommen, und wenn kein Controller angegeben wird, wird auch
+                <emphasis>index</emphasis> als Standard-Controller angenommen. (Das folgt der
+                Apache-Konvention, die einen <emphasis>DirectoryIndex</emphasis> automatisch
+                findet).
             </para>
 
             <para>
@@ -188,25 +192,26 @@ Zend_Controller_Front::run('/path/to/app/controllers');
                 als Controller angegeben ist, und schließt daraus auf eine passende Klasse. In der
                 normalen Einstellung des Dispatchers wird der erste Buchstabe jedes Wortes im
                 Controller-Namen groß geschrieben (Title-case), und dann das Wort
-                <code>Controller</code> angehängt. Das bedeutet für unser Beispiel, dass die Anfrage
-                nach dem Controller <code>roadmap</code> an die Klasse
-                <code>RoadmapController</code> weitergeleitet wird.
+                <emphasis>Controller</emphasis> angehängt. Das bedeutet für unser Beispiel, dass
+                die Anfrage nach dem Controller <emphasis>roadmap</emphasis> an die Klasse
+                <classname>RoadmapController</classname> weitergeleitet wird.
             </para>
 
             <para>
                 Auf ähnliche Art wird die Methode für die Aktion bestimmt, die der Controller
                 ausführen soll. In der Grundeinstellung wird die angefragte Aktion komplett
-                kleingeschrieben und das Wort <code>Action</code> wird angehängt. In unserem
-                Beispiel wird also die Aktion <code>components</code> zu
-                <code>componentsAction</code>, insgesamt wird also die Methode
+                kleingeschrieben und das Wort <emphasis>Action</emphasis> wird angehängt. In
+                unserem Beispiel wird also die Aktion <emphasis>components</emphasis> zu
+                <methodname>componentsAction()</methodname>, insgesamt wird also die Methode
                 <methodname>RoadmapController::componentsAction()</methodname> aufgerufen.
             </para>
 
             <para>
                 Also, weiter gehts. Jetzt wird ein Startseiten-Controller und eine dazugehörige
                 Standard-Aktionsmethode erstellt. Wie vorhin bereits erwähnt, heißen
-                Standard-Controller und -Aktion beide <code>index</code>. Also gehört in die Datei
-                <filename>application/controllers/IndexController.php</filename> folgendes:
+                Standard-Controller und -Aktion beide <emphasis>index</emphasis>. Also gehört in
+                die Datei <filename>application/controllers/IndexController.php</filename>
+                folgendes:
             </para>
 
             <programlisting language="php"><![CDATA[
@@ -224,17 +229,18 @@ class IndexController extends Zend_Controller_Action
                     linkend="zend.controller.actionhelpers.viewrenderer">ViewRenderer</link>
                 eingeschaltet. Das bedeutet, dass sofort, wenn eine leere Aktionsmethode und ein
                 passendes View-Script existieren, Inhalte gerendert werden. Standardmäßig wird die
-                Klasse <classname>Zend_View</classname> als View-Schicht im Zend-Framework MVC
-                verwendet. Der <emphasis>ViewRenderer</emphasis> zaubert ein wenig, und benutzt
-                Controller- (hier: <code>index</code>) und Aktionsname (hier: <code>index</code>),
-                um herauszufinden, welches Template er rendern soll. Ohne dass man dies ändert,
-                haben Templates die Dateiendung <filename>.phtml</filename>, das heißt also für
-                unser Beispiel, dass das Template <filename>index/index.phtml</filename> gerendert
-                wird. Zusätzlich nimmt der <emphasis>ViewRenderer</emphasis> automatisch an, dass
-                das Verzeichnis <code>views</code> auf der selben Ebene wie das Controller
-                Verzeichnis das View-Basisverzeichnis ist, und dass die eigentlichen View-Scripts
-                in dessen Unterverzeichnis <filename>views/scripts/</filename> liegen. Insgesamt
-                hat also das Template, das gerendert wird, den Pfad
+                Klasse <classname>Zend_View</classname> als View-Schicht im Zend-Framework
+                <acronym>MVC</acronym> verwendet. Der <emphasis>ViewRenderer</emphasis> zaubert ein
+                wenig, und benutzt Controller- (hier: <emphasis>index</emphasis>) und Aktionsname
+                (hier: <emphasis>index</emphasis>), um herauszufinden, welches Template er rendern
+                soll. Ohne dass man dies ändert, haben Templates die Dateiendung
+                <filename>.phtml</filename>, das heißt also für unser Beispiel, dass das Template
+                <filename>index/index.phtml</filename> gerendert wird. Zusätzlich nimmt der
+                <emphasis>ViewRenderer</emphasis> automatisch an, dass das Verzeichnis
+                <filename>views/</filename> auf der selben Ebene wie das Controller Verzeichnis das
+                View-Basisverzeichnis ist, und dass die eigentlichen View-Scripts in dessen
+                Unterverzeichnis <filename>views/scripts/</filename> liegen. Insgesamt hat also das
+                Template, das gerendert wird, den Pfad
                 <filename>application/views/scripts/index/index.phtml</filename>.
             </para>
         </sect3>
@@ -248,7 +254,7 @@ class IndexController extends Zend_Controller_Action
                 <filename>application/views/scripts/</filename> abgelegt; das View-Script für den
                 Starseiten-Controller und dessen Standard-Aktion hat den Pfad
                 <filename>application/views/scripts/index/index.phtml</filename>. Da hinein kommt
-                das folgende HTML:
+                das folgende <acronym>HTML</acronym>:
             </para>
 
             <programlisting language="php"><![CDATA[
@@ -322,7 +328,8 @@ PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
                 Jetzt, wo der erste Controller und das erste View-Script geschrieben sind, kann der
                 Browser aufgerufen und die Seite angesehen werden. Wäre
                 <filename>example.com</filename> die Domain der Zend Framework-Installation, dann
-                würde jeder der folgenden URLs auf die Seite zeigen, die wir gerade erstellt haben:
+                würde jeder der folgenden <acronym>URL</acronym>s auf die Seite zeigen, die wir
+                gerade erstellt haben:
             </para>
 
             <itemizedlist>

documentation/manual/de/module_specs/Zend_Controller-Router-Route-Chain.xml

@@ -16,8 +16,8 @@
         <para>
             Wenn Routen wie die Hostnameroute und die Pfadroute zusammengekettet werden, haben die
             Parameter der Hostnameroute eine höhere Priorität als die Parameter der Pfadroute.
-            Deshalb wird, wenn man im Hostnamen und in der Pfadroute einen Kontroller definiert,
-            der Kontroller der Hostnameroute ausgewählt.
+            Deshalb wird, wenn man im Hostnamen und in der Pfadroute einen Controller definiert,
+            der Controller der Hostnameroute ausgewählt.
         </para>
     </note>
 

documentation/manual/de/module_specs/Zend_Controller-Router-Route-Static.xml

@@ -46,7 +46,7 @@ $router->addRoute('login', $route);
         </itemizedlist>
 
         <para>
-            Optional kann auch der "useDefaultControllerAlways" Parameter an den Frontkontroller
+            Optional kann auch der "useDefaultControllerAlways" Parameter an den Frontcontroller
             wärend des Bootstrappings übergeben werden:
         </para>
 

documentation/manual/de/module_specs/Zend_Controller-Router-Route.xml

@@ -126,11 +126,11 @@ $router->addRoute('archive', $route);
 
         <para>
             Dieses Beispiel resultiert darin das eine year Variable in das Anfrage Objekt injiziiert
-            wird. Da keine Routinginformation vorhanden ist (es sind keine Kontroller und
-            Aktionsparameter definiert), wird die Anwendung zum Standardkontroller und der
+            wird. Da keine Routinginformation vorhanden ist (es sind keine Controller und
+            Aktionsparameter definiert), wird die Anwendung zum Standardcontroller und der
             Aktionsmethode (welche beide in
             <classname>Zend_Controller_Dispatcher_Abstract</classname> definiert sind)
-            weitergeleitet. Um es verwendbarer zu machen muß ein gültiger Kontroller und eine
+            weitergeleitet. Um es verwendbarer zu machen muß ein gültiger Controller und eine
             gültige aktion als Standard für die Route angegeben werden:
         </para>
 

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

@@ -242,7 +242,7 @@ $router->addRoute('user',
         <para>
             Es gibt drei spezielle Variablen welche in den Routen verwendet werden können -
             'module', 'controller' und 'action'. Diese speziellen Variablen werden durch
-            <classname>Zend_Controller_Dispatcher</classname> verwendet um einen Kontroller und die
+            <classname>Zend_Controller_Dispatcher</classname> verwendet um einen Controller und die
             Aktion zu funden zu der verwiesen wird.
         </para>
 

documentation/manual/de/module_specs/Zend_Dojo-BuildLayers.xml

@@ -0,0 +1,427 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- EN-Revision: 16720 -->
+<!-- Reviewed: no -->
+<sect1 id="zend.dojo.build-layers">
+    <title>Zend_Dojo build layer support</title>
+
+    <sect2 id="zend.dojo.build-layers.introduction">
+        <title>Einführung</title>
+
+        <para>
+            Dojo build layers provide a clean path from development to
+            production when using Dojo for your UI layer. In development, you
+            can have load-on-demand, rapid application prototyping; a build
+            layer takes all Dojo dependencies and compiles them to a single
+            file, optionally stripping whitespace and comments, and performing
+            code heuristics to allow further minification of variable names.
+            Additionally, it can do <acronym>CSS</acronym> minification.
+        </para>
+
+        <para>
+            In order to create a build layer, you would traditionally create a
+            JavaScript file that has <code>dojo.require</code> statements for
+            each dependency, and optionally some additional code that might run
+            when the script is loaded. As an example:
+        </para>
+
+        <programlisting language="javascript"><![CDATA[
+dojo.provide("custom.main");
+
+dojo.require("dijit.layout.TabContainer");
+dojo.require("dijit.layout.ContentPane");
+dojo.require("dijit.form.Form");
+dojo.require("dijit.form.Button");
+dojo.require("dijit.form.TextBox");
+]]></programlisting>
+
+        <para>
+            This script is generally referred to as a "layer" script.
+        </para>
+
+        <para>
+            Then, in your application's layout, you'd instruct Dojo to load this
+            module:
+        </para>
+
+        <programlisting language="html"><![CDATA[
+<html>
+<head>
+    <script type="text/javascript" src="/js/dojo/dojo.js"></script>
+    <script type="text/javascript">
+        dojo.registerModulePath("custom", "../custom/");
+        dojo.require("custom.main");
+    </script>
+]]></programlisting>
+
+        <para>
+            If you use <classname>Zend_Dojo</classname> to do this, you'd do the
+            following:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$view->dojo()->registerModulePath('custom', '../custom/')
+             ->requireModule('custom.main');
+]]></programlisting>
+
+        <para>
+            But since <classname>Zend_Dojo</classname> aggregates your various
+            <code>dojo.require</code> statements, how do you create your layer
+            script? You could open each page and view the generated
+            <code>dojo.require</code> statements, and cut and paste them into a
+            layer script file manually.
+        </para>
+
+        <para>
+            However, a better solution exists: since
+            <classname>Zend_Dojo</classname> aggregates this information
+            already, you can simply pull that information and build your layer
+            file. This is the purpose of
+            <classname>Zend_Dojo_BuildLayer</classname>.
+        </para>
+    </sect2>
+
+    <sect2 id="zend.dojo.build-layers.usage">
+        <title>Generating Custom Module Layers with Zend_Dojo_BuildLayer</title>
+
+        <para>
+            At its simplest, you simply instantiate
+            <classname>Zend_Dojo_BuildLayer</classname>, feed it the view object
+            and the name of your custom module layer, and have it generate the
+            content of the layer file; it is up to you to then write it to disk.
+        </para>
+
+        <para>
+            As an example, let's say you wanted to create the module layer
+            "custom.main". Assuming you follow the recommended project directory
+            structure, and that you are storing your JavaScript files under
+            <filename>public/js/</filename>, you could do the following:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$build = new Zend_Dojo_BuildLayer(array(
+    'view'      => $view,
+    'layerName' => 'custom.main',
+));
+
+$layerContents = $build->generateLayerScript();
+$filename      = APPLICATION_PATH . '/../public/js/custom/main.js';
+if (!dir_exists(dirname($filename))) {
+    mkdir(dirname($filename));
+}
+file_put_contents($filename, $layerContents);
+]]></programlisting>
+
+        <para>
+            When should you do the above? For it to work correctly, you need to
+            do it after all view scripts and the layout have been rendered, to
+            ensure that the <methodname>dojo()</methodname> helper is fully populated. One
+            easy way to do so is using a front controller plugin, with a
+            <methodname>dispatchLoopShutdown()</methodname> hook:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+class App_Plugin_DojoLayer extends Zend_Controller_Plugin_Abstract
+{
+    public $layerScript = APPLICATION_PATH . '/../public/js/custom/main.js';
+    protected $_build;
+
+    public function dispatchLoopShutdown()
+    {
+        if (!file_exists($this->layerScript)) {
+            $this->generateDojoLayer();
+        }
+    }
+
+    public function getBuild()
+    {
+        if (null === $this->_build) {
+            $this->_build = new Zend_Dojo_BuildLayer(array(
+                'view'      => $view,
+                'layerName' => 'custom.main',
+            ));
+        }
+        return $this->_build;
+    }
+
+    public function generateDojoLayer()
+    {
+        $build = $this->getBuild();
+        $layerContents = $build->generateLayerScript();
+        if (!dir_exists(dirname($this->layerScript))) {
+            mkdir(dirname($this->layerScript));
+        }
+        file_put_contents($this->layerScript, $layerContents);
+    }
+}
+]]></programlisting>
+
+        <note>
+            <title>Do not generate the layer on every page</title>
+
+            <para>
+                It's tempting to generate the layer script on each and every
+                page. However, this is resource intensive, as it must write to
+                the disk on each page. Additionally, since the mtime of the file
+                will keep changing, you will get no benefits of client-side
+                caching. Write the file once.
+            </para>
+        </note>
+
+        <sect3 id="zend.dojo.build-layers.usage.options">
+            <title>BuildLayer options</title>
+
+            <para>
+                The above functionality will suffice for most situations. For
+                those needing more customization, a variety of options may be
+                invoked.
+            </para>
+
+            <sect4 id="zend.dojo.build-layers.usage.options.view">
+                <title>Setting the view object</title>
+
+                <para>
+                    While the view object may be passed during instantiation,
+                    you may also pass it in to an instance via the
+                    <methodname>setView()</methodname> method:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$build->setView($view);
+]]></programlisting>
+            </sect4>
+
+            <sect4 id="zend.dojo.build-layers.usage.options.layername">
+                <title>Setting the layer name</title>
+
+                <para>
+                    While the layer name may be passed during instantiation,
+                    you may also pass it in to an instance via the
+                    <methodname>setLayerName()</methodname> method:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$build->setLayerName("custom.main");
+]]></programlisting>
+            </sect4>
+
+            <sect4 id="zend.dojo.build-layers.usage.options.onload">
+                <title>Including onLoad events in the generated layer</title>
+
+                <para>
+                    <code>dojo.addOnLoad</code> is a useful utility for
+                    specifying actions that should trigger when the <acronym>DOM</acronym> has
+                    finished loading. The <methodname>dojo()</methodname> view helper can
+                    create these statements via its
+                    <methodname>addOnLoad()</methodname> and
+                    <methodname>onLoadCapture*()</methodname> methods. In some
+                    cases, it makes sense to push these into your layer file
+                    instead of rendering them via your view scripts.
+                </para>
+
+                <para>
+                    By default, these are not rendered; to enable them, pass the
+                    <property>consumeOnLoad</property> configuration key during
+                    instantiation:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$build = new Zend_Dojo_BuildLayer(array(
+    'view'          => $view,
+    'layerName'     => 'custom.main',
+    'consumeOnLoad' => true,
+));
+]]></programlisting>
+
+                <para>
+                    Alternately, you can use the
+                    <methodname>setConsumeOnLoad()</methodname> method after
+                    instantiation:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$build->setConsumeOnLoad(true);
+]]></programlisting>
+            </sect4>
+
+            <sect4 id="zend.dojo.build-layers.usage.options.javascript">
+                <title>Including captured JavaScript in the generated layer</title>
+
+                <para>
+                    The <methodname>dojo()</methodname> view helper includes methods for
+                    capturing arbitrary JavaScript to include in the
+                    &lt;script&gt; tag containing the various
+                    <code>dojo.require</code> and <code>dojo.addOnLoad</code>
+                    statements. This can be useful when creating default data
+                    stores or globally scoped objects used throughout your
+                    application.
+                </para>
+
+                <para>
+                    By default, these are not rendered; to enable them, pass the
+                    <property>consumeJavascript</property> configuration key during
+                    instantiation:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$build = new Zend_Dojo_BuildLayer(array(
+    'view'              => $view,
+    'layerName'         => 'custom.main',
+    'consumeJavascript' => true,
+));
+]]></programlisting>
+
+                <para>
+                    Alternately, you can use the
+                    <methodname>setConsumeJavascript()</methodname> method after
+                    instantiation:
+                </para>
+
+                <programlisting language="php"><![CDATA[
+$build->setConsumeJavascript(true);
+]]></programlisting>
+            </sect4>
+        </sect3>
+    </sect2>
+
+    <sect2 id="zend.dojo.build-layers.profiles">
+        <title>Generating Build Profiles with Zend_Dojo_BuildLayer</title>
+
+        <para>
+            One of the chief benefits of a Dojo module layer is that it
+            facilitates the creation of a custom build.
+            <classname>Zend_Dojo_BuildLayer</classname> has functionality for
+            generate build profiles.
+        </para>
+
+        <para>
+            The simplest use case is to utilize the
+            <methodname>generateBuildProfile()</methodname> method and send the
+            output to a file:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$build = new Zend_Dojo_BuildLayer(array(
+    'view'      => $view,
+    'layerName' => 'custom.main',
+));
+
+$profile   = $build->generateBuildProfile();
+$filename  = APPLICATION_PATH . '/../misc/scripts/custom.profile.js';
+file_put_contents($filename, $profile);
+]]></programlisting>
+
+        <para>
+            Just like generating layers, you may want to automate this via a
+            <methodname>dispatchLoopShutdown()</methodname> plugin hook; you
+            could even simply modify the one shown for generating layers to read
+            as follows:
+        </para>
+
+        <programlisting language="php"><![CDATA[
+class App_Plugin_DojoLayer extends Zend_Controller_Plugin_Abstract
+{
+    public $layerScript  = APPLICATION_PATH
+                         . '/../public/js/custom/main.js';
+    public $buildProfile = APPLICATION_PATH
+                         . '/../misc/scripts/custom.profile.js';
+    protected $_build;
+
+    public function dispatchLoopShutdown()
+    {
+        if (!file_exists($this->layerScript)) {
+            $this->generateDojoLayer();
+        }
+        if (!file_exists($this->buildProfile)) {
+            $this->generateBuildProfile();
+        }
+    }
+
+    public function generateDojoLayer() { /* ... */ }
+
+    public function generateBuildProfile()
+    {
+        $profile = $this->getBuild()->generateBuildProfile();
+        file_put_contents($this->buildProfile, $profile);
+    }
+
+}
+]]></programlisting>
+
+        <para>
+            As noted, with module layers, you should only create the file once.
+        </para>
+
+        <sect3 id="zend.dojo.build-layers.profiles.options">
+            <title>Build Profile options</title>
+
+            <para>
+                The above functionality will suffice for most situations. The
+                only way to customize build profile generation is to provide
+                additional build profile options to utilize.
+            </para>
+
+            <para>
+                As an example, you may want to specify what type of
+                optimizations should be performed, whether or not to optimize
+                <acronym>CSS</acronym> files in the layer, whether or not to copy tests into the
+                build, etc. For a listing of available options, you should read
+                the <ulink url="http://docs.dojocampus.org/build/index">Dojo
+                    Build documentation</ulink> and <ulink
+                    url="http://www.dojotoolkit.org/book/dojo-book-0-9/part-4-meta-dojo/package-system-and-custom-builds">accompanying
+                documentation</ulink>.
+            </para>
+
+            <para>
+                Setting these options is trivial: use the
+                <methodname>addProfileOption()</methodname>,
+                <methodname>addProfileOptions()</methodname>, or
+                <methodname>setProfileOptions()</methodname> methods. The first
+                method adds a single key and value option pair, the second will add
+                several, and the third will overwrite any options with the list
+                of key and value pairs provided.
+            </para>
+
+            <para>
+                By default, the following options are set:
+            </para>
+
+            <programlisting language="javascript"><![CDATA[
+{
+    action:        "release",
+    optimize:      "shrinksafe",
+    layerOptimize: "shrinksafe",
+    copyTests:     false,
+    loader:        "default",
+    cssOptimize:   "comments"
+}
+]]></programlisting>
+
+            <para>
+                You can pass in whatever key and value pairs you want; the Dojo
+                build script will ignore those it does not understand.
+            </para>
+
+            <para>
+                As an example of setting options:
+            </para>
+
+            <programlisting language="php"><![CDATA[
+// A single option:
+$build->addProfileOption('version', 'zend-1.3.1');
+
+// Several options:
+$build->addProfileOptions(array(
+    'loader'   => 'xdomain',
+    'optimize' => 'packer',
+));
+
+// Or overwrite options:
+$build->setProfileOptions(array(
+    'version'  => 'custom-1.3.1',
+    'loader'   => 'shrinksafe',
+    'optimize' => 'shrinksafe',
+));
+]]></programlisting>
+        </sect3>
+    </sect2>
+</sect1>

documentation/manual/de/module_specs/Zend_Feed_Reader.xml

@@ -0,0 +1,1342 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- EN-Revision: 16721 -->
+<!-- Reviewed: no -->
+<sect1 id="zend.feed.reader">
+    <title>Zend_Feed_Reader</title>
+
+    <sect2 id="zend.feed.reader.introduction">
+        <title>Introduction</title>
+
+        <para>
+            <classname>Zend_Feed_Reader</classname> is a component used to
+            consume <acronym>RSS</acronym> and Atom feeds of any version, including
+            <acronym>RDF</acronym>/<acronym>RSS</acronym> 1.0,
+            <acronym>RSS</acronym> 2.0 and Atom 0.3/1.0. The <acronym>API</acronym> for
+            retrieving feed data is
+            deliberately simple since <classname>Zend_Feed_Reader</classname> is
+            capable of searching any feed of any type for the information
+            requested through the <acronym>API</acronym>. If the typical elements containing this
+            information are not present, it will adapt and fall back on a
+            variety of alternative elements instead. This ability to choose from
+            alternatives removes the need for users to create their own
+            abstraction layer on top of the component to make it useful or have
+            any in-depth knowledge of the underlying standards, current
+            alternatives, and namespaced extensions.
+        </para>
+
+        <para>
+            Internally, <classname>Zend_Feed_Reader</classname> works almost
+            entirely on the basis of making XPath queries against the feed <acronym>XML</acronym>'s
+            Document Object Model. The <acronym>DOM</acronym> is not exposed though a chained
+            property <acronym>API</acronym> like <classname>Zend_Feed</classname> though the
+            underlying <classname>DOMDocument</classname>,
+            <classname>DOMElement</classname> and
+            <classname>DOMXPath</classname> objects are exposed for external
+            manipulation. This singular approach to parsing is consistent and
+            the component offers a plugin system to add to the Feed and Entry
+            level <acronym>API</acronym> by writing Extensions on a similar basis.
+        </para>
+
+        <para>
+            Performance is assisted in three ways. First of all,
+            <classname>Zend_Feed_Reader</classname> supports caching using
+            <classname>Zend_Cache</classname> to maintain a copy of the original
+            feed <acronym>XML</acronym>. This allows you to skip network requests for a feed
+            <acronym>URI</acronym> if
+            the cache is valid. Second, the Feed and Entry level <acronym>API</acronym> is backed
+            by an internal cache (non-persistant) so repeat <acronym>API</acronym> calls for the
+            same feed will avoid additional <acronym>DOM</acronym>/XPath use. Thirdly, importing
+            feeds from a <acronym>URI</acronym> can take advantage of
+            <acronym>HTTP</acronym> Conditional GET requests
+            which allow servers to issue an empty 304 response when the
+            requested feed has not changed since the last time you requested it.
+            In the final case, an instance of <classname>Zend_Cache</classname>
+            will hold the last received feed along with the ETag and
+            Last-Modified header values sent in the <acronym>HTTP</acronym> response.
+        </para>
+
+        <para>
+            In relation to <classname>Zend_Feed</classname>,
+            <classname>Zend_Feed_Reader</classname> was formulated as a free
+            standing replacement for <classname>Zend_Feed</classname> but it is
+            not backwards compatible with <classname>Zend_Feed</classname>.
+            Rather it is an alternative following a different ideology focused
+            on being simple to use, flexible, consistent and extendable through
+            the plugin system. <classname>Zend_Feed_Reader</classname> is also
+            not capable of constructing feeds through this will be addressed at
+            a future date.
+        </para>
+    </sect2>
+
+    <sect2 id="zend.feed.reader.import">
+        <title>Importing Feeds</title>
+
+        <para>
+            Importing a feed with <classname>Zend_Feed_Reader</classname> is not
+            that much different to <classname>Zend_Feed</classname>. Feeds can
+            be imported from a string, file, <acronym>URI</acronym> or an instance of type
+            <classname>Zend_Feed_Abstract</classname>. Importing from a <acronym>URI</acronym> can
+            additionally utilise a <acronym>HTTP</acronym> Conditional GET request. If importing
+            fails, an exception will be raised. The end result will be an object
+            of type <classname>Zend_Feed_Reader_FeedInterface</classname>, the
+            core implementations of which are
+            <classname>Zend_Feed_Reader_Feed_Rss</classname> and
+            <classname>Zend_Feed_Reader_Feed_Atom</classname>
+            (<classname>Zend_Feed</classname> took all the short names!). Both
+            objects support multiple (all existing) versions of these broad feed
+            types.
+        </para>
+
+        <para>
+            In the following example, we import an <acronym>RDF</acronym>/<acronym>RSS</acronym> 1.0
+            feed and extract some basic information that can be saved to a database or
+            elsewhere.
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$feed = Zend_Feed_Reader::import('http://www.planet-php.net/rdf/');
+$data = array(
+    'title'        => $feed->getTitle(),
+    'link'         => $feed->getLink(),
+    'dateModified' => $feed->getDateModified(),
+    'description'  => $feed->getDescription(),
+    'language'     => $feed->getLanguage(),
+    'entries'      => array(),
+);
+
+foreach ($feed as $entry) {
+    $edata = array(
+        'title'        => $entry->getTitle(),
+        'description'  => $entry->getDescription(),
+        'dateModified' => $entry->getDateModified(),
+        'author'       => $entry->getAuthor(),
+        'link'         => $entry->getLink(),
+        'content'      => $entry->getContent()
+    );
+    $data['entries'][] = $edata;
+}
+]]></programlisting>
+
+        <para>
+            The example above demonstrates
+            <classname>Zend_Feed_Reader</classname>'s <acronym>API</acronym>, and it also
+            demonstrates some of it's internal operation. In reality, the <acronym>RDF</acronym>
+            feed selected does not have any native date or author elements,
+            however it does utilise the Dublin Core 1.1 module which offers
+            namespaced creator and date elements.
+            <classname>Zend_Feed_Reader</classname> falls back on these and
+            similar options if no relevant native elements exist. If it
+            absolutely cannot find an alternative it will return <constant>NULL</constant>,
+            indicating the information could not be found in the feed. You
+            should note that classes implementing
+            <classname>Zend_Feed_Reader_FeedInterface</classname> also implement
+            the <acronym>SPL</acronym> <classname>Iterator</classname> and
+            <classname>Countable</classname> interfaces.
+        </para>
+
+        <para>
+            Feeds can also be imported from strings, files, and even objects of
+            type <classname>Zend_Feed_Abstract</classname>.
+        </para>
+
+        <programlisting language="php"><![CDATA[
+// from a URI
+$feed = Zend_Feed_Reader::import('http://www.planet-php.net/rdf/');
+
+// from a String
+$feed = Zend_Feed_Reader::importString($feedXmlString);
+
+// from a file
+$feed = Zend_Feed_Reader::importFile('./feed.xml');
+
+// from a Zend_Feed_Abstract object
+$zfeed = Zend_Feed::import('http://www.planet-php.net/atom/');
+$feed  = Zend_Feed_Reader::importFeed($zfeed);
+]]></programlisting>
+    </sect2>
+
+    <sect2 id="zend.feed.reader.sources">
+        <title>Retrieving Underlying Feed and Entry Sources</title>
+
+        <para>
+            <classname>Zend_Feed_Reader</classname> does it's best not to stick
+            you in a narrow confine. If you need to work on a feed outside of
+            <classname>Zend_Feed_Reader</classname>, you can extract the base
+            <classname>DOMDocument</classname> or
+            <classname>DOMElement</classname> objects from any class, or even an
+            <acronym>XML</acronym> string containing these. Also provided are methods to extract
+            the current <classname>DOMXPath</classname> object (with all core
+            and Extension namespaces registered) and the correct prefix used in
+            all XPath queries for the current Feed or Entry. The basic methods
+            to use (on any object) are <methodname>saveXml()</methodname>,
+            <methodname>getDomDocument()</methodname>,
+            <methodname>getElement()</methodname>,
+            <methodname>getXpath()</methodname> and
+            <methodname>getXpathPrefix()</methodname>. These will let you break
+            free of <classname>Zend_Feed_Reader</classname> and do whatever else
+            you want.
+        </para>
+
+        <itemizedlist>
+            <listitem>
+                <para>
+                    <methodname>saveXml()</methodname> returns an <acronym>XML</acronym> string
+                    containing only the element representing the current object.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <methodname>getDomDocument()</methodname> returns the
+                    <classname>DOMDocument</classname> object representing the
+                    entire feed (even if called from an Entry object).
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <methodname>getElement()</methodname> returns the
+                    <classname>DOMElement</classname> of the current object
+                    (i.e. the Feed or current Entry).
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <methodname>getXpath()</methodname> returns the
+                    <classname>DOMXPath</classname> object for the current feed
+                    (even if called from an Entry object) with the namespaces of
+                    the current feed type and all loaded Extensions
+                    pre-registered.
+                </para>
+            </listitem>
+
+            <listitem>
+                <para>
+                    <methodname>getXpathPrefix()</methodname> returns the query
+                    prefix for the current object (i.e. the Feed or current
+                    Entry) which includes the correct XPath query path for that
+                    specific Feed or Entry.
+                </para>
+            </listitem>
+        </itemizedlist>
+
+        <para>
+            Here's an example where a feed might include an <acronym>RSS</acronym> Extension not
+            supported by <classname>Zend_Feed_Reader</classname> out of the box.
+            Notably, you could write and register an Extension (covered later)
+            to do this, but that's not always warranted for a quick check. You
+            must register any new namespaces on the
+            <classname>DOMXPath</classname> object before use unless they are
+            registered by <classname>Zend_Feed_Reader</classname> or an
+            Extension beforehand.
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$feed        = Zend_Feed_Reader::import('http://www.planet-php.net/rdf/');
+$xpathPrefix = $feed->getXpathPrefix();
+$xpath       = $feed->getXpath();
+$xpath->registerNamespace('admin', 'http://webns.net/mvcb/');
+$reportErrorsTo = $xpath->evaluate('string('
+                                 . $xpathPrefix
+                                 . '/admin:errorReportsTo)');
+]]></programlisting>
+
+        <warning>
+            <para>
+                If you register an already registered namespace with a different
+                prefix name to that used internally by
+                <classname>Zend_Feed_Reader</classname>, it will break the
+                internal operation of this component.
+            </para>
+        </warning>
+    </sect2>
+
+    <sect2 id="zend.feed.reader.cache-request">
+        <title>Cache Support and Intelligent Requests</title>
+
+        <sect3 id="zend.feed.reader.cache-request.cache">
+            <title>Adding Cache Support to Zend_Feed_Reader</title>
+
+            <para>
+                <classname>Zend_Feed_Reader</classname> supports using an
+                instance of <classname>Zend_Cache</classname> to cache feeds (as
+                <acronym>XML</acronym>) to avoid unnecessary network requests. Adding a cache is as
+                simple here as it is for other Zend Framework components, create
+                and configure your cache and then tell
+                <classname>Zend_Feed_Reader</classname> to use it! The cache key
+                used is "<classname>Zend_Feed_Reader_</classname>" followed by the
+                <acronym>MD5</acronym> hash of the feed's <acronym>URI</acronym>.
+            </para>
+
+            <programlisting language="php"><![CDATA[
+$frontendOptions = array(
+   'lifetime' => 7200,
+   'automatic_serialization' => true
+);
+$backendOptions = array('cache_dir' => './tmp/');
+$cache = Zend_Cache::factory(
+    'Core', 'File', $frontendOptions, $backendOptions
+);
+
+Zend_Feed_Reader::setCache($cache);
+]]></programlisting>
+
+            <note>
+                <para>
+                    While it's a little off track, you should also consider
+                    adding a cache to
+                    <classname>Zend_Loader_PluginLoader</classname> which is
+                    used by <classname>Zend_Feed_Reader</classname> to load
+                    Extensions.
+                </para>
+            </note>
+        </sect3>
+
+        <sect3 id="zend.feed.reader.cache-request.http-conditional-get">
+            <title>HTTP Conditional GET Support</title>
+
+            <para>
+                The big question often asked when importing a feed frequently, is
+                if it has even changed. With a cache enabled, you can add <acronym>HTTP</acronym>
+                Conditional GET support to your arsenal to answer that question.
+            </para>
+
+            <para>
+                Using this method, you can request feeds from <acronym>URI</acronym>s and include
+                their last known ETag and Last-Modified response header values
+                with the request (using the If-None-Match and If-Modified-Since
+                headers). If the feed on the server remains unchanged, you
+                should receive a 304 response which tells
+                <classname>Zend_Feed_Reader</classname> to use the cached
+                version. If a full feed is sent in a response with a status code
+                of 200, this means the feed has changed and
+                <classname>Zend_Feed_Reader</classname> will parse the new
+                version and save it to the cache. It will also cache the new
+                ETag and Last-Modified header values for future use.
+            </para>
+
+            <para>
+                These "conditional" requests are not guaranteed to be supported
+                by the server you request a <acronym>URI</acronym> of, but can be attempted
+                regardless. Most common feed sources like blogs should however
+                have this supported. To enable conditional requests, you will
+                need to provide a cache to <classname>Zend_Feed_Reader</classname>.
+            </para>
+
+            <programlisting language="php"><![CDATA[
+$frontendOptions = array(
+   'lifetime' => 86400,
+   'automatic_serialization' => true
+);
+$backendOptions = array('cache_dir' => './tmp/');
+$cache = Zend_Cache::factory(
+    'Core', 'File', $frontendOptions, $backendOptions
+);
+
+Zend_Feed_Reader::setCache($cache);
+Zend_Feed_Reader::useHttpConditionalGet();
+
+$feed = Zend_Feed_Reader::import('http://www.planet-php.net/rdf/');
+]]></programlisting>
+
+            <para>
+                In the example above, with <acronym>HTTP</acronym> Conditional GET requests enabled,
+                the response header values for ETag and Last-Modified will be cached
+                along with the feed. For the next 24hrs (the cache lifetime), feeds will
+                only be updated on the cache if a non-304 response is received
+                containing a valid <acronym>RSS</acronym> or Atom <acronym>XML</acronym> document.
+            </para>
+
+            <para>
+                If you intend on managing request headers from outside
+                <classname>Zend_Feed_Reader</classname>, you can set the
+                relevant If-None-Matches and If-Modified-Since request headers
+                via the <acronym>URI</acronym> import method.
+            </para>
+
+            <programlisting language="php"><![CDATA[
+$lastEtagReceived = '5e6cefe7df5a7e95c8b1ba1a2ccaff3d';
+$lastModifiedDateReceived = 'Wed, 08 Jul 2009 13:37:22 GMT';
+$feed = Zend_Feed_Reader::import(
+    $uri, $lastEtagReceived, $lastModifiedDateReceived
+);
+]]></programlisting>
+        </sect3>
+    </sect2>
+
+    <sect2 id="zend.feed.reader.locate">
+        <title>Locating Feed URIs from Websites</title>
+
+        <para>
+            These days, many websites are aware that the location of their <acronym>XML</acronym>
+            feeds is not always obvious. A small <acronym>RDF</acronym>, <acronym>RSS</acronym> or
+            Atom graphic helps when the user is reading the page, but what about when a machine
+            visits trying to identify where your feeds are located? To assist in
+            this, websites may point to their feeds using &lt;link&gt; tags in
+            the &lt;head&gt; section of their <acronym>HTML</acronym>. To take advantage of this,
+            you can use <classname>Zend_Feed_Reader</classname> to locate these
+            feeds using the static <methodname>findFeedLinks()</methodname>
+            method.
+        </para>
+
+        <para>
+            This method calls any <acronym>URI</acronym> and searches for the location of
+            <acronym>RSS</acronym>, <acronym>RDF</acronym>
+            and Atom feeds assuming the wlebsite's <acronym>HTML</acronym> contains the relevant
+            links. It then returns a value object where you can check for the existence of a
+            <acronym>RSS</acronym>, <acronym>RDF</acronym> or Atom feed <acronym>URI</acronym>.
+        </para>
+
+        <programlisting language="php"><![CDATA[
+$links = Zend_Feed_Reader::findFeedLinks('http://www.planet-php.net');
+
+if(isset($links->rdf)) {
+    echo $links->rdf, "\n"; // http://www.planet-php.org/rdf/
+}
+if(isset($links->rss)) {
+    echo $links->rss, "\n"; // http://www.planet-php.org/rss/
+}
+if(isset($links->atom)) {
+    echo $links->atom, "\n"; // http://www.planet-php.org/atom/
+}
+]]></programlisting>
+
+        <para>
+            Based on these links, you can then import from whichever source you
+            wish in the usual manner.
+        </para>
+  </sect2>
+
+  <sect2 id="zend.feed.reader.retrieve-info">
+        <title>Retrieving Feed Information</title>
+
+        <para>
+            Retrieving information from a feed (we'll cover entries/items in the
+            next section though they follow identical principals) uses a clearly
+            defined <acronym>API</acronym> which is exactly the same regardless of whether the feed
+            in question is <acronym>RSS</acronym>/<acronym>RDF</acronym>/Atom. The same goes for
+            sub-versions of these standards and we've tested every single
+            <acronym>RSS</acronym> and Atom version. While
+            the underlying feed <acronym>XML</acronym> can differ substantially in terms of the
+            tags and elements they present, they nonetheless are all trying to
+            convey similar information and to reflect this all the differences
+            and wrangling over alternative tags are handled internally by
+            <classname>Zend_Feed_Reader</classname> presenting you with an
+            identical interface for each. Ideally, you should not have to care
+            whether a feed is <acronym>RSS</acronym> or Atom so long as you can extract the
+            information you want.
+        </para>
+
+        <para>
+            Of course, we don't live in an ideal world so there may be times the
+            <acronym>API</acronym> just does not cover what you're looking for. To assist you,
+            <classname>Zend_Feed_Reader</classname> offers a plugin system which
+            allows you to write Extensions to expand the core <acronym>API</acronym> and cover any
+            additional data you are trying to extract from feeds. If writing
+            another Extension is too much trouble, you can simply grab the
+            underlying <acronym>DOM</acronym> or XPath objects and do it by hand in your
+            application. Of course, we really do encourage writing an Extension
+            simply to make it more portable and reusable.
+        </para>
+
+        <para>
+            Here's a summary of the Core <acronym>API</acronym> for Feeds. You should note it
+            comprises not only the basic <acronym>RSS</acronym> and Atom standards, but also
+            accounts for a number of included Extensions bundled with
+            <classname>Zend_Feed_Reader</classname>. The naming of these
+            Extension sourced methods remain fairly generic - all Extension
+            methods operate at the same level as the Core <acronym>API</acronym> though we do allow
+            you to retrieve any specific Extension object separately if
+            required.
+        </para>
+
+        <table>
+            <title>Feed Level API Methods</title>
+
+            <tgroup cols="2">
+                <tbody>
+                    <row>
+                        <entry><methodname>getId()</methodname></entry>
+
+                        <entry>Returns a unique ID associated with this feed</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getTitle()</methodname></entry>
+
+                        <entry>Returns the title of the feed</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getDescription()</methodname></entry>
+
+                        <entry>Returns the text description of the feed</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getLink()</methodname></entry>
+
+                        <entry>
+                            Returns a <acronym>URI</acronym> to the <acronym>HTML</acronym> website
+                            containing the same or
+                            similar information as this feed (i.e. if the feed is from a blog,
+                            it should provide the blog's <acronym>URI</acronym> where the
+                            <acronym>HTML</acronym> version of the entries can be read).
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getFeedLink()</methodname></entry>
+
+                        <entry>
+                            Returns the <acronym>URI</acronym> of this feed, which should be the
+                            same as the <acronym>URI</acronym> used to import the feed
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getAuthors()</methodname></entry>
+
+                        <entry>
+                            Returns an array of all authors associated with this feed
+                            including email address in the author string if available
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getAuthor(integer $index = 0)</methodname></entry>
+
+                        <entry>
+                            Returns either the first author known, or with the
+                            optional <varname>$index</varname> parameter any specific
+                            index on the array of Authors (returning null if an
+                            invalid index).
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getDateCreated()</methodname></entry>
+
+                        <entry>
+                            Returns the date on which this feed was created. Generally
+                            only applicable to Atom where it represents the date the resource
+                            described by an Atom 1.0 document was created.
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getDateModified()</methodname></entry>
+
+                        <entry>
+                            Returns the date on which this feed was last modified
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getLanguage()</methodname></entry>
+
+                        <entry>
+                            Returns the language of the feed (if defined) or simply the
+                            language noted in the <acronym>XML</acronym> document
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getGenerator()</methodname></entry>
+
+                        <entry>
+                            Returns the generator of the feed, e.g. the software which
+                            generated it. This may differ between <acronym>RSS</acronym> and Atom
+                            since Atom defines a different notation.
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getCopyright()</methodname></entry>
+
+                        <entry>
+                            Returns any copyright notice associated with the feed
+                        </entry>
+                    </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+        <para>
+            Given the variety of feeds in the wild, some of these methods will
+            undoubtedly return <constant>NULL</constant> indicating the relevant information
+            couldn't be located. Where possible, <classname>Zend_Feed_Reader</classname>
+            will fall back on alternative elements during its search. For
+            example, searching an <acronym>RSS</acronym> feed for a modification date is more
+            complicated than it looks. <acronym>RSS</acronym> 2.0 feeds should include a
+            <code>&lt;lastBuildDate&gt;</code> tag and/or a
+            <code>&lt;pubDate&gt;</code> element. But what if it doesn't, maybe
+            this is an <acronym>RSS</acronym> 1.0 feed? Perhaps it instead has an
+            <code>&lt;atom:updated&gt;</code> element with identical information
+            (Atom may be used to supplement <acronym>RSS</acronym>'s syntax)? Failing that, we
+            could simply look at the entries, pick the most recent, and use its
+            <code>&lt;pubDate&gt;</code> element. Assuming it exists... Many
+            feeds also use Dublin Core 1.0/1.1 <code>&lt;dc:date&gt;</code>
+            elements for feeds/entries. Or we could find Atom lurking again.
+        </para>
+
+        <para>
+            The point is, <classname>Zend_Feed_Reader</classname> was designed
+            to know this. When you ask for the modification date (or anything
+            else), it will run off and search for all these alternatives until
+            it either gives up and returns <constant>NULL</constant>, or finds an
+            alternative that should have the right answer.
+        </para>
+
+        <para>
+            In addition to the above methods, all Feed objects implement methods
+            for retrieving the <acronym>DOM</acronym> and XPath objects for the current feeds as
+            described earlier. Feed objects also implement the <acronym>SPL</acronym> Iterator and
+            Countable interfaces. The extended <acronym>API</acronym> is summarised below.
+        </para>
+
+        <table>
+            <title>Extended Feed Level API Methods</title>
+
+            <tgroup cols="2">
+                <tbody>
+                    <row>
+                        <entry><methodname>getDomDocument()</methodname></entry>
+
+                        <entry>
+                            Returns the parent
+                            <classname>DOMDocument</classname> object for the
+                            entire source <acronym>XML</acronym> document
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getElement()</methodname></entry>
+
+                        <entry>
+                            Returns the current feed level
+                            <classname>DOMElement</classname> object
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>saveXml()</methodname></entry>
+
+                        <entry>
+                            Returns a string containing an <acronym>XML</acronym> document of the
+                            entire feed element (this is not the original
+                            document but a rebuilt version)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getXpath()</methodname></entry>
+
+                        <entry>
+                            Returns the <classname>DOMXPath</classname> object
+                            used internally to run queries on the
+                            <classname>DOMDocument</classname> object (this
+                            includes core and Extension namespaces
+                            pre-registered)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getXpathPrefix()</methodname></entry>
+
+                        <entry>
+                            Returns the valid <acronym>DOM</acronym> path prefix prepended
+                            to all XPath queries matching the feed being queried
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getEncoding()</methodname></entry>
+
+                        <entry>
+                            Returns the encoding of the source <acronym>XML</acronym> document
+                            (note: this cannot account for errors such as the
+                            server sending documents in a different encoding)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>count()</methodname></entry>
+
+                        <entry>
+                            Returns a count of the entries or items this feed contains
+                            (implements <acronym>SPL</acronym> <classname>Countable</classname>
+                            interface)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>current()</methodname></entry>
+
+                        <entry>
+                            Returns either the current entry (using the current index
+                            from <methodname>key()</methodname>)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>key()</methodname></entry>
+
+                        <entry>Returns the current entry index</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>next()</methodname></entry>
+
+                        <entry>Increments the entry index value by one</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>rewind()</methodname></entry>
+
+                        <entry>Resets the entry index to 0</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>valid()</methodname></entry>
+
+                        <entry>
+                            Checks that the current entry index is valid, i.e.
+                            it does fall below 0 and does not exceed the number
+                            of entries existing.
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getExtensions()</methodname></entry>
+
+                        <entry>
+                            Returns an array of non-Core Extension objects loaded for
+                            the current feed (note: both feed-level and entry-level Extensions
+                            exist, and only feed-level Extensions are returned here).
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getType()</methodname></entry>
+
+                        <entry>
+                            Returns a static class constant (e.g.
+                            <constant>Zend_Feed_Reader::TYPE_ATOM_03</constant>,
+                            i.e. Atom 0.3) indicating exactly what kind of feed
+                            is being consumed.
+                        </entry>
+                    </row>
+                </tbody>
+            </tgroup>
+        </table>
+    </sect2>
+
+    <sect2 id="zend.feed.reader.entry">
+        <title>Retrieving Entry/Item Information</title>
+
+        <para>
+            Retrieving information for specific entries or items (depending on
+            whether you speak Atom or <acronym>RSS</acronym>) is identical to feed level data.
+            Accessing entries is simply a matter of iterating over a Feed object
+            or using the <acronym>SPL</acronym> <classname>Iterator</classname> interface Feed
+            objects implement and calling the appropriate method on each.
+        </para>
+
+        <table>
+            <title>Entry Level API Methods</title>
+
+            <tgroup cols="2">
+                <tbody>
+                    <row>
+                        <entry><methodname>getId()</methodname></entry>
+
+                        <entry>Returns a unique ID for the current entry</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getTitle()</methodname></entry>
+
+                        <entry>Returns the title of the current entry</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getDescription()</methodname></entry>
+
+                        <entry>Returns a description of the current entry</entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getLink()</methodname></entry>
+
+                        <entry>
+                            Returns a <acronym>URI</acronym> to the <acronym>HTML</acronym> version
+                            of the current entry
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getPermaLink()</methodname></entry>
+
+                        <entry>
+                            Returns the permanent link to the current entry
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getAuthors()</methodname></entry>
+
+                        <entry>
+                            Returns an array of all authors associated with this entry
+                            including email address in the author string if available
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getAuthor($index = 0)</methodname></entry>
+
+                        <entry>
+                            Returns either the first author known, or with the
+                            optional <varname>$index</varname> parameter any specific
+                            index on the array of Authors (returning null if an
+                            invalid index).
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getDateCreated()</methodname></entry>
+
+                        <entry>
+                            Returns the date on which the current entry was
+                            created. Generally only applicable to Atom where it
+                            represents the date the resource described by an
+                            Atom 1.0 document was created.
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getDateModified()</methodname></entry>
+
+                        <entry>
+                            Returns the date on which the current entry was last
+                            modified
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getContent()</methodname></entry>
+
+                        <entry>
+                            Returns the content of the current entry (this has any
+                            entities reversed if possible assuming the content type is
+                            <acronym>HTML</acronym>). The description is returned if a
+                            separate content element does not exist.
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getCommentCount()</methodname></entry>
+
+                        <entry>
+                            Returns the number of comments made on this entry at the
+                            time the feed was last generated
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getCommentLink()</methodname></entry>
+
+                        <entry>
+                            Returns a <acronym>URI</acronym> pointing to the <acronym>HTML</acronym>
+                            page where comments can be made on this entry
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry>
+                            <methodname>getCommentFeedLink(string $type =
+                                'atom'|'rss')</methodname>
+                        </entry>
+
+                        <entry>
+                            Returns a <acronym>URI</acronym> pointing to a feed of the provided type
+                            containing all comments for this entry (type defaults to
+                            Atom/<acronym>RSS</acronym> depending on current feed type).
+                        </entry>
+                    </row>
+                </tbody>
+            </tgroup>
+        </table>
+
+        <para>
+            The extended <acronym>API</acronym> for entries is identical to that for feeds with the
+            exception of the Iterator methods which are not needed here.
+        </para>
+
+        <caution>
+            <para>
+                There is often confusion over the concepts of modified and
+                created dates. In Atom, these are two clearly defined concepts
+                (so knock yourself out) but in <acronym>RSS</acronym> they are vague.
+                <acronym>RSS</acronym> 2.0
+                defines a single <emphasis>&lt;pubDate&gt;</emphasis> element
+                which typically refers to the date this entry was published,
+                i.e. a creation date of sorts. This is not always the case, and
+                it may change with updates or not. As a result, if you really
+                want to check whether an entry has changed, don't rely on the
+                results of <methodname>getDateModified()</methodname>. Instead,
+                consider tracking the <acronym>MD5</acronym> hash of three other elements
+                concatenated, e.g. using <methodname>getTitle()</methodname>,
+                <methodname>getDescription()</methodname> and
+                <methodname>getContent()</methodname>. If the entry was trully
+                updated, this hash computation will give a different result than
+                previously saved hashes for the same entry. Further muddying the
+                waters, dates in feeds may follow different standards. Atom and
+                Dublin Core dates should follow <acronym>ISO</acronym> 8601,
+                and <acronym>RSS</acronym> dates should
+                follow <acronym>RFC</acronym> 822 or <acronym>RFC</acronym> 2822
+                which is also common. Date methods
+                will throw an exception if <classname>Zend_Date</classname>
+                cannot load the date string using one of the above standards.
+            </para>
+        </caution>
+
+        <warning>
+            <para>
+                The values returned from these methods are not validated. This
+                means users must perform validation on all retrieved data
+                including the filtering of any <acronym>HTML</acronym> such as from
+                <methodname>getContent()</methodname> before it is output from
+                your application. Remember that most feeds come from external
+                sources, and therefore the default assumption should be that
+                they cannot be trusted.
+            </para>
+        </warning>
+
+        <table>
+            <title>Extended Entry Level API Methods</title>
+
+            <tgroup cols="2">
+                <tbody>
+                    <row>
+                        <entry><methodname>getDomDocument()</methodname></entry>
+
+                        <entry>
+                            Returns the parent
+                            <classname>DOMDocument</classname> object for the
+                            entire feed (not just the current entry)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getElement()</methodname></entry>
+
+                        <entry>
+                            Returns the current entry level
+                            <classname>DOMElement</classname> object
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getXpath()</methodname></entry>
+
+                        <entry>
+                            Returns the <classname>DOMXPath</classname> object
+                            used internally to run queries on the
+                            <classname>DOMDocument</classname> object (this
+                            includes core and Extension namespaces
+                            pre-registered)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getXpathPrefix()</methodname></entry>
+
+                        <entry>
+                            Returns the valid <acronym>DOM</acronym> path prefix prepended
+                            to all XPath queries matching the entry being queried
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getEncoding()</methodname></entry>
+
+                        <entry>
+                            Returns the encoding of the source <acronym>XML</acronym> document
+                            (note: this cannot account for errors such as the server sending
+                            documents in a different encoding)
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getExtensions()</methodname></entry>
+
+                        <entry>
+                            Returns an array of non-Core Extension objects loaded for
+                            the current entry (note: both feed-level and entry-level
+                            Extensions exist, and only entry-level Extensions are returned
+                            here).
+                        </entry>
+                    </row>
+
+                    <row>
+                        <entry><methodname>getType()</methodname></entry>
+
+                        <entry>
+                            Returns a static class constant (e.g.
+                            <constant>Zend_Feed_Reader::TYPE_ATOM_03</constant>,
+                            i.e. Atom 0.3) indicating exactly what kind
+                            of feed is being consumed.
+                        </entry>
+                    </row>
+                </tbody>
+            </tgroup>
+        </table>
+    </sect2>
+
+    <sect2 id="zend.feed.reader.extending">
+        <title>Extending Feed and Entry APIs</title>
+
+        <para>
+            Extending <classname>Zend_Feed_Reader</classname> allows you to add
+            methods at both the feed and entry level which cover the retrieval
+            of information not already supported by
+            <classname>Zend_Feed_Reader</classname>. Given the number of
+            <acronym>RSS</acronym> and
+            Atom extensions that exist, this is a good thing since
+            <classname>Zend_Feed_Reader</classname> couldn't possibly add
+            everything.
+        </para>
+
+        <para>
+            There are two types of Extensions possible, those which retrieve
+            information from elements which are immediate children of the root
+            element (e.g. <code>&lt;channel&gt;</code> for <acronym>RSS</acronym> or
+            <code>&lt;feed&gt;</code> for Atom) and those who retrieve
+            information from child elements of an entry (e.g.
+            <code>&lt;item&gt;</code> for <acronym>RSS</acronym> or <code>&lt;entry&gt;</code> for
+            Atom). On the filesystem these are grouped as classes within
+            a namespace based on the extension standard's name. For
+            example, internally we have
+            <classname>Zend_Feed_Reader_Extension_DublinCore_Feed</classname>
+            and <classname>Zend_Feed_Reader_Extension_DublinCore_Entry</classname>
+            classes which are two Extensions implementing Dublin Core
+            1.0/1.1 support.
+        </para>
+
+        <para>
+            Extensions are loaded into <classname>Zend_Feed_Reader</classname>
+            using <classname>Zend_Loader_PluginLoader</classname>, so their operation
+            will be familiar from other Zend Framework components.
+            <classname>Zend_Feed_Reader</classname> already bundles a number of
+            these Extensions, however those which are not used internally and
+            registered by default (so called Core Extensions) must be registered
+            to <classname>Zend_Feed_Reader</classname> before they are used. The
+            bundled Extensions include:
+        </para>
+
+        <table>
+            <title>Core Extensions (pre-registered)</title>
+
+            <tgroup cols="2">
+                <tbody>
+                    <row>
+                        <entry>DublinCore (Feed and Entry)</entry>
+
+                        <entry>Implements support for both Dublin Core 1.0 and 1.1</entry>
+                    </row>
+
+                    <row>
+                        <entry>Content (Entry only)</entry>
+
+                        <entry>Implements support for Content 1.0</entry>
+                    </row>
+
+                    <row>
+                        <entry>Atom (Feed and Entry)</entry>
+
+                        <entry>Implements support for Atom 0.3 and Atom 1.0</entry>
+                    </row>
+
+                    <row>
+                        <entry>Slash</entry>
+
+                        <entry>todo</entry>
+                    </row>
+
+                    <row>
+                        <entry>WellFormedWeb</entry>
+
+                        <entry>todo</entry>
+                    </row>
+                </tbody>
+            </tgroup>
+        </table>
+
+        <para>
+            The Core Extensions are somewhat special since they are extremely
+            common and multi-faceted. For example, we have a Core Extension for Atom.
+            Atom is implemented as an Extension (not just a base class) because it
+            doubles as a valid <acronym>RSS</acronym> Extension - you can insert
+            Atom elements into <acronym>RSS</acronym> feeds. I've even seen
+            <acronym>RDF</acronym> feeds which use a lot of Atom in place of more
+            common Extensions like Dublin Core.
+        </para>
+
+        <table>
+            <title>Non-Core Extensions (must register manually)</title>
+
+            <tgroup cols="1">
+                <tbody>
+                    <row>
+                        <entry>At present, no non-Core Extensions are distributed.</entry>
+                    </row>
+                </tbody>
+            </tgroup>
+        </table>
+
+        <para>
+            The additional non-Core Extensions are offered but not registered to
+            <classname>Zend_Feed_Reader</classname> by default. If you want to
+            use them, you'll need to tell
+            <classname>Zend_Feed_Reader</classname> to load them in advance of
+            importing a feed.
+        </para>
+
+        <para>
+            Registering an Extension with
+            <classname>Zend_Feed_Reader</classname>, so it is loaded and its <acronym>API</acronym>
+            is available to Feed and Entry objects, is a simple affair using the
+            <classname>Zend_Loader_PluginLoader</classname>. Here we register
+            the optional Slash Extension, and discover that it can be directly
+            called from the Entry level <acronym>API</acronym> without any effort. Note that
+            Extension names are case sensitive and use camel casing for multiple
+            terms.
+        </para>
+
+        <programlisting language="php"><![CDATA[
+Zend_Feed_Reader::registerExtension('Slash');
+$feed = Zend_Feed_Reader::import('http://rss.slashdot.org/Slashdot/slashdot');
+$commentsForLastEntry = $feed->current()->getCommentCount();
+]]></programlisting>
+
+        <para>
+            In the simple example above, we checked how many comments were made
+            on an entry using the <methodname>getCommentCount()</methodname>
+            method. Since it's not part of
+            <classname>Zend_Feed_Reader</classname>'s core <acronym>API</acronym>, it could only be
+            a method supported by the newly registered Slash Extension (indeed
+            Slash was invented at Slashdot as an <acronym>RDF</acronym> Site Summary module and is
+            now fairly popular).
+        </para>
+
+        <sect3 id="zend.feed.reader.extending.feed">
+            <title>Writing Zend_Feed_Reader Extensions</title>
+
+            <para>
+                Inevitably, there will be times when the
+                <classname>Zend_Feed_Reader</classname> <acronym>API</acronym> is just not capable
+                of getting something you need from a feed or entry. You can use
+                the underlying source objects, like
+                <classname>DOMDocument</classname>, to get these by hand however
+                there is a more reusable method available by writing Extensions
+                supporting these new queries.
+            </para>
+
+            <para>
+                As an example, let's take the case of a purely fictitious
+                corporation named Jungle Books. Jungle Books have been
+                publishing a lot of reviews on books they sell (from external
+                sources and customers), which are distributed as an <acronym>RSS</acronym> 2.0
+                feed. Their marketing department realises that web applications
+                using this feed cannot currently figure out exactly what book is
+                being reviewed. To make life easier for everyone, they determine
+                that the geek department needs to extend <acronym>RSS</acronym> 2.0 to include a
+                new element per entry supplying the <acronym>ISBN</acronym>-10 or
+                <acronym>ISBN</acronym>-13 number of
+                the publication the entry concerns. They define the new
+                <code>&lt;isbn&gt;</code> element quite simply with a standard
+                name and namespace <acronym>URI</acronym>:
+            </para>
+
+            <programlisting language="php"><![CDATA[
+JungleBooks 1.0:
+http://example.com/junglebooks/rss/module/1.0/
+]]></programlisting>
+
+            <para>
+                A snippet of <acronym>RSS</acronym> containing this extension in practice could be
+                something similar to:
+            </para>
+
+            <programlisting language="php"><![CDATA[
+<?xml version="1.0" encoding="utf-8" ?>
+<rss version="2.0"
+   xmlns:content="http://purl.org/rss/1.0/modules/content/"
+   xmlns:jungle="http://example.com/junglebooks/rss/module/1.0/">
+<channel>
+    <title>Jungle Books Customer Reviews</title>
+    <link>http://example.com/junglebooks</link>
+    <description>Many book reviews!</description>
+    <pubDate>Fri, 26 Jun 2009 19:15:10 GMT</pubDate>
+    <jungle:dayPopular>http://example.com/junglebooks/book/938</jungle:dayPopular>
+    <item>
+        <title>Review Of Flatland: A Romance of Many Dimensions</title>
+        <link>http://example.com/junglebooks/review/987</link>
+        <author>Confused Physics Student</author>
+        <content:encoded>
+        A romantic square?!
+        </content:encoded>
+        <pubDate>Thu, 25 Jun 2009 20:03:28 -0700</pubDate>
+        <jungle:isbn>048627263X</jungle:isbn>
+    </item>
+</channel>
+</rss>
+]]></programlisting>
+
+            <para>
+                Implementing this new <acronym>ISBN</acronym> element as a simple entry level
+                extension would require the following class (using your own class
+                namespace outside of Zend).
+            </para>
+
+            <programlisting language="php"><![CDATA[
+class My_FeedReader_Extension_JungleBooks_Entry
+    extends Zend_Feed_Reader_Extension_EntryAbstract
+{
+    public function getIsbn()
+    {
+        if (isset($this->_data['isbn'])) {
+            return $this->_data['isbn'];
+        }
+        $isbn = $this->_xpath->evaluate(
+            'string(' . $this->getXpathPrefix() . '/jungle:isbn)'
+        );
+        if (!$isbn) {
+            $isbn = null;
+        }
+        $this->_data['isbn'] = $title;
+        return $this->_data['isbn'];
+    }
+
+    protected function _registerNamespaces()
+    {
+        $this->_xpath->registerNamespace(
+            'jungle', 'http://example.com/junglebooks/rss/module/1.0/'
+        );
+    }
+}
+]]></programlisting>
+
+            <para>
+                This extension is easy enough to follow. It creates a new method
+                <methodname>getIsbn()</methodname> which runs an XPath query on
+                the current entry to extract the <acronym>ISBN</acronym> number enclosed by the
+                <code>&lt;jungle:isbn&gt;</code> element. It can optionally
+                store this to the internal non-persistent cache (no need to keep
+                querying the <acronym>DOM</acronym> if it's called again on the same entry). The
+                value is returned to the caller. At the end we have a protected
+                method (it's abstract so it must exist) which registers the
+                Jungle Books namespace for their custom <acronym>RSS</acronym> module. While we
+                call this an <acronym>RSS</acronym> module, there's nothing to prevent the same
+                element being used in Atom feeds - and all Extensions which use
+                the prefix provided by <methodname>getXpathPrefix()</methodname>
+                are actually neutral and work on <acronym>RSS</acronym> or Atom feeds with no
+                extra code.
+            </para>
+
+            <para>
+                Since this Extension is stored outside of Zend Framework, you'll
+                need to register the path prefix for your Extensions so
+                <classname>Zend_Loader_PluginLoader</classname> can find them.
+                After that, it's merely a matter of registering the Extension,
+                if it's not already loaded, and using it in practice.
+            </para>
+
+            <programlisting language="php"><![CDATA[
+if(!Zend_Feed_Reader::isRegistered('JungleBooks')) {
+    Zend_Feed_Reader::addPrefixPath(
+        '/path/to/My/FeedReader/Extension', 'My_FeedReader_Extension'
+    );
+    Zend_Feed_Reader::registerExtension('JungleBooks');
+}
+$feed = Zend_Feed_Reader::import('http://example.com/junglebooks/rss');
+
+// ISBN for whatever book the first entry in the feed was concerned with
+$firstIsbn = $feed->current()->getIsbn();
+]]></programlisting>
+
+            <para>
+                Writing a feed level Extension is not much different. The
+                example feed from earlier included an unmentioned
+                <code>&lt;jungle:dayPopular&gt;</code> element which Jungle
+                Books have added to their standard to include a link to the
+                day's most popular book (in terms of visitor traffic). Here's
+                an Extension which adds a
+                <methodname>getDaysPopularBookLink()</methodname> method to the
+                feel level <acronym>API</acronym>.
+            </para>
+
+            <programlisting language="php"><![CDATA[
+class My_FeedReader_Extension_JungleBooks_Feed
+    extends Zend_Feed_Reader_Extension_FeedAbstract
+{
+    public function getDaysPopularBookLink()
+    {
+        if (isset($this->_data['dayPopular'])) {
+            return $this->_data['dayPopular'];
+        }
+        $dayPopular = $this->_xpath->evaluate(
+            'string(' . $this->getXpathPrefix() . '/jungle:dayPopular)'
+        );
+        if (!$dayPopular) {
+            $dayPopular = null;
+        }
+        $this->_data['dayPopular'] = $dayPopular;
+        return $this->_data['dayPopular'];
+    }
+
+    protected function _registerNamespaces()
+    {
+        $this->_xpath->registerNamespace(
+            'jungle', 'http://example.com/junglebooks/rss/module/1.0/'
+        );
+    }
+}]]></programlisting>
+
+            <para>
+                Let's repeat the last example using a custom Extension to show the
+                method being used.
+            </para>
+
+            <programlisting language="php"><![CDATA[
+if(!Zend_Feed_Reader::isRegistered('JungleBooks')) {
+    Zend_Feed_Reader::addPrefixPath(
+        '/path/to/My/FeedReader/Extension', 'My_FeedReader_Extension'
+    );
+    Zend_Feed_Reader::registerExtension('JungleBooks');
+}
+$feed = Zend_Feed_Reader::import('http://example.com/junglebooks/rss');
+
+// URI to the information page of the day's most popular book with visitors
+$daysPopularBookLink = $feed->getDaysPopularBookLink();
+
+// ISBN for whatever book the first entry in the feed was concerned with
+$firstIsbn = $feed->current()->getIsbn();
+]]></programlisting>
+
+            <para>
+                Going through these examples, you'll note that we don't register
+                feed and entry Extensions separately. Extensions within the same
+                standard may or may not include both a feed and entry class, so
+                <classname>Zend_Feed_Reader</classname> only requires you to
+                register the overall parent name, e.g. JungleBooks, DublinCore,
+                Slash. Internally, it can check at what level Extensions exist
+                and load them up if found. In our case, we have a full set of
+                Extensions now: <classname>JungleBooks_Feed</classname> and
+                <classname>JungleBooks_Entry</classname>.
+            </para>
+        </sect3>
+  </sect2>
+</sect1>

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

@@ -25,8 +25,8 @@
 
         <listitem>
             <para>
-                <emphasis>Eigene Front Kontroller Plugins.</emphasis>
-                <classname>Zend_Layout</classname> wird mit einem Standard Front Kontroller Plugin
+                <emphasis>Eigene Front Controller Plugins.</emphasis>
+                <classname>Zend_Layout</classname> wird mit einem Standard Front Controller Plugin
                 ausgeliefert der das Layout automatisch darstellt bevor die Antwort zurückgegeben
                 wird. Es kann ein eigenes Plugin verwendet werden.
             </para>
@@ -110,7 +110,7 @@ $layoutVars   = $placeholders->placeholder('Zend_Layout')->getArrayCopy();
 
         <para>
             Wenn <classname>Zend_Layout</classname> mit den MVC Komponenten verwendet wird,
-            registriert es ein Front Kontroller Plugin das das Layout als letzte Aktion darstellt
+            registriert es ein Front Controller Plugin das das Layout als letzte Aktion darstellt
             bevor die Bearbeitungsschleife beendet wird. In den meisten Fällen, wird das
             Standardplugin ausreichen, aber sollte es gewünscht sein ein eigenes zu schreiben, kann
             der Name der Pluginklasse die geladen werden soll durch die übergabe der

documentation/manual/de/module_specs/Zend_Layout-Introduction.xml

@@ -41,7 +41,7 @@
         <listitem>
             <para>
                 Erlaubt das Ausschalten von Layouts, die Änderung von Layout Skripts, und andere
-                Stati; erlaubt diese Aktionen von innerhalb des Aktions Kontrollers und von View
+                Stati; erlaubt diese Aktionen von innerhalb des Aktions Controllers und von View
                 Skripten.
             </para>
         </listitem>

documentation/manual/de/module_specs/Zend_Layout-Options.xml

@@ -75,7 +75,7 @@
 
         <listitem>
             <para>
-                <emphasis>pluginClass</emphasis>: Das Front Kontroller Plugin das verwendet wird
+                <emphasis>pluginClass</emphasis>: Das Front Controller Plugin das verwendet wird
                 wenn <classname>Zend_Layout</classname> mit den MVC Komponenten verwendet wird.
                 Standardmäßig ist das <classname>Zend_Layout_Controller_Plugin_Layout</classname>.
                 Zugriffsmethoden sind <code>setPluginClass()</code> und

documentation/manual/de/module_specs/Zend_Layout-QuickStart.xml

@@ -89,8 +89,8 @@
 
         <para>
             <classname>Zend_Controller</classname> bietet ein reiches Set von Funktionalitäten für
-            Erweiterung mit seinen <link linkend="zend.controller.plugins">Front Kontroller
-                Plugins</link> und <link linkend="zend.controller.actionhelpers">Action Kontroller
+            Erweiterung mit seinen <link linkend="zend.controller.plugins">Front Controller
+                Plugins</link> und <link linkend="zend.controller.actionhelpers">Action Controller
                 Helfern</link>. <classname>Zend_View</classname> hat auch <link
                 linkend="zend.view.helpers">Helfer</link>. <classname>Zend_Layout</classname> nimmt
             Vorteile wahr von diesen verschiedenen Erweiterungspunkten wenn es mit den MVC
@@ -100,10 +100,10 @@
         <para>
             <classname>Zend_Layout::startMvc()</classname> erstellt eine Instanz von
             <classname>Zend_Layout</classname> mit jeder optionalen Konfiguration die angegeben
-            wird. Anschließend wird ein Front Kontroller Plugin registriert das das Layout mit jedem
+            wird. Anschließend wird ein Front Controller Plugin registriert das das Layout mit jedem
             Anwendungsinhalt darstellt sobald die Dispatch Schleife fertiggestellt ist, und
             registriert einen Action Helfer der den Zugriff auf das Layout Objekt vom Action
-            Kontroller aus gestattet. Zusätzlich kann jederzeit die Layout Instanz vom View Skript
+            Controller aus gestattet. Zusätzlich kann jederzeit die Layout Instanz vom View Skript
             geholt werden indem der <code>layout</code> View Helfer verwendet wird.
         </para>
 

documentation/manual/de/module_specs/Zend_Locale-Introduction.xml

@@ -377,7 +377,7 @@ try {
     $locale = new Zend_Locale('de');
 }
 
-// Im Modell/Kontroller
+// Im Modell/Controller
 $date = new Zend_Date($locale);
 ]]></programlisting>
         </example>
@@ -403,7 +403,7 @@ $date = new Zend_Date($locale);
 // In der Bootstrap Datei
 Zend_Locale::setDefault('de');
 
-// Im Modell/Kontroller
+// Im Modell/Controller
 $date = new Zend_Date();
 ]]></programlisting>
         </example>

documentation/manual/de/module_specs/Zend_Session-AdvancedUsage.xml

@@ -225,21 +225,21 @@ $s->setExpirationSeconds(60);
 
     <sect2 id="zend.session.advanced_usage.controllers">
 
-        <title>Kapseln von Sessions und Kontroller</title>
+        <title>Kapseln von Sessions und Controller</title>
 
         <para>
-            Namensräume können auch verwendet werden um den Zugriff auf Sessions durch Kontroller
+            Namensräume können auch verwendet werden um den Zugriff auf Sessions durch Controller
             zu seperieren um Variablen vor Kontaminierung zu schützen. Zum Beispiel könnte ein
-            Authentifizierungs Kontroller seine Session Daten von allen anderen Kontrollern separat
+            Authentifizierungs Controller seine Session Daten von allen anderen Controllern separat
             halten um notwendigen Sicherheiten zu entsprechen.
         </para>
 
         <example id="zend.session.advanced_usage.controllers.example">
 
-            <title>Session Namensräume für Kontroller mit automatischem Verfall</title>
+            <title>Session Namensräume für Controller mit automatischem Verfall</title>
 
             <para>
-                Der folgende Code ist Teil eines Kontrollers der die Test Frage anzeigt und eine
+                Der folgende Code ist Teil eines Controllers der die Test Frage anzeigt und eine
                 boolsche Variable initialisiert die anzeigt ob eine geschickte Antwort zur Test
                 Frage akzeptiert werden sollte oder nicht. In diesem Fall wird dem Benutzer der
                 Anwendung 300 Sekunden Zeit gegeben die angezeigte Frage zu beantworten.
@@ -247,7 +247,7 @@ $s->setExpirationSeconds(60);
 
             <programlisting language="php"><![CDATA[
 // ...
-// Im Frage-View Kontroller
+// Im Frage-View Controller
 $testSpace = new Zend_Session_Namespace('testSpace');
 $testSpace->setExpirationSeconds(300, 'accept_answer');
 // Nur diese Variable ablaufen lassen
@@ -256,14 +256,14 @@ $testSpace->accept_answer = true;
 ]]></programlisting>
 
             <para>
-                Danach bestimmt der Kontroller der die Antworten für die Test Fragen bearbeitet ob
+                Danach bestimmt der Controller der die Antworten für die Test Fragen bearbeitet ob
                 eine Antwort akzeptiert wird oder nach basierend darauf ob der Benutzer die Antwort
                 in der erlaubten Zeit übermittelt hat:
             </para>
 
             <programlisting language="php"><![CDATA[
 // ...
-// Im Frage-Prozess Kontroller
+// Im Frage-Prozess Controller
  $testSpace = new Zend_Session_Namespace('testSpace');
  if ($testSpace->accept_answer === true) {
      // innerhalb der Zeit

documentation/manual/de/module_specs/Zend_Test-PHPUnit-Assertions.xml

@@ -8,7 +8,7 @@
         Ausnahmen sind der Herz vom Unit Testen; Sie können verwendet werden um zu prüfen das die
         Ergebnisse das sind was man erwartet. Zu diesem Zweck bietet
         <classname>Zend_Test_PHPUnit_ControllerTestCase</classname> eine Anzahl an Ausnahmen um das
-        Testen eigene MVC Anwendungen und Kontroller einfacher zu machen.
+        Testen eigene MVC Anwendungen und Controller einfacher zu machen.
     </para>
 
     <sect3 id="zend.test.phpunit.assertions.query">
@@ -222,7 +222,7 @@
         <title>Anfrage Ausnahmen</title>
 
         <para>
-            Es ist oft sinnvoll gegen die letzte Aktion, den Kontroller und das Modul zu prüfen;
+            Es ist oft sinnvoll gegen die letzte Aktion, den Controller und das Modul zu prüfen;
             zusätzlich ist es möglich die genommene Route die prüfen. Die folgenden Ausnahmen können
             in diesen Fällen helfen:
         </para>
@@ -234,7 +234,7 @@
             </para></listitem>
             <listitem><para>
                 <code>assertController($controller, $message = '')</code>: Nimmt an das der
-                angegebene Kontroller in der letzten ausgeführten Aktion ausgewählt wurde.
+                angegebene Controller in der letzten ausgeführten Aktion ausgewählt wurde.
             </para></listitem>
             <listitem><para>
                 <code>assertAction($action, $message = '')</code>: Nimmt an das die angegebene

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

@@ -20,8 +20,8 @@
 
     <para>
         Zuerst kann diese Eigenschaft so gesetzt werden das Sie auf eine Datei zeigt. Wenn das getan
-        wurde sollte diese Datei <emphasis>nicht</emphasis> den Front Kontroller ausführen, aber
-        stattdessen den Front Kontroller konfigurieren und alles was die Anwendung an speziellen
+        wurde sollte diese Datei <emphasis>nicht</emphasis> den Front Controller ausführen, aber
+        stattdessen den Front Controller konfigurieren und alles was die Anwendung an speziellen
         Dingen benötigt.
     </para>
 

documentation/manual/de/module_specs/Zend_Test-PHPUnit-Examples.xml

@@ -22,7 +22,7 @@
         <itemizedlist>
             <listitem><para>
                 Wenn ein Benutzer nicht authentifiziert ist, wird er immer zur Login Seite des
-                Kontrollers umgeleitet, unabhängig von der spezifizierten Aktion.
+                Controllers umgeleitet, unabhängig von der spezifizierten Aktion.
             </para></listitem>
 
             <listitem><para>

documentation/manual/de/module_specs/Zend_Test-PHPUnit-Testing.xml

@@ -2,7 +2,7 @@
 <!-- EN-Revision: 15617 -->
 <!-- Reviewed: no -->
 <sect2 id="zend.test.phpunit.testing">
-    <title>Testen eigener Kontroller und MVC Anwendungen</title>
+    <title>Testen eigener Controller und MVC Anwendungen</title>
 
     <para>
         Sobald man sein Bootstrap hat, kann man mit dem Testen beginnen. Testen funktioniert

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

@@ -35,7 +35,7 @@
             erlaubt unsere Umgebung geziehlt zu spezifizieren, und es uns ausserdem erlaubt die
             Anwendung in einer einzigen Zeile zu starten. Unser spezielles Beispiel nimmt auch an
             das das Setup automatisch lädt sodas wir uns nicht um das laden der betreffenden Klassen
-            kümmern müssen (wie die richtigen Kontroller, Plugins, usw).
+            kümmern müssen (wie die richtigen Controller, Plugins, usw).
         </para>
 
         <programlisting language="php"><![CDATA[

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

@@ -5,7 +5,7 @@
     <title>Action View Helfer</title>
 
     <para>
-        Der <code>Action</code> View Helfer ermöglicht es View Skripten eine gegebene Kontroller
+        Der <code>Action</code> View Helfer ermöglicht es View Skripten eine gegebene Controller
         Aktion auszuführen; das Ergebnis des Antwortsobjektes das der Ausführung folgt wird dann
         zurückgegeben. Dieses kann verwendet werden wenn eine bestimmte Aktion wiederverwendbare
         Inhalte oder "helfende" Inhalte erstellt.
@@ -18,7 +18,7 @@
 
     <para>
         Die API für den <code>Action</code> View Helfer folgt dem der meisten MVC Komponenten die
-        Kontroller Aktionen aufrufen:
+        Controller Aktionen aufrufen:
         <code>action($action, $controller, $module = null, array $params = array())</code>.
         <code>$action</code> und <code>$controller</code> werden benötigt; wenn kein Modul angegeben
         wird, dann wird das Standardmodul angenommen.

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

@@ -27,12 +27,12 @@
 
         <para>
             Es kann jederzeit ein Titel Tag spezifiziert werden. Die typische Verwendung besteht
-            darin das Titel Segment bei jedem Level an Tiefe in der Anwendung: Site, Kontroller,
+            darin das Titel Segment bei jedem Level an Tiefe in der Anwendung: Site, Controller,
             Aktion und potentiell Ressourcen.
         </para>
 
         <programlisting language="php"><![CDATA[
-// Setzen des Kontroller und Aktion Namens als Titel Segment:
+// Setzen des Controller und Aktion Namens als Titel Segment:
 $request = Zend_Controller_Front::getInstance()->getRequest();
 $this->headTitle($request->getActionName())
      ->headTitle($request->getControllerName());