Dieses Dokument bietet Richtlinien für die Erstellung der End-Benutzer Dokumentation, die im Zend Framework gefunden werden kann. Es ist als Richtlinie für die Mitglieder des Zend Framework gedacht, welche Dokumentationen als Teil ihrer übermittelten Komponenten Dokumentation schreiben müssen, sowie für die Übersetzer von Dokumentation. Der hier enthaltene Standard ist gedacht für einfache Übersetzung von Dokumentationen, minimalisieren von Visualisierung und stylistischen Unterschieden zwischen den unterschiedlichen Dokumentationsdateien, und macht das Finden von Änderungen in der Dokumentation einfacher mit diff Tools. Man kann diese Standards zusammen mit den Regeln unserer Lizenz adoptieren und oder modifizieren. Themen, die im Zend Framework Dokumentations Standard beschrieben sind, enthalten die Formatierung von Dokumentationsdateien sowie Empfehlungen für die Qualität der Dokumentation. Jede Datei des Manuals muss die folgenden XML Deklarationen am Beginn der Datei enthalten: ]]> XML Dateien von übersetzten Sprachen müssen auch ein Revisions Tag enthalten, das mit der Revision der englischen Sprachdatei korrespondiert, auf der die Übersetzung basiert. ]]> Die maximale Zeilenlänge, inklusive Tags, Attribute und Einrückungen, darf 100 Zeichen nicht überschreiten. Es gibt nur eine einzige Ausnahme zu dieser Regel: Attributen und Werte Paaren ist es erlaubt die 100 Zeichen zu überschreiten wenn diese nicht getrennt werden dürfen. Eine Einrückung sollte aus 4 Leerzeichen bestehen. Tabulatoren sind nicht erlaubt. Tags, welche auf dem gleichen Level sind, müssen auch die gleiche Einrückung haben. ]]> Tags, welche ein Level unter dem vorhergehenden Tag sind, müssen mit 4 zusätzlichen Leerzeichen eingerückt werden. ]]> Mehrere Block Tags in der gleichen Zeile sind nicht erlaubt; mehrere Inline Tags sind trotzdem erlaubt. Zend_Magic existiert nicht. Zend_Acl existiert. ]]> Die Zeilenendekennzeichen folgt der Unix Textdatei Konvention. Zeilen müssen mit einem einzelnen Linefeed (LF) Zeichen enden. Linefeed Zeichen werden als ordinale 10, oder Hexadezimale 0x0A repräsentiert. Beachte: Es sind keine Carriage Returns (CR) zu verwenden, welche die Konvention in Apple OS's (0x0D) sind, oder die Carriage Return - Linefeed Kombination (CRLF), welche der Standard für Windows OS (0x0D, 0x0A) sind. Leere Tags sind nicht erlaubt; alle Tags müssen Text oder Untertags enthalten. Irgendein Text. ]]> Öffnende Block Tags sollten direkt anschliessend keine Leerzeichen haben, sondern nur einen Zeilenumbruch (und Einrückungen in der folgenden Zeile). LEERZEICHEN ]]> Öffnende Inline Tags sollten keine Leerzeichen haben, die direkt folgen. Das ist die Klasse Zend_Class. Das ist die Klasse Zend_Class. ]]> Schließenden Block Tags können Leerzeichen vorangestellt sein, die dem aktuellen Einrückungslevel entsprechen, aber nicht mehr als diese Anzahl. ]]> Schließenden Inline Tags dürfen keine Leerzeichen vorangestellt sein. Das ist die Klasse Zend_Class Das ist die Klasse Zend_Class ]]> Mehrere Zeilenumbrüche innerhalb oder auch zwischen Tags sind nicht erlaubt. Etwas Text... ... und mehr Text. Anderer Paragraph. Etwas Text... ... und mehr Text Anderer Paragraph. ]]> Tags auf dem gleichen Level müssen durch eine leere Zeile getrennt sein, um die Lesbarkeit zu erhöhen. Etwas Text... Mehr Text... Etwas Text... Mehr Text... ]]> Das erste Untertag sollte direkt unterhalb seiner Eltern geöffnet werden, ohne dass eine leere Zeile zwischen ihnen ist; das letzte Untertag sollte direkt vor dem schließenden Tag seiner Eltern geschlossen werden. ]]> Das öffnende <programlisting> Tag muss das richtige "language" Attribut anzeigen und auf dem gleichen Level eingerückt sein wie die vorhergehenden Blöcke. Vorhergehender Paragraph. ]]>< CDATA sollte um alle Programmcode-Abschnitte vorhanden sein. <programlisting> Abschnitte dürfen keine Zeilenumbrüche oder Leerzeichen am Anfang oder Ende des Abschnitts besitzen, da diese auch in der endgültigen Ausgabe dargestellt werden. ]]><> ]]><> ]]> Endende CDATA und <programlisting> Tags sollten in der gleichen Zeile, aber ohne Einrückung stehen. ]]><> ]]><> ]]><> ]]> Das <programlisting> Tag sollte das "language" Attribut mit einem Wert enthalten, der dem Inhalt des Programmcode-Abschnitts entspricht. Typischerweise enthält es die Werte "css", "html", "ini", "javascript", "php", "text", und "xml". ]]>< ]]>< ]]>< Für Programmcode-Abschnitte, die nur PHP Code enthalten, werden keine PHP-Tags (wie z.B. "<?php", "?>") benötigt, und sollten auch nicht verwendet werden. Sie zeigen nur das Naheliegendste und werden durch die Verwendung des <programlisting> Tags impliziert. <]]]]>> < ]]]]>> ]]> Die Zeilenlängen in Programmcode-Abschnitten sollten den Coding Standard Empfehlungen folgen. require_once(), require(), include_once() und include() sollten innerhalb von PHP-Listings nicht verwendet werden. Sie zeigen nur das Naheliegendste, und sind meistens nicht notwendig, wenn ein Autoloader verwendet wird. Sie sollten nur verwendet werden, wenn sie essentiell für das Beispiel sind. Short Tags (z.B., "<?", "<?=") sollten niemals innerhalb von programlisting oder eines Dokuments verwendet werden. Das Tag <classname> muß jedesmal verwendet werden, wenn ein Klassenname durch sich selbst repräsentiert wird; er sollte nicht in Kombination mit einem Methodennamen, Variablennamen, oder einer Konstante verwendet werden, und auch anderer Inhalt ist nicht innerhalb des Tags erlaubt. Die Klasse Zend_Class. ]]> Variablen müssen im <varname> Tag eingeschlossen sein. Variablen müssen mit Verwendung des "$" Siegels geschrieben werden. Kein anderer Inhalt ist innerhalb des Tags erlaubt, ausser es wird ein Klassenname verwendet, der eine Klassenvariable anzeigt. Die Variable $var und die Klassenvariable Zend_Class::$var. ]]> Methoden müssen innerhalb des <methodname> Tags stehen. Methoden müssen entweder die komplette Methoden Signatur enthalten, oder zumindest ein Paar schließender Klammern (z.B., "()"). Kein anderer Inhalt ist innerhalb dieses Tags erlaubt, ausser es wird ein Klassenname verwendet, der eine Klassenmethode anzeigt. Die Methode foo() und die Klassenmethode Zend_Class::foo(). Eine Methode mit der kompletten Signatur foo($bar, $baz) ]]> Das <constant> Tag ist zu verwenden wenn Konstanten angezeigt werden sollen. Konstanten müssen GROßGESCHRIEBEN werden. Kein anderer Inhalt ist innerhalb dieses Tags erlaubt, ausser es wird ein Klassenname verwendet, der eine Klassenkonstante anzeigt. Die Konstante FOO und die Klassenkonstante Zend_Class::FOO. ]]> Dateinamen und Pfade müssen im <filename> Tag enthalten sein. Kein anderer Inhalt ist innerhalb dieses Tags erlaubt. Die Datei application/Bootstrap.php. ]]> Commands, Shell Skripte, und Programmaufrufe müssen im <command> Tag enthalten sein. Wenn das Kommando Argumente enthält sollten diese auch im Tag enthalten sein. Ausführen von zf.sh create project. ]]> Die Verwendung des <code> Tags ist nicht erlaubt. Stattdessen sollten die anderen vorher besprochenen Inline Tags verwendet werden. Das <title> Tag darf keine anderen Tags enthalten. ]]> Für die Bearbeitung der Dokumentation sollten typischerweise keine formalen XML-Editoren verwendet werden. Solche Editoren formatieren bestehende Dokumente normalerweise so, dass diese ihren eigenen Standards folgen und folgen dem Docbook Standard nicht strikt. Als Beispiel haben wir gesehen das sie die CDATA Tags entfernen, die Trennung von 4 Leerzeichen zu Tabs oder 2 Leerzeichen ändern, usw. Die Styling Richtlinien wurde großteils geschrieben, um Übersetzern zu helfen, damit diese durch Verwendung von normalen diff-Tools erkennen, welche Zeilen sich geändert haben. Die automatische Formatierung macht diesen Prozess viel schwieriger. Gute Bilder und Diagramme können die Lesbarkeit und das Verständnis erhöhen. Sie sollten immer dann verwendet werden, wenn sie diesen Zielen helfen. Bilder sollten im Verzeichnis documentation/manual/en/figures/ platziert, und nach dem Kapitel benannt werden, in dem sie vorkommen. Man sollte nach guten Fallbeispielen suchen, die von der Community verbreitet werden. Speziell jene, die in den Kommentaren der Proposals oder einer der Mailing Listen gesendet werden. Beispiel zeigen oft viel besser die Verwendung, als es Beschreibungen tun. Wenn man Beispiele für die Aufnahme in das Handbuch schreibt, sollte man allen Coding Standards und Dokumentations Standards folgen. Das Handbuch ist dazu gedacht, ein Referenzhandbuch für die Verwendung durch Endbenutzer zu sein. Die Wiederholung von phpdoc Dokumentation für intern verwendete Komponenten und Klassen ist nicht erwünscht, und die Beschreibungen sollten auf die Verwendung fokussiert sein, und nicht der internen Arbeitsweise. In jedem Fall und zu jeder Zeit wollen wir, dass sich die Dokumentations-Teams auf die Übersetzung des englischen Handbuchs und nicht auf ide phpdoc Kommentare fokussiert. Links sollten zu anderen Abschnitten des Handbuchs oder externen Quellen verweisen, statt Dokumentation zu wiederholen. Die Verlinkung zu anderen Abschnitten des Handbuchs kann durchgeführt werden, indem das <link> Tag verwendet wird (für welches man den Link Text selbst angeben muß). "Link" verweist zu einer Sektion, und verwendet beschreibenden Text: Dokumentation zum Link. ]]> Um auf eine externe Ressource zu verweisen, muss <ulink> verwendet werden: Die Zend Framework Seite. ]]>