  DLHP Autor HOWTO
  Marco Budde (Budde@tu-harburg.de)
  v1.0, 25. Mai 1998

  Diese HOWTO richtet sich an Autoren und bersetzer der deutschen Linux
  HOWTOs.

  1.  Einleitung

  1.1.  Ziel dieser HOWTO

  Diese HOWTO sollte jeder lesen, der eine deutsche Linux HOWTO
  schreiben oder eine englische ins Deutsche bersetzen mchte.  Es wird
  beschrieben, wie eine HOWTO genau formatiert werden sollte. Dieses ist
  wichtig, damit alle deutschen HOWTOs hnlich aussehen und den gleichen
  Qualittsansprchen gengen.

  Falls Sie der Meinung sind, da man einige der hier beschriebenen
  Sachen besser machen knnte, zgern Sie bitte nicht und schicken Sie
  mir ein EMail.

  1.2.  Copyright

  Dieses Dokument ist urheberrechtlich geschtzt. Das Copyright liegt
  bei Marco Budde.

  Das Dokument darf gem der GNU General Public License verbreitet
  werden.  Insbesondere bedeutet dieses, da der Text sowohl ber
  elektronische wie auch physikalische Medien ohne die Zahlung von
  Lizenzgebhren verbreitet werden darf, solange dieser Copyright
  Hinweis nicht entfernt wird. Eine kommerzielle Verbreitung ist erlaubt
  und ausdrcklich erwnscht. Bei einer Publikation in Papierform ist
  das Deutsche Linux HOWTO Projekt hierber zu informieren.

  2.  Grundlagen

  2.1.  Wie kann ich mich am DLHP beteiligen?

  Wenn Sie selbst eine HOWTO bersetzen oder eine eigene schreiben
  mchten, erreichen Sie den Koordinator des DLHP unter:

  Internet: Budde@tu-harburg.de
  Fido: Marco Budde@2:240/5202.15

  Um sicherzustellen, da nicht eine HOWTO von mehreren Leuten
  bearbeitet wird, mssen Sie dem Koordinator unbedingt zuerst
  mitteilen, welche HOWTO Sie bearbeiten wollen, bevor Sie anfangen.

  Wenn Sie eine englische HOWTO bersetzen mchten, knnen Sie sich
  selbst eine aussuchen, die Sie bearbeiten mchten. Gehen Sie dabei
  folgendermassen vor:

  1. Suchen Sie sich eine interessante HOWTO von
     sunsite.unc.edu:/pub/Linux/docs/howto aus.

  2. Schauen Sie in DE-HOWTO nach, ob diese HOWTO nicht bereits
     bersetzt wurde oder sich gerade in Arbeit befindet.

  3. Teilen Sie dem Koordinator die ausgesuchte HOWTO mit.

  Nach einiger Zeit sollte Ihre HOWTO dann auch in DE-HOWTO auftauchen.
  Falls dieses nicht der Fall ist, der Koordinator kann ja auch mal was
  vergessen :), weisen Sie den Koordinator unbedingt darauf hin.

  2.2.  Was tun nach der bersetzung?

  Fertige HOWTOs schicken Sie dem Koordinator bitte per EMail an seine
  EMail Adresse. Schicken Sie bitte nur den SGML Source, den sie vorher
  mit gzip komprimiert haben, im uuencode oder MIME base64 Format.

  Bedenken Sie bitte, da auch die Zeit des Koordinators begrenzt ist
  und er nicht die Zeit hat, bei jeder HOWTO Formatierungs- und SGML-
  Fehler zu beseitigen.

  Testen Sie also unbedingt vorher, ob sich Ihr Source in alle
  verwendeten Format ohne Fehler bersetzen lt und ob die Formatierung
  der hier beschriebenen entspricht.

  2.3.  sgml-tools

  Zur Formatierung der HOWTOs wird das Programmpaket sgml-tools
  verwendet. Dieses Paket erlaubt es, mittels einer SGML Quelldatei die
  Formate HTML, ASCII, LaTeX (DVI), Postscript und Adobe Acrobat (PDF)
  zu erzeugen.

  Die Verwendung der sgml-tools bietet sich an, da man so leicht
  verschiedene Formate erzeugen kann und alle HOWTOs dadurch hnlich
  aussehen.

  Eine speziell fr das DLHP modifizierte Version kann von

       http://www.tu-harburg.de/~semb2204/dlhp/dlhp-1.3.tgz

  bezogen werden.

  2.4.  Vorlagen

  Fr die bersetzung einer HOWTO empfiehlt es sich, den SGML Source der
  entsprechenden HOWTO von

       sunsite.unc.edu:/pub/Linux/docs/howto/other-format/sgml

  zu beziehen und als Grundlage fr die bersetzung zu verwenden.

  Hierbei sollte man jedoch unbedingt beachten, da die LDP HOWTOs auf
  einer anderen Formatierungsrichtlinie beruhen. Man kann also nicht
  einfach die bestehende Formatierung bernehmen, sondern mu diese
  eventuell an die in diesem Dokument beschriebene anpassen.

  2.5.  Copyright bei bersetzung

  Wenn Sie eine englische HOWTO bersetzen, berprfen Sie bitte das
  Copyright der englischen HOWTO. Die HOWTOs des DLHP sollen mglichst
  alle der GNU General Public License unterliegen.

  Falls das beim Original nicht der Fall sein sollte, fragen Sie bitte
  beim Autor nach, ob wir die deutsche Version unter der GPL verbreiten
  knnen.

  2.6.  SGML Header

  Jedes SGML Dokument beginnt mit einem Header wie dem folgendem:

       <!doctype linuxdoc system>

       <article>

       <title>Linux foo HOWTO
       <author>Name1 (<tt>name1@foo.org</tt>) und
               Name2 (<tt>name2@foo.org</tt>)
       <date>v1.0, 1. April 1998
       <abstract>
       kurze Inhaltsangabe, hoechstens drei Zeilen
       </abstract>

       <toc>

       [ ... ]

       </article>

  Als Autor sollte der Autor der englischen HOWTO (Name1) und der
  bersetzer (Name2) angegeben werden. Unter <date> wird die
  Versionsnummer gefolgt vom Datum angegeben. Falls es sich um eine
  reine bersetzung handelt, kann die Versionsnummer des Originals
  verwendet werden. Als Datum wird nicht das Datum des Originals
  verwendet, sondern das der Erstellung der bersetzung.

  2.7.  Umlaute

  Die Umlaute sollen in den formatierten Dokumenten in der Form "" und
  nicht in der Form "ue" erscheinen. Die sgml-tools bieten zwei
  Mglichkeiten, die Umlaute einzugeben:

    Latin-1 Zeichensatz (8 Bit): 

    HTML Form (7 Bit): &uuml;

  Wenn mglich, sollte die erste Mglichkeit gewhlt werden.

  3.  Formatierung

  3.1.  FTP Adressen

  Eine FTP Adresse soll im Dokument immer in der Form

       sunsite.unc.edu:/pub

  auftauchen. Die Form

       ftp://sunsite.unc.edu/pub

  findet keine Verwendung.

  Meistens soll die FTP Adresse im HTML Dokument auch anklickbar sein.
  Im SGML Source wrde man also folgendes verwenden:

       <tscreen><htmlurl url="ftp://sunsite.unc.edu/pub"
                         name="sunsite.unc.edu:/pub"></tscreen>

  Das <tscreen> sorgt dafr, da die Zeile in Typewriter Schrift und in
  einer seperaten Zeile dargestellt wird.  Dieses ist sinnvoll, da es
  ansonsten zu Umbruchproblemen in der LaTeX Version kommen kann. Falls
  es sich um eine sehr kurze Adresse handelt, kann statt dessen auch
  <tt> benutzt werden.

  3.2.  HTTP Adressen

  HTTP Adressen sehen fast genauso wie die FTP Adressen aus. Auch hier
  findet meistens <tscreen> statt <tt> Verwendung:

  <tscreen><htmlurl url="http://www.foo.de/foo/"
            name="http://www.foo.de/foo/"></tscreen>

  Falls Sie wie in diesem Beispiel nur das Verzeichnis und nicht auch
  den Dateinamen (z.B. index.html) angeben, achten Sie bitte darauf, da
  das letzte Zeichen ein Slash ist. Hierdurch wird unntiger HTTP
  Verkehr vermieden.

  3.3.  Mailadressen

  Eine EMail Adresse wird meistens in folgender Form gesetzt:

       Thomas Mustermann (<tt><htmlurl url="mailto:tm@entenhausen.de"
                          name="tm@entenhausen.de"></tt>)

  3.4.  Dokumente

  Falls Sie im Text auf andere Dokumente verweisen, schlieen Sie den
  Titel bitte in <em> ein.

  Verweise auf andere HOWTOs sollten auf jeden Fall anklickbar sein.
  Falls es sich bei der anderen HOWTO um eine HOWTO handelt, die bereits
  als deutsche bersetzung existiert, wird ein relativer Link benutzt.
  Ein Link auf die PPP HOWTO wrde also z.B.  so aussehen:

       <em><htmlurl url="DE-PPP-HOWTO.html" name="PPP HOWTO"></em>

  Beachten Sie bitte, da PPP HOWTO ohne Bindestrich geschrieben wird!

  Falls der Link auf eine englische HOWTO gehen soll, benutzt man einen
  Link auf die sunsite:

       <em><htmlurl url="http://sunsite.unc.edu/LDP/HOWTO/PPP-HOWTO.html"
                    name="PPP HOWTO"></em>

  3.5.  Listings, Kommandozeile

  Listings und Beispiele fr die Eingabe werden mit <tscreen><verb>
  formatiert. Die <code> Umgebung wird nicht benutzt.

  Bei Listings sollten unbedingt auch die Kommentare im Listing ins
  Deutsche bersetzt werden. Gehen Sie immer davon aus, da der Leser
  kein Wort Englisch versteht :).

  Da die sgml-tools Probleme mit Umlauten in der obigen Umgebung haben,
  mu auf diese hier verzichtet werden. Achten Sie unbedingt auf die
  Zeilenlnge. Mehr als 60-70 Zeichen sollte eine Zeile auf keinen Fall
  enthalten. Sonst gibt es in der ASCII und der Druckversion Probleme.

