Преглед изворни кода

[DOCUMENTATION] German:

- manual fixes

git-svn-id: http://framework.zend.com/svn/framework/standard/trunk@15364 44c647ce-9c0f-0410-b52a-842ac1e357ba
thomas пре 16 година
родитељ
комит
8cb6f4b1a4

+ 129 - 117
documentation/manual/de/ref/coding_standard.xml

@@ -252,10 +252,11 @@ widgetFactory()
             </para>
 
             <para>
-                Für Instanzvariablen die mit dem "private" oder "protected" Modifikator deklariert werden,
-                muß das erste Zeichen des Funktionsnamens ein einzelner Unterstrich sein. Das ist die
-                einzige akzeptierte Anwendung eines Unterstriches in einem variablen Namen. Klassenvariablen
-                welche als "public" deklariert werden sollten nie mit einem Unterstrich beginnen.
+                Für Instanzvariablen die mit dem "private" oder "protected" Modifikator deklariert
+                werden, muß das erste Zeichen des Funktionsnamens ein einzelner Unterstrich sein.
+                Das ist die einzige akzeptierte Anwendung eines Unterstriches in einem variablen
+                Namen. Klassenvariablen welche als "public" deklariert werden sollten nie mit einem
+                Unterstrich beginnen.
             </para>
 
             <para>
@@ -264,11 +265,11 @@ widgetFactory()
             </para>
 
             <para>
-                Wortreichtum wird generell befürwortet. Variablen sollen immer so wortreich wie möglich sein
-                um die Daten zu beschreiben die der Entwickler in Ihnen zu speichern gedenkt.
-                Von gedrängte Variablennamen wie "$i" und "$n" wird abgeraten für alles außer die kleinsten
-                Schleifen. Wenn eine Schleife mehr als 20 Codezeilen enthält sollten die Index-Variablen
-                einen ausführlicheren Namen haben.
+                Wortreichtum wird generell befürwortet. Variablen sollen immer so wortreich wie
+                möglich sein um die Daten zu beschreiben die der Entwickler in Ihnen zu speichern
+                gedenkt. Von gedrängte Variablennamen wie "$i" und "$n" wird abgeraten für alles
+                außer die kleinsten Schleifen. Wenn eine Schleife mehr als 20 Codezeilen enthält
+                sollten die Index-Variablen einen ausführlicheren Namen haben.
             </para>
         </sect2>
 
@@ -276,13 +277,13 @@ widgetFactory()
             <title>Konstanten</title>
 
             <para>
-                Konstanten können beides enthalten, sowohl Alphanummerische Zeichen als auch Unterstriche.
-                Nummern sind in Konstantennamen gestattet.
+                Konstanten können beides enthalten, sowohl Alphanummerische Zeichen als auch
+                Unterstriche. Nummern sind in Konstantennamen gestattet.
             </para>
 
             <para>
-                Alle Buchstaben die in Konstantenname verwendet werden müssen großgeschrieben haben, wärend
-                Wörter in einem Konstantennamen durch Unterstriche getrennt werden müssen.
+                Alle Buchstaben die in Konstantenname verwendet werden müssen großgeschrieben haben,
+                wärend Wörter in einem Konstantennamen durch Unterstriche getrennt werden müssen.
             </para>
 
             <para>
@@ -291,9 +292,9 @@ widgetFactory()
             </para>
 
             <para>
-                Konstanten müssen als Klassenkonstanten definiert werden mit dem "const" Modifikator.
-                Die Definition von Konstanten im globalen Bereich mit der "define" Funktion ist gestattet
-                aber es wird es wird stärkstens davon abgeraten.
+                Konstanten müssen als Klassenkonstanten definiert werden mit dem "const"
+                Modifikator. Die Definition von Konstanten im globalen Bereich mit der "define"
+                Funktion ist gestattet aber es wird es wird stärkstens davon abgeraten.
             </para>
         </sect2>
     </sect1>
@@ -328,9 +329,9 @@ widgetFactory()
                 <title>String Literale</title>
 
                 <para>
-                    Wenn ein String ein Literal ist (er also keine Variablenvertreter enthält), sollte
-                    immer das Apostroph oder "einzelne Anführungszeichen" verwendet werden um den String
-                    abzugrenzen:
+                    Wenn ein String ein Literal ist (er also keine Variablenvertreter enthält),
+                    sollte immer das Apostroph oder "einzelne Anführungszeichen" verwendet werden um
+                    den String abzugrenzen:
 
                     <programlisting role="php"><![CDATA[
 $a = 'Beispiel String';
@@ -342,17 +343,17 @@ $a = 'Beispiel String';
                 <title>String Literale die Apostrophe enthalten</title>
 
                 <para>
-                    Wenn ein literaler String selbst Apostrophe enthält, ist es gestattet den String mit
-                    Anführungszeichen oder "doppeltes Anführungszeichen" abzugrenzen. Das ist speziell für
-                    SQL Anweisungen nützlich:
+                    Wenn ein literaler String selbst Apostrophe enthält, ist es gestattet den String
+                    mit Anführungszeichen oder "doppeltes Anführungszeichen" abzugrenzen. Das ist
+                    speziell für SQL Anweisungen nützlich:
 
                     <programlisting role="php"><![CDATA[
 $sql = "SELECT `id`, `name` from `people` "
      . "WHERE `name`='Fred' OR `name`='Susan'";
 ]]></programlisting>
 
-                    Diese Syntax ist zu bevorzugen, im Gegensatz zum Ausbruch von Apostrophs, da Sie viel
-                    einfacher lesbar ist.
+                    Diese Syntax ist zu bevorzugen, im Gegensatz zum Ausbruch von Apostrophs, da Sie
+                    viel einfacher lesbar ist.
                 </para>
             </sect3>
 
@@ -382,8 +383,9 @@ $greeting = "Hallo ${name}, willkommen zurück!";
                 <title>Verbinden von Strings</title>
 
                 <para>
-                    Strings müssen verbunden werden indem man den "." Operator verwendet. Ein Leerzeichen muß
-                    immer vor und nach dem "." Operator hinzugefügt werden um die Lesbarkeit zu erhöhen:
+                    Strings müssen verbunden werden indem man den "." Operator verwendet. Ein
+                    Leerzeichen muß immer vor und nach dem "." Operator hinzugefügt werden um die
+                    Lesbarkeit zu erhöhen:
 
                     <programlisting role="php"><![CDATA[
 $company = 'Zend' . ' ' . 'Technologies';
@@ -391,10 +393,10 @@ $company = 'Zend' . ' ' . 'Technologies';
                 </para>
 
                 <para>
-                    Wenn Strings mit dem "." Operator verbunden werden, ist es empfohlen die Anweisung in
-                    mehrere Zeilen umzubrechen um die Lesbarkeit zu erhöhen. In diesen Fällen sollte jede
-                    folgende Zeile mit Leerraum aufgefüllt werden so das der "." Operator genau unterhalb
-                    des "=" Operators ist:
+                    Wenn Strings mit dem "." Operator verbunden werden, ist es empfohlen die
+                    Anweisung in mehrere Zeilen umzubrechen um die Lesbarkeit zu erhöhen. In diesen
+                    Fällen sollte jede folgende Zeile mit Leerraum aufgefüllt werden so das der "."
+                    Operator genau unterhalb des "=" Operators ist:
 
                     <programlisting role="php"><![CDATA[
 $sql = "SELECT `id`, `name` FROM `people` "
@@ -414,14 +416,14 @@ $sql = "SELECT `id`, `name` FROM `people` "
                 <para>Negative Nummern sind in Indezes nicht gestattet.</para>
 
                 <para>
-                    Ein indiziertes Array kann mit mit irgendeiner nicht-negativen Nummer beginnen, trotzdem
-                    sind alle BasisIndex neben 0 nicht erlaubt.
+                    Ein indiziertes Array kann mit mit irgendeiner nicht-negativen Nummer beginnen,
+                    trotzdem sind alle BasisIndex neben 0 nicht erlaubt.
                 </para>
 
                 <para>
-                    Wenn indizierte Arrays mit dem <code>array</code> Funktion deklariert werden, muß ein
-                    folgendes Leerzeichen nach jeder Kommabegrenzung hinzugefügt werden um die Lesbarkeit
-                    zu erhöhen:
+                    Wenn indizierte Arrays mit dem <code>array</code> Funktion deklariert werden,
+                    muß ein folgendes Leerzeichen nach jeder Kommabegrenzung hinzugefügt werden um
+                    die Lesbarkeit zu erhöhen:
 
                     <programlisting role="php"><![CDATA[
 $sampleArray = array(1, 2, 3, 'Zend', 'Studio');
@@ -430,8 +432,8 @@ $sampleArray = array(1, 2, 3, 'Zend', 'Studio');
 
                 <para>
                     Es ist gestattet mehrzeilige indizierte Arrays zu definieren bei Verwendung des
-                    "array" Konstrukts. In diesem Fall, muß jede folgende Zeile mit Leerzeichen aufgefüllt
-                    werden so das der Beginn jeder Zeile ausgerichtet ist:
+                    "array" Konstrukts. In diesem Fall, muß jede folgende Zeile mit Leerzeichen
+                    aufgefüllt werden so das der Beginn jeder Zeile ausgerichtet ist:
 
                     <programlisting role="php"><![CDATA[
 $sampleArray = array(1, 2, 3, 'Zend', 'Studio',
@@ -445,10 +447,10 @@ $sampleArray = array(1, 2, 3, 'Zend', 'Studio',
                 <title>Assoziative Arrays</title>
 
                 <para>
-                    Wenn assoziative Arrays mit dem <code>array</code> Konstrukt deklariert werden, ist das
-                    Umbrechen der Anweisung in mehrere Zeilen gestattet. In diesem Fall muß jede folgende
-                    Linie mit Leerraum aufgefüllt werden so das beide, der Schlüssel und der Wert untereinander
-                    stehen:
+                    Wenn assoziative Arrays mit dem <code>array</code> Konstrukt deklariert werden,
+                    ist das Umbrechen der Anweisung in mehrere Zeilen gestattet. In diesem Fall muß
+                    jede folgende Linie mit Leerraum aufgefüllt werden so das beide, der Schlüssel
+                    und der Wert untereinander stehen:
 
                     <programlisting role="php"><![CDATA[
 $sampleArray = array('firstKey'  => 'firstValue',
@@ -469,15 +471,16 @@ $sampleArray = array('firstKey'  => 'firstValue',
                 </para><para>
                     Die Klammer sollte immer in der Zeile unter dem Klassennamen geschrieben werden.
                 </para><para>
-                    Jede Klasse muß einen Dokumentationsblock haben der dem PHPDocumentor Standard entspricht.
+                    Jede Klasse muß einen Dokumentationsblock haben der dem PHPDocumentor Standard
+                    entspricht.
                 </para><para>
                     Jeder Code in der Klasse muß mit vier Leerzeichen eingerückt sein.
                 </para><para>
                     Nur eine Klasse ist in jeder PHP Datei gestattet.
                 </para><para>
-                    Das Platzieren von zusätzlichem Code in Klassendateien ist gestattet aber es wird davon
-                    abgeraten. In solchen Dateien müssen zwei leere Zeilen die Klasse von jedem zusätzlichen PHP
-                    Code in der Datei seperieren.
+                    Das Platzieren von zusätzlichem Code in Klassendateien ist gestattet aber es
+                    wird davon abgeraten. In solchen Dateien müssen zwei leere Zeilen die Klasse von
+                    jedem zusätzlichen PHP Code in der Datei seperieren.
                 </para><para>
                     Das folgende ist ein Beispiel einer akzeptierbaren Klassendeklaration:
 
@@ -502,15 +505,16 @@ class SampleClass
                     Zend Frameworks benannt werden.
                 </para>
                 <para>
-                    Jede Variable die in der Klasse deklariert wird muß am Beginn der Klasse ausgelistet werden,
-                    vor der Deklaration von allen Methoden.
+                    Jede Variable die in der Klasse deklariert wird muß am Beginn der Klasse
+                    ausgelistet werden, vor der Deklaration von allen Methoden.
                 </para>
                 <para>
-                    Das <code>var</code> Konstrukt ist nicht gestattet. Klassenvariablen definieren Ihre
-                    Sichtbarkeit durch die Verwendung des <code>private</code>, <code>protected</code>,
-                    oder <code>public</code> Modifikatoren. Das gestatten von direktem Zugriff auf
-                    Klassenvariablen durch deren Deklaration als public ist gestattet aber es wird davon
-                    abgeraten da hierfür Zugriffsmethoden verwendet werden sollten (set/get).
+                    Das <code>var</code> Konstrukt ist nicht gestattet. Klassenvariablen definieren
+                    Ihre Sichtbarkeit durch die Verwendung des <code>private</code>,
+                    <code>protected</code>, oder <code>public</code> Modifikatoren. Das gestatten
+                    von direktem Zugriff auf Klassenvariablen durch deren Deklaration als public ist
+                    gestattet aber es wird davon abgeraten da hierfür Zugriffsmethoden verwendet
+                    werden sollten (set/get).
                 </para>
             </sect3>
         </sect2>
@@ -522,25 +526,27 @@ class SampleClass
                 <title>Deklaration von Funktionen und Methoden</title>
 
                 <para>
-                    Funktionen müssen nach der Funktions-Namenskonvention des Zend Frameworks benannt werden.
+                    Funktionen müssen nach der Funktions-Namenskonvention des Zend Frameworks
+                    benannt werden.
                 </para>
                 <para>
-                    Methoden innerhalb von Klassen müssen immer Ihre Sichtbarkeit durch Verwendung einer der
-                    <code>private</code>, <code>protected</code>, oder <code>public</code> Modifikatoren
-                    definieren.
+                    Methoden innerhalb von Klassen müssen immer Ihre Sichtbarkeit durch Verwendung
+                    einer der <code>private</code>, <code>protected</code>, oder <code>public</code>
+                    Modifikatoren definieren.
                 </para>
                 <para>
-                    Wie bei Klassen, sollte die Klammer immer in der Zeile unterhalb des Funktionsnamens
-                    geschrieben werden.
+                    Wie bei Klassen, sollte die Klammer immer in der Zeile unterhalb des
+                    Funktionsnamens geschrieben werden.
 
-                    Leerzeichen zwischen dem Funktionsnamen und der öffnenden Klammer für die Argumente
-                    sind nicht erlaubt.
+                    Leerzeichen zwischen dem Funktionsnamen und der öffnenden Klammer für die
+                    Argumente sind nicht erlaubt.
                 </para>
                 <para>
                     Von Funktionen im globalen Raum wird komplett abgeraten.
                 </para>
                 <para>
-                    Das folgende ist ein Beispiel einer akzeptierbaren Funktionsdeklaration in einer Klasse:
+                    Das folgende ist ein Beispiel einer akzeptierbaren Funktionsdeklaration in einer
+                    Klasse:
 
                     <programlisting role="php"><![CDATA[
 /**
@@ -561,8 +567,8 @@ class Foo
                 </para>
 
                 <para>
-                    <emphasis>NOTIZ:</emphasis> Die Übergabe per Referenz ist die einzige erlaubt Mechanismus
-                    für die Übergabe von Parametern in der Deklaration einer Funktion:
+                    <emphasis>NOTIZ:</emphasis> Die Übergabe per Referenz ist die einzige erlaubt
+                    Mechanismus für die Übergabe von Parametern in der Deklaration einer Funktion:
 
                     <programlisting role="php"><![CDATA[
 /**
@@ -584,9 +590,9 @@ class Foo
                 </para>
 
                 <para>
-                    Der Rückgabewert darf nicht in Klammern stehen. Das kann die Lesbarkeit behindern und
-                    zusätzlich den Code unterbrechen wenn eine Methode später später auf Rückgabe durch
-                    Referenz geändert wird.
+                    Der Rückgabewert darf nicht in Klammern stehen. Das kann die Lesbarkeit
+                    behindern und zusätzlich den Code unterbrechen wenn eine Methode später auf
+                    Rückgabe durch Referenz geändert wird.
 
                     <programlisting role="php"><![CDATA[
 /**
@@ -619,9 +625,9 @@ class Foo
                 <title>Verwendung von Funktionen und Methoden</title>
 
                 <para>
-                    Funktionsargumente sollten durch ein einzelnes trennendes Leerzeichen nach dem Komma
-                    Trennzeichen getrennt werden. Das folgende ist ein Beispiel für einen akzeptierbaren
-                    Aufruf einer Funktion die drei Argumente benötigt:
+                    Funktionsargumente sollten durch ein einzelnes trennendes Leerzeichen nach dem
+                    Komma Trennzeichen getrennt werden. Das folgende ist ein Beispiel für einen
+                    akzeptierbaren Aufruf einer Funktion die drei Argumente benötigt:
 
                     <programlisting role="php"><![CDATA[
 threeArguments(1, 2, 3);
@@ -629,15 +635,15 @@ threeArguments(1, 2, 3);
                 </para>
 
                 <para>
-                    Übergabe von Referenzen zur Laufzeit ist strengstens verboten. Siehe die Sektion für
-                    Funktions Deklarationen für den richtigen Weg um Funktionsargumente per Referenz
-                    zu übergeben.
+                    Übergabe von Referenzen zur Laufzeit ist strengstens verboten. Siehe die Sektion
+                    für Funktions Deklarationen für den richtigen Weg um Funktionsargumente per
+                    Referenz zu übergeben.
                 </para>
                 <para>
                     Durch die Übergabe von Arrays als Argument für eine Funktion, kann der
-                    Funktionsaufruf den "array" Hinweis enthalten und kann in mehrere Zeilen geteilt werden
-                    um die Lesbarkeit zu erhöhen. In solchen Fällen sind die normalen Richtlinien für
-                    das Schreiben von Arrays trotzdem noch anzuwenden:
+                    Funktionsaufruf den "array" Hinweis enthalten und kann in mehrere Zeilen geteilt
+                    werden um die Lesbarkeit zu erhöhen. In solchen Fällen sind die normalen
+                    Richtlinien für das Schreiben von Arrays trotzdem noch anzuwenden:
 
                     <programlisting role="php"><![CDATA[
 threeArguments(array(1, 2, 3), 2, 3);
@@ -657,21 +663,24 @@ threeArguments(array(1, 2, 3, 'Zend', 'Studio',
                 <title>If/Else/Elseif</title>
 
                 <para>
-                    Kontrollanweisungen die auf den <code>if</code> und <code>elseif</code> Konstrukten
-                    beruhen müssen ein einzelnes Leerzeichen vor der öffnenden Klammer der bedingten Anweisung
-                    und ein einzelnes Leerzeichen nach der schließenden Klammer.
+                    Kontrollanweisungen die auf den <code>if</code> und <code>elseif</code>
+                    Konstrukten beruhen müssen ein einzelnes Leerzeichen vor der öffnenden Klammer
+                    der bedingten Anweisung und ein einzelnes Leerzeichen nach der schließenden
+                    Klammer.
                 </para>
 
                 <para>
-                    Innerhalb der bedingten Anweisungen zwischen den Klammern, müssen die Operationen, für die
-                    Lesbarkeit, durch Leerzeichen getrennt werden. Innere Klammern sind zu befürworten um
-                    die logische Gruppierung für größeren bedingte Anweisungen zu erhöhen.
+                    Innerhalb der bedingten Anweisungen zwischen den Klammern, müssen die
+                    Operationen, für die Lesbarkeit, durch Leerzeichen getrennt werden. Innere
+                    Klammern sind zu befürworten um die logische Gruppierung für größeren bedingte
+                    Anweisungen zu erhöhen.
                 </para>
 
                 <para>
-                    Die öffnende Klammer wird in der selben Zeile geschrieben wie die Bedingungsanweisung.
-                    Die schließende Klammer wird immer in einer eigenen Zeile geschrieben. Jeder Inhalt innerhalb
-                    der Klammer muß durch Verwendung von vier Leerzeichen eingerückt werden.
+                    Die öffnende Klammer wird in der selben Zeile geschrieben wie die
+                    Bedingungsanweisung. Die schließende Klammer wird immer in einer eigenen Zeile
+                    geschrieben. Jeder Inhalt innerhalb der Klammer muß durch Verwendung von vier
+                    Leerzeichen eingerückt werden.
 
                     <programlisting role="php"><![CDATA[
 if ($a != 2) {
@@ -701,13 +710,13 @@ if ($a != 2) {
 }
 ]]></programlisting>
                     PHP erlaubt das Anweisungen in einigen Fällen auch ohne Klammern zu schreiben.
-                    Dieser Coding Standard macht keine Unterscheidungen und es müssen alle "if", "elseif" oder "else"
-                    Anweisungen in Klammern geschrieben werden.
+                    Dieser Coding Standard macht keine Unterscheidungen und es müssen alle "if",
+                    "elseif" oder "else" Anweisungen in Klammern geschrieben werden.
                 </para>
 
                 <para>
-                    Die Verwendung des "elseif" Konstruktes ist erlaubt es wird aber strengstens davon abgeraten
-                    und es ist die "else if" Kombination zu bevorzugen.
+                    Die Verwendung des "elseif" Konstruktes ist erlaubt es wird aber strengstens
+                    davon abgeraten und es ist die "else if" Kombination zu bevorzugen.
                 </para>
             </sect3>
 
@@ -715,15 +724,15 @@ if ($a != 2) {
                 <title>Switch</title>
 
                 <para>
-                    Kontrollanweisungen die mit der "switch" Anweisung geschrieben werden müssen ein einzelnes
-                    Leerzeichen vor der öffnenden Klammer der Bedingten Anweisung besitzen, und auch
-                    nach der schließenden Klammer.
+                    Kontrollanweisungen die mit der "switch" Anweisung geschrieben werden müssen ein
+                    einzelnes Leerzeichen vor der öffnenden Klammer der Bedingten Anweisung
+                    besitzen, und auch nach der schließenden Klammer.
                 </para>
 
                 <para>
-                    Jeglicher Inhalt innerhalb der "switch" Anweisung muß durch Verwendung von vier Leerzeichen
-                    eingerückt sein. Der Inhalt unter jeder "case" Anweisung muß durch Verwendung von vier
-                    zusätzlichen Leerzeichen eingerückt werden.
+                    Jeglicher Inhalt innerhalb der "switch" Anweisung muß durch Verwendung von vier
+                    Leerzeichen eingerückt sein. Der Inhalt unter jeder "case" Anweisung muß durch
+                    Verwendung von vier zusätzlichen Leerzeichen eingerückt werden.
                 </para>
 
                 <programlisting role="php"><![CDATA[
@@ -740,17 +749,18 @@ switch ($numPeople) {
 ]]></programlisting>
 
                 <para>
-                    Das <code>default</code> Konstrukt darf nie bei der <code>switch</code> Anweisung vergessen
-                    werden.
+                    Das <code>default</code> Konstrukt darf nie bei der <code>switch</code>
+                    Anweisung vergessen werden.
                 </para>
 
                 <para>
-                    <emphasis>NOTIZ:</emphasis> Es ist machmal nützlich eine <code>case</code> Anweisung zu
-                    schreiben, die durch das nächste case fällt indem innerhalb solcher Fälle kein
-                     <code>break</code> oder <code>return</code> angegeben wird. Um diese Fälle von Fehlern
-                     zu unterscheiden, sollte jede <code>case</code> Anweisung in der <code>break</code>
-                     oder <code>return</code> unterlassen werden einen Kommentar enthalten der anzeigt das
-                     das break gewünschtermaßen unterdrückt wurde.
+                    <emphasis>NOTIZ:</emphasis> Es ist machmal nützlich eine <code>case</code>
+                    Anweisung zu schreiben, die durch das nächste case fällt indem innerhalb solcher
+                    Fälle kein <code>break</code> oder <code>return</code> angegeben wird. Um diese
+                    Fälle von Fehlern zu unterscheiden, sollte jede <code>case</code> Anweisung in
+                    der <code>break</code> oder <code>return</code> unterlassen werden einen
+                    Kommentar enthalten der anzeigt das das break gewünschtermaßen unterdrückt
+                    wurde.
                 </para>
             </sect3>
         </sect2>
@@ -762,16 +772,16 @@ switch ($numPeople) {
                 <title>Dokumentations Format</title>
 
                 <para>
-                    Alle Dokumentations Blöcke ("DocBlock") müssel mit dem phpDocumentor Format kompatibel sein.
-                    Die Beschreibung des phpDocumentor Formats is jenseits der Reichweite dieses Dokuments.
-                    Für weiterführende Informationen siehe:
+                    Alle Dokumentations Blöcke ("DocBlock") müssel mit dem phpDocumentor Format
+                    kompatibel sein. Die Beschreibung des phpDocumentor Formats is jenseits der
+                    Reichweite dieses Dokuments. Für weiterführende Informationen siehe:
                     <ulink url="http://phpdoc.org/">http://phpdoc.org"></ulink>
                 </para>
 
                 <para>
-                    Alle Klassen Dateien müssen einen "file-level" Docblock am Beginn jeder Datei und einen
-                    "class-level" Docblock direkt überhalb jeder Klasse enthalten. Beispiele solcher
-                    Docblocks können anbei gefunden werden.
+                    Alle Klassen Dateien müssen einen "file-level" Docblock am Beginn jeder Datei
+                    und einen "class-level" Docblock direkt überhalb jeder Klasse enthalten.
+                    Beispiele solcher Docblocks können anbei gefunden werden.
                 </para>
             </sect3>
 
@@ -779,8 +789,8 @@ switch ($numPeople) {
                 <title>Dateien</title>
 
                 <para>
-                    Jede Datei die PHP Code enthält muß einen Docblock am Beginn der Datei besitzen welcher
-                    mindestens diese phpDocumentor Tags enthält:
+                    Jede Datei die PHP Code enthält muß einen Docblock am Beginn der Datei besitzen
+                    welcher mindestens diese phpDocumentor Tags enthält:
 
                     <programlisting role="php"><![CDATA[
 /**
@@ -804,7 +814,8 @@ switch ($numPeople) {
                 <title>Klassen</title>
 
                 <para>
-                    Jede Klasse muß einen Docblock haben welche mindestens diese phpDocumentor Tags enthält:
+                    Jede Klasse muß einen Docblock haben welche mindestens diese phpDocumentor Tags
+                    enthält:
 
                     <programlisting role="php"><![CDATA[
 /**
@@ -827,8 +838,8 @@ switch ($numPeople) {
                 <title>Funktionen</title>
 
                 <para>
-                Jede Funktion, auch Objekt Methoden, müssen einen Docblock haben welcher mindestens folgendes
-                enthält:
+                Jede Funktion, auch Objekt Methoden, müssen einen Docblock haben welcher mindestens
+                folgendes enthält:
 
                     <itemizedlist>
                         <listitem><para>Eine Beschreibung der Funktion</para></listitem>
@@ -838,13 +849,14 @@ switch ($numPeople) {
                 </para>
 
                 <para>
-                    Es ist nicht notwendig das "@access" Tag zu verwenden, weil das Accesslevel bereits vom
-                    "public", "private" oder "protected" Modifikator bekannt ist wenn die Funktion deklariert wird.
+                    Es ist nicht notwendig das "@access" Tag zu verwenden, weil das Accesslevel
+                    bereits vom "public", "private" oder "protected" Modifikator bekannt ist wenn
+                    die Funktion deklariert wird.
                 </para>
 
                 <para>
-                    Wenn eine Funktion/Methode eine Ausnahme werfen könnte, muß @throws für alle bekannten
-                    Exception Klassen verwendet werden:
+                    Wenn eine Funktion/Methode eine Ausnahme werfen könnte, muß @throws für alle
+                    bekannten Exception Klassen verwendet werden:
 
                     <programlisting role="php"><![CDATA[
 @throws exceptionclass [Beschreibung]

+ 4 - 4
documentation/manual/de/ref/performance-classloading.xml

@@ -273,8 +273,8 @@ Zend_Loader_Autoloader::getInstance();
             </para></listitem>
 
             <listitem><para>
-                <classname>Zend_Filter_Inflector</classname>: Filter (verwendet vom ViewRenderer Action
-                Helfer und Zend_Layout)
+                <classname>Zend_Filter_Inflector</classname>: Filter (verwendet vom ViewRenderer
+                Action Helfer und Zend_Layout)
             </para></listitem>
 
             <listitem><para>
@@ -282,8 +282,8 @@ Zend_Loader_Autoloader::getInstance();
             </para></listitem>
 
             <listitem><para>
-                <classname>Zend_Form</classname>: Elemente, Prüfungen, Filter, Dekoratore, Captcha und
-                File Transfer Adapter
+                <classname>Zend_Form</classname>: Elemente, Prüfungen, Filter, Dekoratore, Captcha
+                und File Transfer Adapter
             </para></listitem>
 
             <listitem><para>

+ 24 - 21
documentation/manual/de/ref/performance-database.xml

@@ -6,10 +6,11 @@
 
     <para>
         <classname>Zend_Db</classname> ist ein Datenbank Abstraktion Layer und ist dazu gedacht eine
-        gemeinsame API für SQL Operationen zu bieten. <classname>Zend_Db_Table</classname> ist ein Table
-        Data Bateway, dazu gedacht übliche Tabellen-artige Datenbank Operationen zu abstrahieren.
-        Wegen Ihrer abstrakten Natur und der "Magie" die Sie versteckt haben um Ihre Operationen
-        durchführen zu können, können Sie manchmal auch zu Geschwindigkeitsnachteilen führen.
+        gemeinsame API für SQL Operationen zu bieten. <classname>Zend_Db_Table</classname> ist ein
+        Table Data Bateway, dazu gedacht übliche Tabellen-artige Datenbank Operationen zu
+        abstrahieren. Wegen Ihrer abstrakten Natur und der "Magie" die Sie versteckt haben um Ihre
+        Operationen durchführen zu können, können Sie manchmal auch zu Geschwindigkeitsnachteilen
+        führen.
     </para>
 
     <sect2 id="performance.database.tableMetadata">
@@ -20,11 +21,11 @@
 
         <para>
             Um die Verwendung so einfach wie möglich zu halten, und auch sich konstant ändernde
-            Schemata wärend der Entwicklung zu unterstützen, macht <classname>Zend_Db_Table</classname>
-            einiges an Magie unter seinem Hut: bei der ersten Verwendung, holt es das
-            Tabellenschema und speichert es im Objekt. Diese Operation ist normalerweise sehr
-            teuer, unabhängig von der Datenbank -- das zu einer Schwachstelle in der Produktion
-            führen kann.
+            Schemata wärend der Entwicklung zu unterstützen, macht
+            <classname>Zend_Db_Table</classname> einiges an Magie unter seinem Hut: bei der ersten
+            Verwendung, holt es das Tabellenschema und speichert es im Objekt. Diese Operation ist
+            normalerweise sehr teuer, unabhängig von der Datenbank -- das zu einer Schwachstelle in
+            der Produktion führen kann.
         </para>
 
         <para>
@@ -35,15 +36,16 @@
             <title>Den Metadaten Cache verwenden</title>
 
             <para>
-                <classname>Zend_Db_Table</classname> kann optional <classname>Zend_Cache</classname> verwenden um die
-                Metadaten der Tabelle zu cachen. Dieser ist typischerweise schneller im Zugriff
-                und nicht so teuer wie das holen der Metadaten von der Tabelle selbst.
+                <classname>Zend_Db_Table</classname> kann optional <classname>Zend_Cache</classname>
+                verwenden um die Metadaten der Tabelle zu cachen. Dieser ist typischerweise
+                schneller im Zugriff und nicht so teuer wie das holen der Metadaten von der Tabelle
+                selbst.
             </para>
 
             <para>
-                Die Dokumentation von <link linkend="zend.db.table.metadata.caching">
-                <classname>Zend_Db_Table</classname> enthält Informationen über das Cachen der Metadaten
-                </link>.
+                Die Dokumentation von <link
+                    linkend="zend.db.table.metadata.caching"><classname>Zend_Db_Table</classname>
+                    enthält Informationen über das Cachen der Metadaten</link>.
             </para>
         </sect3>
 
@@ -68,18 +70,19 @@
         </title>
 
         <para>
-            <classname>Zend_Db_Select</classname> ist relativ gut in seinem Job. Trotzdem kann es, wenn man
-            komplexe Abfragen benötigt die Joins oder Unterabfragen enthalten, sehr naiv sein.
+            <classname>Zend_Db_Select</classname> ist relativ gut in seinem Job. Trotzdem kann es,
+            wenn man komplexe Abfragen benötigt die Joins oder Unterabfragen enthalten, sehr naiv
+            sein.
         </para>
 
         <sect3 id="performance.database.select.writeyourown">
             <title>Selbst getuntes SQL schreiben</title>
 
             <para>
-                Die einzige echte Antwort ist es eigenes SQL zu schreiben; <classname>Zend_Db</classname>
-                erfordert nicht die Verwendung von <classname>Zend_Db_Select</classname>, als ist die
-                Verwendung von eigenen, getunten SQL Select Statements, eine perfekte und legitime
-                Anwendung.
+                Die einzige echte Antwort ist es eigenes SQL zu schreiben;
+                <classname>Zend_Db</classname> erfordert nicht die Verwendung von
+                <classname>Zend_Db_Select</classname>, als ist die Verwendung von eigenen, getunten
+                SQL Select Statements, eine perfekte und legitime Anwendung.
             </para>
             <para>
                 Lasse <code>EXPLAIN</code> auf den Abfragen laufen, und teste eine Vielzahl von

+ 7 - 6
documentation/manual/de/ref/performance-localization.xml

@@ -81,11 +81,11 @@
             <title>Verwenden von Übersetzungs und Lokalisierungs Caches</title>
 
             <para>
-                Beide, <classname>Zend_Translate</classname> und <classname>Zend_Locale</classname> implementieren eine
-                Caching Funktionalität die die Geschwindigkeit großartig verbessern kann. In jedem
-                der Fälle ist das das Nadelöhr typischerweise das Lesen der Dateien, nicht das
-                effektive Nachschauen; die Verwendung eines Caches eliminiert die Notwendigkeit die
-                Übersetzungsdateien und/oder Lokalisierungsdateien zu lesen.
+                Beide, <classname>Zend_Translate</classname> und <classname>Zend_Locale</classname>
+                implementieren eine Caching Funktionalität die die Geschwindigkeit großartig
+                verbessern kann. In jedem der Fälle ist das das Nadelöhr typischerweise das Lesen
+                der Dateien, nicht das effektive Nachschauen; die Verwendung eines Caches eliminiert
+                die Notwendigkeit die Übersetzungsdateien und/oder Lokalisierungsdateien zu lesen.
             </para>
 
             <para>
@@ -103,7 +103,8 @@
 
                 <listitem>
                     <para>
-                        <link linkend="zend.locale.cache"><classname>Zend_Locale</classname> Caching</link>
+                        <link linkend="zend.locale.cache"><classname>Zend_Locale</classname>
+                        Caching</link>
                     </para>
                 </listitem>
             </itemizedlist>

+ 26 - 26
documentation/manual/de/ref/performance-view.xml

@@ -6,12 +6,12 @@
 
     <para>
         Wenn man den MVC Layer vom Zend Framework verwendet, sind die Chancen das man
-        <classname>Zend_View</classname> verwendet recht hoch. <classname>Zend_View</classname> ist performant
-        verglichen mit anderen View oder Templating Engines; da View Skripte in PHP geschrieben
-        sind muß man weder den Overhead eines Kompilierungssystems zu PHP auf sich nehmen, noch muß
-        man darauf achten das das kompilierte PHP nicht optimiert ist. Trotzdem zeigt
-        <classname>Zend_View</classname> seine eigenen Probleme: Erweiterungen werden durch überladen (View
-        Helfer) durchgeführt, und eine Anzahl von View Helfern, die dadurch
+        <classname>Zend_View</classname> verwendet recht hoch. <classname>Zend_View</classname> ist
+        performant verglichen mit anderen View oder Templating Engines; da View Skripte in PHP
+        geschrieben sind muß man weder den Overhead eines Kompilierungssystems zu PHP auf sich
+        nehmen, noch muß man darauf achten das das kompilierte PHP nicht optimiert ist. Trotzdem
+        zeigt <classname>Zend_View</classname> seine eigenen Probleme: Erweiterungen werden durch
+        überladen (View Helfer) durchgeführt, und eine Anzahl von View Helfern, die dadurch
         Schlüsselfunktionalitäten bieten machen das auch, mit einem Verlust von Geschwindigkeit.
     </para>
 
@@ -19,23 +19,23 @@
         <title>Wie kann ich die Auflösung von View Helfern schneller machen?</title>
 
         <para>
-            Die meisten <classname>Zend_View</classname> "Methoden" werden in Wirklichkeit durch Überladen
-            des Helfersystems angeboten. Das bietet Zend_View wichtige Flexibilität; statt der
-            Notwendigkeit Zend_View zu erweitern und alle Helfermethoden anzubieten die man in der
-            eigenen Anwendung verwenden will, kann man eigene Helfermethoden in separaten Klassen
-            definieren und Sie bei Bedarf konsumieren wie wenn es direkte Methoden von Zend_View
-            wären. Das hält das View Objekt selbst relativ dünn, und stellt sicher das Objekte nur
-            erstellt werden wenn Sie auch benötigt werden.
+            Die meisten <classname>Zend_View</classname> "Methoden" werden in Wirklichkeit durch
+            Überladen des Helfersystems angeboten. Das bietet Zend_View wichtige Flexibilität; statt
+            der Notwendigkeit Zend_View zu erweitern und alle Helfermethoden anzubieten die man in
+            der eigenen Anwendung verwenden will, kann man eigene Helfermethoden in separaten
+            Klassen definieren und Sie bei Bedarf konsumieren wie wenn es direkte Methoden von
+            Zend_View wären. Das hält das View Objekt selbst relativ dünn, und stellt sicher das
+            Objekte nur erstellt werden wenn Sie auch benötigt werden.
         </para>
 
         <para>
-            Intern verwendet <classname>Zend_View</classname> den
-            <link linkend="zend.loader.pluginloader">PluginLoader</link> um nach Helferklassen zu
-            sehen. Das bedeutet das für jeden Helfer den man aufruft, <classname>Zend_View</classname> den
+            Intern verwendet <classname>Zend_View</classname> den <link
+            linkend="zend.loader.pluginloader">PluginLoader</link> um nach Helferklassen zu sehen.
+            Das bedeutet das für jeden Helfer den man aufruft, <classname>Zend_View</classname> den
             Helfernamen zum PluginLoader übergeben muß, welcher dann den Klassennamen erkennen muß
-            damit er instanziiert werden kann. Nachfolgende Aufrufe des Helfers sind viel
-            schneller, da <classname>Zend_View</classname> eine interne Registry von geladenen Helfern
-            behält, aber wenn man viele Helfer verwendet, werden die Aufrufe hinzuaddiert.
+            damit er instanziiert werden kann. Nachfolgende Aufrufe des Helfers sind viel schneller,
+            da <classname>Zend_View</classname> eine interne Registry von geladenen Helfern behält,
+            aber wenn man viele Helfer verwendet, werden die Aufrufe hinzuaddiert.
         </para>
 
         <para>
@@ -61,11 +61,11 @@
 
             <para>
                 Eine andere Lösung für jene die die Geschwindigkeit sogar noch mehr steigern wollen
-                ist es <classname>Zend_View</classname>zu erweitern um manuell die Helfermethoden die man am
-                meisten in seiner Anwendung verwendet hinzuzufügen. Solche Helfermethoden können
-                einfach manuell die betreffenden Helferklassen instanziiert und auf Sie verwesen
-                wird, oder indem die komplette Implementation des Helfers in die Methode eingefügt
-                wird.
+                ist es <classname>Zend_View</classname>zu erweitern um manuell die Helfermethoden
+                die man am meisten in seiner Anwendung verwendet hinzuzufügen. Solche Helfermethoden
+                können einfach manuell die betreffenden Helferklassen instanziiert und auf Sie
+                verwesen wird, oder indem die komplette Implementation des Helfers in die Methode
+                eingefügt wird.
             </para>
 
             <programlisting role="php"><![CDATA[
@@ -169,8 +169,8 @@ class My_View extends Zend_View
                 Grundsätzlich, solange man nicht Variablen an das Partial übergibt und einen reinen
                 Variablenraum benötigt, oder ein Viewskript von einem anderen MVC Modul darstellt,
                 gibt es keinen Grund den Overhead von <code>partial()</code> zu verwenden;
-                stattdessen sollte man <classname>Zend_View</classname>'s eingebaute <code>render()</code>
-                Methode verwendet um das Viewskript darzustellen.
+                stattdessen sollte man <classname>Zend_View</classname>'s eingebaute
+                <code>render()</code> Methode verwendet um das Viewskript darzustellen.
             </para>
         </sect3>
     </sect2>