Extended coverage of German localization of help files.

git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@9230 71c3de6d-444a-0410-be80-ed276b4c234a

Extended coverage of German localization of help files.
git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@9230 71c3de6d-444a-0410-be80-ed276b4c234a
019fa64f · swiest · 2aa5c9a8 · 019fa64f · 019fa64f · 019fa64f
14 changed file
--- a/war/resources/env-vars_de.html
+++ b/war/resources/env-vars_de.html
@@ -7,7 +7,7 @@
        dt { font-weight: bold; }
    </style>
 <body>
-    Die folgenden Variablen sind innerhalb von Shell-Skripten sichtbar
+    Die folgenden Variablen sind innerhalb von Shell-Skripten sichtbar:

 <dl>
    <dt>BUILD_NUMBER</dt>

--- a/war/resources/help/_cvs/branch_de.html
+++ b/war/resources/help/_cvs/branch_de.html
+<div>
+  Wenn gesetzt, führt Hudson CVS mit der Option <tt>-r</tt> aus, um einen
+  bestimmten Zweig (branch) zu bauen. Wenn leer, wird Hudson die Hauptlinie (trunk)
+  bauen.
+  <p>
+  Im Regelfall startet Hudson CVS check-out und update mit der Option <tt>-D date</tt>,
+  um kohärente Schnappschüsse des Repositories und damit reproduzierbare Builds sicherzustellen.
+  Dies kann allerdings problematisch werden, falls der hier angegebene Name des Zweigs
+  der Name eines Tags ist. Hudson mitzuteilen, dass es sich um einen Tag-Namen handelt,
+  würde das Problem lösen.
+</div>
\ No newline at end of file
--- a/war/resources/help/_cvs/cvs-rsh_de.html
+++ b/war/resources/help/_cvs/cvs-rsh_de.html
+<div>
+  Wenn gesetzt, startet Hudson CVS mit der <a href="http://www.google.com/search?q=CVS_RSH">
+  Umgebungsvariable <tt>CVS_RSH</tt></a> - gesetzt auf den angegebenen Wert.
+  Ist das Feld leer und der Web-Container, in dem Hudson läuft, hat in seiner
+  Umgebung <tt>CVS_RSH</tt> gesetzt, so wird CVS dies erben.
+</div>
\ No newline at end of file
--- a/war/resources/help/_cvs/cvsexe_de.html
+++ b/war/resources/help/_cvs/cvsexe_de.html
+<div>
+  Im Regelfall sollten Sie dieses Feld leerlassen und Hudson die richtige CVS-Installation
+  wählen lassen. Falls Ihre <tt>cvs</tt> Kommandozeilenanwendung nicht über die <tt>PATH</tt>
+  Umgebungsvariable gefunden werden kann, geben Sie den absoluten Pfad zur <tt>cvs</tt>
+  Kommandozeilenanwendung an. Wenn Sie nur "cvs" angeben, wird Hudson cvs über die <tt>PATH</tt>
+  Variable finden.
+</div>
\ No newline at end of file
--- a/war/resources/help/_cvs/cvsroot_de.html
+++ b/war/resources/help/_cvs/cvsroot_de.html
+<div>
+  Geben Sie hier den CVS-Verbindungsparameter an, mit dem sich Hudson mit dem CVS-Server
+  verbindet. Das Format ist identisch mit dem der Umgebungsvariable <tt>$CVSROOT</tt>
+  (<tt>:protocol:user@host:path</tt>).
+</div>
\ No newline at end of file
--- a/war/resources/help/_cvs/legacy_de.html
+++ b/war/resources/help/_cvs/legacy_de.html
+<div>
+  Hudson 1.20 und früher legten redundante Verzeichnisse innerhalb des Arbeitsbereiches
+  an. War der CVS-Modulname beispielsweise "foo/bar", so legte Hudson erst ein
+  Verzeichnis "foo/bar" an und legte dann alles unterhalb dieses Verzeichnisses ab.
+  If diese Option nicht angewählt, werden keine solchen unnötigen Zwischenverzeichnisse
+  mehr erzeugt.  
+  <p>
+  Dies wirkt sich auf weitere Pfadangaben aus, etwa zur Archivierung von Artefakten:
+  Sie geben dann "build/foo.jar" statt "foo/build/foo.jar" an.
+</div>
\ No newline at end of file
--- a/war/resources/help/_cvs/modules_de.html
+++ b/war/resources/help/_cvs/modules_de.html
+<div>
+  CVS-Modulnamen im angegebenen <tt>CVSROOT</tt>, die ausgecheckt werden sollen.
+  Mehrere Modulnamen können - durch Leerzeichen getrennt - angegeben werden.
+
+  Wenn Ihr Modulname ein Leerzeichen enthält, stellen Sie dem Leezeichen ein
+  '\' voran. Beispiel: Die Eingabe "foo\ bar zot" spezifiziert die zwei Module
+  "foo bar" und "zot".
+</div>
\ No newline at end of file
--- a/war/resources/help/_cvs/tagAll_de.html
+++ b/war/resources/help/_cvs/tagAll_de.html
+<div>
+  Statt nur diesen Build zu kennzeichnnen ("taggen"), werden alle Builds der
+  vorgelagerten  Projekte gekennzeichnet, auf denen dieser Build basiert.
+  Dies erlaubt Ihnen, die exakten Version aller Builds festzuhalten, die zu
+  diesem Build beigetragen haben.
+</div>
\ No newline at end of file
--- a/war/resources/help/_cvs/update_de.html
+++ b/war/resources/help/_cvs/update_de.html
+<div>
+  Ist diese Option angewählt, so verwendet Hudson wann immer möglich 'cvs update'
+  während eines Builds. Dies bewirkt außerdem, dass Artefakte von vorhergehenden
+  Builds im Dateisystem verbleiben und nachfolgende Builds daher nicht vollständig
+  von Grund auf neu gebaut werden.
+</div>
\ No newline at end of file
--- a/war/resources/help/matrix/axes_de.html
+++ b/war/resources/help/matrix/axes_de.html
+<div>
+  Hier können Sie die Achsen Ihrer Konfigurationsmatrix angeben.
+  <p>
+  Beispiel: Sie haben eine Datenbankanwendung geschrieben und möchten diese mit
+  den drei Datenbanksystemen MySQL, PostgresSQL und Oracle  testen. Ihr Build-Skript
+  ist so gestaltet, dass Sie ein bestimmtes Datenbanksystem testen können, indem 
+  Sie Ant etwa folgendermaßen aufrufen: <tt>ant -Ddatabase=mysql</tt>.
+  <p>
+  Dies ist das Konzept einer "Achse". Sie definieren dazu eine Variable namens "database",
+  welche unterschiedliche Werte annehmen kann. Wenn Sie für diese Variable 3 Werte
+  konfigurieren, wird Hudson 3 Unter-Builds ausführen - jeder mit einem anderen Wert
+  für die Variable "database", um die Konfigurationsmatrix erschöpfend abzudecken.
+  <p>
+  Variablen, die hier als Achse spezifiziert werden, stehen dem Build als Umgebungsvariablen
+  zur Verfügung. Für Ant und Maven sind die Variablen zusätzlich auch als Eigenschaften
+  (properties) sichtbar - genau so, als ob <tt>-D<i>variableName</i>=<i>value</i></tt> 
+  in der Kommandozeile angegeben worden wäre.
+  <p>
+  Sind mehrere Achsen eingerichtet, so werden alle möglichen Kombinationen
+  erschöpfend in Unter-Builds ausgeführt. Mehrfache Auswahlen in Labels und JDKs
+  werden auf dieselbe Weise behandelt. Geben Sie beispielsweise
+  <tt>jdk=[JDK5,JDK6], database=[mysql,postgresql,oracle], container=[jetty,tomcat]</tt>
+  an, so besteht ein Build aus 2x3x2=12 unterschiedlichen Unter-Builds.
+</div>
\ No newline at end of file
--- a/war/resources/help/matrix/axis-value_de.html
+++ b/war/resources/help/matrix/axis-value_de.html
+<div>
+  Geben Sie hier die Werte an, welche die Variable annehmen kann. Mehrere Werte werden durch Leerraum oder Zeilenumbrüche getrennt.
+</div>
\ No newline at end of file
--- a/war/resources/help/matrix/jdk_de.html
+++ b/war/resources/help/matrix/jdk_de.html
+<div>
+  Geben Sie die JDK(s) an, mit denen die Unter-Builds durchgeführt werden sollen.
+  Wenn kein JDK ausgewählt ist, wird das Default-JDK verwendet (kein explizites
+  Setzen der Umgebungsvariable <tt>JAVA_HOME</tt>; es wird erwartet, dass die 
+  Kommandozeilenanwendung <tt>java</tt> im Suchpfad <tt>PATH</tt> enthalten ist).
+  Wenn mehrere JDKs ausgewählt sind, deckt die Konfigurationsmatrix alle diese
+  JDKs ab.
+  <p>
+  Eine Mehrfachauswahl ist typischerweise dann nützlich, wenn dieser Job Tests
+  beinhaltet und Sie diese Tests mit unterschiedlichen JDKs ausführen möchten.
+  <p>
+  Während eines Builds ist das aktuelle JDK als Achse <tt>jdk</tt> sichtbar.
+  Im Hilfetext zu "Achsen" finden Sie weitere Informationen, wie Sie auf die
+  Werte der Achsenvariablen zugreifen können.
+</div>
\ No newline at end of file
--- a/war/resources/help/matrix/label_de.html
+++ b/war/resources/help/matrix/label_de.html
+<div>
+  Geben Sie die Knoten an, auf denen Ihre Builds ausgeführt werden sollen.
+  <ul>
+    <li>
+      Ist kein Knoten ausgewählt, wird Hudson einen verfügbaren Knoten auswählen,
+      um den Build durchzuführen (dies ist das gleiche Verhalten wie beim 
+      "Free-Style-Projekt", wenn "Projekt an Knoten binden" abgewählt ist).
+      Dies ist sinnvoll, wenn das Projekt keine Abhängigkeiten zu einem bestimmten
+      Knoten aufweist, da es Hudson erlaubt, die Knoten optimal einzusetzen.
+    <li>
+      Ist ein Knoten ausgewählt, wird Hudson den Build immer auf dem gewählten Knoten
+      (wenn ein Knoten unter "Bestimmte Knoten" ausgewählt wurde) oder auf einem Knoten,
+      der zum gewählten Label gehört (wenn ein Knoten unter "Labels" ausgewählt wurde), ausführen.
+      Dies ist sinnvoll, wenn der Build auf einem bestimmten Rechner oder 
+      Rechnergruppe ausgeführt werden soll. Beispielsweise könnte der Build ein
+      bestimmtes Betriebssystem wie MacOS X voraussetzen.
+    <li>
+      Sind mehrere Knoten ausgewählt, wird die Konfigurationsmatrix so erweitert,
+      dass sie alle Werte beinhaltet. Builds werden dann auf allen gewählten Knoten/Labels
+      ausgeführt.
+      Dies ist sinnvoll, wenn Sie beispielsweise Tests unter Windows, Linux und
+      Solaris ausführen möchten.
+  </ul>
+
+  <br>
+  Während eines Builds ist der aktuelle Name des Knotens bzw. des Labels als Achse
+  <tt>label</tt> sichtbar.
+  Im Hilfetext zu "Achsen" finden Sie weitere Informationen, wie Sie auf die
+  Werte der Achsenvariablen zugreifen können.
+</div>
\ No newline at end of file
--- a/war/resources/help/system-config/master-slave/usage_de.html
+++ b/war/resources/help/system-config/master-slave/usage_de.html
@@ -3,7 +3,7 @@

  <dl>
    <dt><b>
-      Verwende diesen Slave-Knoten zu viel wie möglich
+      Verwende diesen Slave-Knoten so viel wie möglich
    </b></dt>
    <dd>
      Dies ist die Vorgabe- und Normaleinstellung.