nls: Update 'de' translation of the manual.

1 files changed, 402 insertions, 355 deletions

diff --git a/doc/contributing.de.texi b/doc/contributing.de.texi
index 259523aa6f..6a999baece 100644
--- a/doc/contributing.de.texi
+++ b/doc/contributing.de.texi
@@ -6,7 +6,7 @@ es wachsen zu lassen! Bitte kontaktieren Sie uns auf
 @email{guix-devel@@gnu.org} und @code{#guix} im Freenode-IRC-Netzwerk. Wir
 freuen uns auf Ihre Ideen, Fehlerberichte, Patches und alles, was hilfreich
 für das Projekt sein könnte. Besonders willkommen ist Hilfe bei der
-Erstellung von Paketen (@pxref{Paketrichtlinien}).
+Erstellung von Paketen (siehe @ref{Paketrichtlinien}).
 
 @cindex Verhaltensregeln, für Mitwirkende
 @cindex Verhaltenskodex für Mitwirkende
@@ -43,8 +43,8 @@ git clone https://git.savannah.gnu.org/git/guix.git
 @end example
 
 Wenn Sie Guix aus einem Checkout erstellen, sind außer den bereits in den
-Installationsanweisungen genannten Paketen weitere nötig
-(@pxref{Voraussetzungen}).
+Installationsanweisungen genannten Paketen weitere nötig (siehe
+@ref{Voraussetzungen}).
 
 @itemize
 @item @url{http://gnu.org/software/autoconf/, GNU Autoconf};
@@ -64,7 +64,7 @@ an Guix zu arbeiten:
 guix environment guix
 @end example
 
-In @xref{Aufruf von guix environment} finden Sie weitere Informationen zu
+In @ref{Aufruf von guix environment} finden Sie weitere Informationen zu
 diesem Befehl. Zusätzliche Abhängigkeiten können mit @option{--ad-hoc}
 hinzugefügt werden:
 
@@ -73,7 +73,7 @@ guix environment guix --ad-hoc help2man git strace
 @end example
 
 Führen Sie @command{./bootstrap} aus, um die Infrastruktur des
-Erstellungssystems mit Autoconf und Automake zu erstellen. Möglicherweise
+Erstellungssystems mit Autoconf und Automake zu erzeugen. Möglicherweise
 erhalten Sie eine Fehlermeldung wie diese:
 
 @example
@@ -93,18 +93,18 @@ Befehl aufrufen:
 export ACLOCAL_PATH=/usr/share/aclocal
 @end example
 
-In @xref{Macro Search Path,,, automake, The GNU Automake Manual} finden Sie
+In @ref{Macro Search Path,,, automake, The GNU Automake Manual} finden Sie
 weitere Informationen.
 
 Dann führen Sie wie gewohnt @command{./configure} aus. Achten Sie darauf,
 @code{--localstatedir=@var{Verzeichnis}} zu übergeben, wobei
 @var{Verzeichnis} der von Ihrer aktuellen Installation verwendete
-@code{localstatedir}-Wert ist (weitere Informationen auf @pxref{Der Store}).
+@code{localstatedir}-Wert ist (weitere Informationen siehe @ref{Der Store}).
 
 Zum Schluss müssen Sie @code{make check} aufrufen, um die Tests auszuführen
-(@pxref{Die Testsuite laufen lassen}). Falls etwas fehlschlägt, werfen Sie einen
-Blick auf die Installationsanweisungen (@pxref{Installation}) oder senden
-Sie eine E-Mail an die @email{guix-devel@@gnu.org, Mailingliste}.
+(siehe @ref{Den Testkatalog laufen lassen}). Falls etwas fehlschlägt, werfen Sie
+einen Blick auf die Installationsanweisungen (siehe @ref{Installation}) oder
+senden Sie eine E-Mail an die @email{guix-devel@@gnu.org, Mailingliste}.
 
 
 @node Guix vor der Installation ausführen
@@ -118,7 +118,7 @@ Endnutzer-»Straßenanzug« und Ihrem »Faschingskostüm« unterscheiden.
 Zu diesem Zweck können alle Befehlszeilenwerkzeuge auch schon benutzt
 werden, ohne dass Sie @code{make install} laufen lassen.  Dazu müssen Sie
 sich in einer Umgebung befinden, in der alle Abhängigkeiten von Guix
-verfügbar sind (@pxref{Erstellung aus dem Git}) und darin einfach vor jeden
+verfügbar sind (siehe @ref{Erstellung aus dem Git}) und darin einfach vor jeden
 Befehl @command{./pre-inst-env} schreiben (das Skript @file{pre-inst-env}
 befindet sich auf oberster Ebene im Verzeichnis, wo Guix erstellt wird, wo
 es durch @command{./configure} erzeugt wird), zum Beispiel so@footnote{Die
@@ -144,8 +144,8 @@ $ ./pre-inst-env guile -c '(use-modules (guix utils)) (pk (%current-system))'
 @noindent
 @cindex REPL
 @cindex Lese-Auswerten-Schreiben-Schleife
-@dots{} und auf einer REPL (@pxref{Using Guile Interactively,,, guile, Guile
-Reference Manual}):
+@dots{} und auf einer REPL (siehe @ref{Using Guile Interactively,,, guile,
+Guile Reference Manual}):
 
 @example
 $ ./pre-inst-env guile
@@ -169,19 +169,20 @@ nötig sind, um dies zu ermöglichen, einschließlich @env{PATH} und
 
 Beachten Sie, dass @command{./pre-inst-env guix pull} den lokalen Quellbaum
 @emph{nicht} aktualisiert; es aktualisiert lediglich die symbolische
-Verknüpfung @file{~/.config/guix/current} (@pxref{Aufruf von guix pull}).  Um
-Ihren lokalen Quellbaum zu aktualisieren, müssen Sie stattdessen
+Verknüpfung @file{~/.config/guix/current} (siehe @ref{Aufruf von guix pull}). Um Ihren lokalen Quellbaum zu aktualisieren, müssen Sie stattdessen
 @command{git pull} benutzen.
 
 
 @node Perfekt eingerichtet
 @section Perfekt eingerichtet
 
-The Perfect Setup to hack on Guix is basically the perfect setup used for
-Guile hacking (@pxref{Using Guile in Emacs,,, guile, Guile Reference
-Manual}).  First, you need more than an editor, you need
-@url{http://www.gnu.org/software/emacs, Emacs}, empowered by the wonderful
-@url{http://nongnu.org/geiser/, Geiser}.  To set that up, run:
+Um perfekt für das Hacken an Guix eingerichtet zu sein, brauchen Sie an sich
+dasselbe wie um perfekt für das Hacken mit Guile (siehe @ref{Using Guile in
+Emacs,,, guile, Guile Reference Manual}). Zunächst brauchen Sie mehr als ein
+Textverarbeitungsprogramm, Sie brauchen
+@url{http://www.gnu.org/software/emacs, Emacs} zusammen mit den vom
+wunderbaren @url{http://nongnu.org/geiser/, Geiser} verliehenen Kräften. Um
+diese zu installieren, können Sie Folgendes ausführen:
 
 @example
 guix package -i emacs guile emacs-geiser
@@ -191,8 +192,8 @@ Geiser ermöglicht interaktive und inkrementelle Entwicklung aus Emacs
 heraus: Code kann in Puffern kompiliert und ausgewertet werden. Zugang zu
 Online-Dokumentation (Docstrings) steht ebenso zur Verfügung wie
 kontextabhängige Vervollständigung, @kbd{M-.} um zu einer Objektdefinition
-zu springen, eine REPL, um Ihren Code auszuprobieren, und mehr
-(@pxref{Einführung,,, geiser, Geiser User Manual}). Zur bequemen
+zu springen, eine REPL, um Ihren Code auszuprobieren, und mehr (siehe
+@ref{Einführung,,, geiser, Geiser User Manual}). Zur bequemen
 Guix-Entwicklung sollten Sie Guiles Ladepfad so ergänzen, dass die
 Quelldateien in Ihrem Checkout gefunden werden.
 
@@ -245,63 +246,69 @@ wieder weiter umgeschrieben werden kann.
 @node Paketrichtlinien
 @section Paketrichtlinien
 
-@cindex packages, creating
-The GNU distribution is nascent and may well lack some of your favorite
-packages.  This section describes how you can help make the distribution
-grow.
-
-Free software packages are usually distributed in the form of @dfn{source
-code tarballs}---typically @file{tar.gz} files that contain all the source
-files.  Adding a package to the distribution means essentially two things:
-adding a @dfn{recipe} that describes how to build the package, including a
-list of other packages required to build it, and adding @dfn{package
-metadata} along with that recipe, such as a description and licensing
-information.
-
-In Guix all this information is embodied in @dfn{package definitions}.
-Package definitions provide a high-level view of the package.  They are
-written using the syntax of the Scheme programming language; in fact, for
-each package we define a variable bound to the package definition, and
-export that variable from a module (@pxref{Paketmodule}).  However,
-in-depth Scheme knowledge is @emph{not} a prerequisite for creating
-packages.  For more information on package definitions, @pxref{Pakete definieren}.
-
-Once a package definition is in place, stored in a file in the Guix source
-tree, it can be tested using the @command{guix build} command
-(@pxref{Aufruf von guix build}).  For example, assuming the new package is
-called @code{gnew}, you may run this command from the Guix build tree
-(@pxref{Guix vor der Installation ausführen}):
+@cindex Pakete definieren
+Die GNU-Distribution ist noch sehr jung und einige Ihrer Lieblingspakete
+könnten noch fehlen. Dieser Abschnitt beschreibt, wie Sie dabei helfen
+können, die Distribution wachsen zu lassen.
+
+Pakete mit freier Software werden normalerweise in Form von @dfn{Tarballs
+mit dem Quellcode} angeboten — typischerweise in
+@file{tar.gz}-Archivdateien, in denen alle Quelldateien enthalten sind. Ein
+Paket zur Distribution hinzuzufügen, bedeutet also zweierlei Dinge: Zum
+einen fügt man ein @dfn{Rezept} ein, das beschreibt, wie das Paket erstellt
+werden kann, einschließlich einer Liste von anderen Paketen, die für diese
+Erstellung gebraucht werden, zum anderen fügt man @dfn{Paketmetadaten} zum
+Rezept hinzu, wie zum Beispiel eine Beschreibung und Lizenzinformationen.
+
+In Guix sind all diese Informationen ein Teil der
+@dfn{Paketdefinitionen}. In Paketdefinitionen hat man eine abstrahierte,
+hochsprachliche Sicht auf das Paket. Sie werden in der Syntax der
+Scheme-Programmiersprache verfasst; tatsächlich definieren wir für jedes
+Paket eine Variable und binden diese an dessen Definition, um die Variable
+anschließend aus einem Modul heraus zu exportieren (siehe @ref{Paketmodule}). Allerdings ist @emph{kein} tiefgehendes Wissen über Scheme
+erforderlich, um Pakete zu erstellen. Mehr Informationen über
+Paketdefinitionen finden Sie im Abschnitt @ref{Pakete definieren}.
+
+Eine fertige Paketdefinition kann, nachdem sie in eine Datei im
+Quell-Verzeichnisbaum von Guix eingesetzt wurde, mit Hilfe des Befehls
+@command{guix build} getestet werden (siehe @ref{Aufruf von guix build}). Wenn
+das Paket zum Beispiel den Namen @code{gnew} trägt, können Sie folgenden
+Befehl aus dem Erstellungs-Verzeichnisbaum von Guix heraus ausführen (siehe
+@ref{Guix vor der Installation ausführen}):
 
 @example
 ./pre-inst-env guix build gnew --keep-failed
 @end example
 
-Using @code{--keep-failed} makes it easier to debug build failures since it
-provides access to the failed build tree.  Another useful command-line
-option when debugging is @code{--log-file}, to access the build log.
+Wenn Sie @code{--keep-failed} benutzen, ist es leichter, fehlgeschlagene
+Erstellungen zu untersuchen, weil dann der Verzeichnisbaum der
+fehlgeschlagenen Erstellung zugänglich bleibt. Eine andere nützliche
+Befehlszeilenoption bei der Fehlersuche ist @code{--log-file}, womit das
+Erstellungsprotokoll eingesehen werden kann.
 
-If the package is unknown to the @command{guix} command, it may be that the
-source file contains a syntax error, or lacks a @code{define-public} clause
-to export the package variable.  To figure it out, you may load the module
-from Guile to get more information about the actual error:
+Wenn der @command{guix}-Befehl das Paket nicht erkennt, kann es daran
+liegen, dass die Quelldatei einen Syntaxfehler hat oder ihr eine
+@code{define-public}-Klausel fehlt, die die Paketvariable exportiert. Um das
+herauszufinden, können Sie das Modul aus Guile heraus laden, um mehr
+Informationen über den tatsächlichen Fehler zu bekommen:
 
 @example
 ./pre-inst-env guile -c '(use-modules (gnu packages gnew))'
 @end example
 
-Once your package builds correctly, please send us a patch
-(@pxref{Einreichen von Patches}).  Well, if you need help, we will be happy to
-help you too.  Once the patch is committed in the Guix repository, the new
-package automatically gets built on the supported platforms by
-@url{http://hydra.gnu.org/jobset/gnu/master, our continuous integration
-system}.
+Sobald Ihr Paket erfolgreich erstellt werden kann, schicken Sie uns bitte
+einen Patch (siehe @ref{Einreichen von Patches}). Wenn Sie dabei Hilfe brauchen
+sollten, helfen wir gerne. Ab dem Zeitpunkt, zu dem der Patch als Commit ins
+Guix-Repository eingepflegt wurde, wird das neue Paket automatisch durch
+@url{http://hydra.gnu.org/jobset/gnu/master, unser System zur
+Kontinuierlichen Integration} auf allen unterstützten Plattformen erstellt.
 
-@cindex substituter
-Users can obtain the new package definition simply by running @command{guix
-pull} (@pxref{Aufruf von guix pull}).  When @code{@value{SUBSTITUTE-SERVER}}
-is done building the package, installing the package automatically downloads
-binaries from there (@pxref{Substitute}).  The only place where human
-intervention is needed is to review and apply the patch.
+@cindex Substituierer
+Benutzern steht die neue Paketdefinition zur Verfügung, nachdem sie das
+nächste Mal @command{guix pull} ausgeführt haben (siehe @ref{Aufruf von guix pull}). Wenn @code{@value{SUBSTITUTE-SERVER}} selbst damit fertig ist, das
+Paket zu erstellen, werden bei der Installation automatisch Binärdateien von
+dort heruntergeladen (siehe @ref{Substitute}). Menschliches Eingreifen muss
+nur stattfinden, um den Patch zu überprüfen und anzuwenden.
 
 
 @menu
@@ -326,67 +333,74 @@ intervention is needed is to review and apply the patch.
 @c
 @c ===========================================================================
 @c Adapted from http://www.gnu.org/philosophy/philosophy.html.
-@cindex free software
-The GNU operating system has been developed so that users can have freedom
-in their computing.  GNU is @dfn{free software}, meaning that users have the
-@url{http://www.gnu.org/philosophy/free-sw.html,four essential freedoms}: to
-run the program, to study and change the program in source code form, to
-redistribute exact copies, and to distribute modified versions.  Packages
-found in the GNU distribution provide only software that conveys these four
-freedoms.
-
-In addition, the GNU distribution follow the
-@url{http://www.gnu.org/distros/free-system-distribution-guidelines.html,free
-software distribution guidelines}.  Among other things, these guidelines
-reject non-free firmware, recommendations of non-free software, and discuss
-ways to deal with trademarks and patents.
-
-Some otherwise free upstream package sources contain a small and optional
-subset that violates the above guidelines, for instance because this subset
-is itself non-free code.  When that happens, the offending items are removed
-with appropriate patches or code snippets in the @code{origin} form of the
-package (@pxref{Pakete definieren}).  This way, @code{guix build --source}
-returns the ``freed'' source rather than the unmodified upstream source.
+@cindex freie Software
+Das GNU-Betriebssystem wurde entwickelt, um Menschen Freiheit bei der
+Nutzung ihrer Rechengeräte zu ermöglichen. GNU ist @dfn{freie Software}, was
+bedeutet, dass Benutzer die
+@url{http://www.gnu.org/philosophy/free-sw.de.html,vier wesentlichen
+Freiheiten} haben: das Programm auszuführen, es zu untersuchen, das Programm
+in Form seines Quellcodes anzupassen und exakte Kopien ebenso wie
+modifizierte Versionen davon an andere weiterzugeben. Die Pakete, die Sie in
+der GNU-Distribution finden, stellen ausschließlich solche Software zur
+Verfügung, die Ihnen diese vier Freiheiten gewährt.
+
+Außerdem befolgt die GNU-Distribution die
+@url{http://www.gnu.org/distros/free-system-distribution-guidelines.de.html,Richtlinien
+für freie Systemverteilungen}. Unter anderem werden unfreie Firmware sowie
+Empfehlungen von unfreier Software abgelehnt und Möglichkeiten zum Umgang
+mit Markenzeichen und Patenten werden diskutiert.
+
+Ansonsten freier Paketquellcode von manchen Anbietern enthält einen kleinen
+und optionalen Teil, der diese Richtlinien verletzt. Zum Beispiel kann
+dieser Teil selbst unfreier Code sein. Wenn das vorkommt, wird der sie
+verletzende Teil mit angemessenen Patches oder Code-Schnipseln innerhalb der
+@code{origin}-Form des Pakets entfernt (siehe @ref{Pakete definieren}). Dadurch liefert Ihnen @code{guix build --source} nur den
+»befreiten« Quellcode und nicht den unmodifizierten Quellcode des Anbieters.
 
 
 @node Paketbenennung
 @subsection Paketbenennung
 
-@cindex package name
-A package has actually two names associated with it: First, there is the
-name of the @emph{Scheme variable}, the one following @code{define-public}.
-By this name, the package can be made known in the Scheme code, for instance
-as input to another package.  Second, there is the string in the @code{name}
-field of a package definition.  This name is used by package management
-commands such as @command{guix package} and @command{guix build}.
+@cindex Paketname
+Tatsächlich sind mit jedem Paket zwei Namen assoziiert: Zum einen gibt es
+den Namen der @emph{Scheme-Variablen}, der direkt nach @code{define-public}
+im Code steht. Mit diesem Namen kann das Paket im Scheme-Code nutzbar
+gemacht und zum Beispiel als Eingabe eines anderen Pakets benannt
+werden. Zum anderen gibt es die Zeichenkette im @code{name}-Feld einer
+Paketdefinition. Dieser Name wird von Paketverwaltungsbefehlen wie
+@command{guix package} und @command{guix build} benutzt.
 
-Both are usually the same and correspond to the lowercase conversion of the
-project name chosen upstream, with underscores replaced with hyphens.  For
-instance, GNUnet is available as @code{gnunet}, and SDL_net as
-@code{sdl-net}.
+Meistens sind die beiden identisch und ergeben sich aus einer Umwandlung des
+vom Anbieter verwendeten Projektnamens in Kleinbuchstaben, bei der
+Unterstriche durch Bindestriche ersetzt werden. Zum Beispiel wird GNUnet
+unter dem Paketnamen @code{gnunet} angeboten und SDL_net als @code{sdl-net}.
 
-We do not add @code{lib} prefixes for library packages, unless these are
-already part of the official project name.  But @pxref{Python-Module} and
-@ref{Perl-Module} for special rules concerning modules for the Python and
-Perl languages.
+An Bibliothekspakete hängen wir vorne kein @code{lib} als Präfix an, solange
+es nicht Teil des offiziellen Projektnamens ist. Beachten Sie aber die
+Abschnitte @ref{Python-Module} und @ref{Perl-Module}, in denen
+Sonderregeln für Module der Programmiersprachen Python und Perl beschrieben
+sind.
 
-Font package names are handled differently, @pxref{Schriftarten}.
+Auch Pakete mit Schriftarten werden anders behandelt, siehe @ref{Schriftarten}.
 
 
 @node Versionsnummern
 @subsection Versionsnummern
 
-@cindex package version
-We usually package only the latest version of a given free software
-project.  But sometimes, for instance for incompatible library versions, two
-(or more) versions of the same package are needed.  These require different
-Scheme variable names.  We use the name as defined in @ref{Paketbenennung}
-for the most recent version; previous versions use the same name, suffixed
-by @code{-} and the smallest prefix of the version number that may
-distinguish the two versions.
-
-The name inside the package definition is the same for all versions of a
-package and does not contain any version number.
+@cindex Paketversion
+Normalerweise stellen wir nur für die neueste Version eines
+Freie-Software-Projekts ein Paket bereit. Manchmal gibt es allerdings Fälle
+wie zum Beispiel untereinander inkompatible Bibliotheksversionen, so dass
+zwei (oder mehr) Versionen desselben Pakets angeboten werden müssen. In
+diesem Fall müssen wir verschiedene Scheme-Variablennamen benutzen. Wir
+benutzen dann für die neueste Version den Namen, wie er im Abschnitt
+@ref{Paketbenennung} festgelegt wird, und geben vorherigen Versionen
+denselben Namen mit einem zusätzlichen Suffix aus @code{-} gefolgt vom
+kürzesten Präfix der Versionsnummer, mit dem noch immer zwei Versionen
+unterschieden werden können.
+
+Der Name innerhalb der Paketdefinition ist hingegen derselbe für alle
+Versionen eines Pakets und enthält keine Versionsnummer.
 
 Zum Beispiel können für GTK in den Versionen 2.24.20 und 3.9.12 Pakete wie
 folgt geschrieben werden:
@@ -414,48 +428,51 @@ Wenn wir auch GTK 3.8.2 wollten, würden wir das Paket schreiben als
 
 @c See <https://lists.gnu.org/archive/html/guix-devel/2016-01/msg00425.html>,
 @c for a discussion of what follows.
-@cindex version number, for VCS snapshots
-Occasionally, we package snapshots of upstream's version control system
-(VCS) instead of formal releases.  This should remain exceptional, because
-it is up to upstream developers to clarify what the stable release is.  Yet,
-it is sometimes necessary.  So, what should we put in the @code{version}
-field?
-
-Clearly, we need to make the commit identifier of the VCS snapshot visible
-in the version string, but we also need to make sure that the version string
-is monotonically increasing so that @command{guix package --upgrade} can
-determine which version is newer.  Since commit identifiers, notably with
-Git, are not monotonically increasing, we add a revision number that we
-increase each time we upgrade to a newer snapshot.  The resulting version
-string looks like this:
+@cindex Versionsnummer, bei Snapshots aus Versionskontrolle
+Gelegentlich fügen wir auch Pakete für Snapshots aus dem
+Versionskontrollsystem des Anbieters statt formaler Veröffentlichungen zur
+Distribution hinzu. Das sollte die Ausnahme bleiben, weil die Entwickler
+selbst klarstellen sollten, welche Version als die stabile Veröffentlichung
+gelten sollte, ab und zu ist es jedoch notwendig. Was also sollten wir dann
+im @code{version}-Feld eintragen?
+
+Offensichtlich muss der Bezeichner des Commits, den wir als Snapshot aus dem
+Versionskontrollsystem nehmen, in der Versionszeichenkette zu erkennen sein,
+aber wir müssen auch sicherstellen, dass die Version monoton steigend ist,
+damit @command{guix package --upgrade} feststellen kann, welche Version die
+neuere ist. Weil Commit-Bezeichner, insbesondere bei Git, nicht monoton
+steigen, müssen wir eine Revisionsnummer hinzufügen, die wir jedes Mal
+erhöhen, wenn wir das Paket auf einen neueren Snapshot aktualisieren. Die
+sich ergebende Versionszeichenkette sieht dann so aus:
 
 @example
 2.0.11-3.cabba9e
   ^    ^    ^
-  |    |    `-- upstream commit ID
+  |    |    `-- Commit-ID beim Anbieter
   |    |
-  |    `--- Guix package revision
+  |    `--- Revisionsnummer des Guix-Pakets
   |
-latest upstream version
+die neueste Version, die der Anbieter veröffentlicht hat
 @end example
 
-It is a good idea to strip commit identifiers in the @code{version} field
-to, say, 7 digits.  It avoids an aesthetic annoyance (assuming aesthetics
-have a role to play here) as well as problems related to OS limits such as
-the maximum shebang length (127 bytes for the Linux kernel.)  It is best to
-use the full commit identifiers in @code{origin}s, though, to avoid
-ambiguities.  A typical package definition may look like this:
+Es ist eine gute Idee, die Commit-Bezeichner im @code{version}-Feld auf,
+sagen wir, 7 Ziffern zu beschränken. Das sieht besser aus (angenommen, das
+sollte hier eine Rolle spielen) und vermeidet Probleme, die mit der
+maximalen Länge von Shebangs zu tun haben (127 Bytes beim Linux-Kernel). Am
+besten benutzt man jedoch den vollständigen Commit-Bezeichner in
+@code{origin}s, um Mehrdeutigkeiten zu vermeiden. Eine typische
+Paketdefinition könnte so aussehen:
 
 @example
-(define my-package
+(define mein-paket
   (let ((commit "c3f29bc928d5900971f65965feaae59e1272a3f7")
-        (revision "1"))          ;Guix package revision
+        (revision "1"))          ;Guix-Paketrevision
     (package
       (version (git-version "0.9" revision commit))
       (source (origin
                 (method git-fetch)
                 (uri (git-reference
-                      (url "git://example.org/my-package.git")
+                      (url "git://example.org/mein-paket.git")
                       (commit commit)))
                 (sha256 (base32 "1mbikn@dots{}"))
                 (file-name (git-file-name name version))))
@@ -466,58 +483,69 @@ ambiguities.  A typical package definition may look like this:
 @node Zusammenfassungen und Beschreibungen
 @subsection Zusammenfassungen und Beschreibungen
 
-@cindex package description
-@cindex package synopsis
-As we have seen before, each package in GNU@tie{}Guix includes a synopsis
-and a description (@pxref{Pakete definieren}).  Synopses and descriptions
-are important: They are what @command{guix package --search} searches, and a
-crucial piece of information to help users determine whether a given package
-suits their needs.  Consequently, packagers should pay attention to what
-goes into them.
-
-Synopses must start with a capital letter and must not end with a period.
-They must not start with ``a'' or ``the'', which usually does not bring
-anything; for instance, prefer ``File-frobbing tool'' over ``A tool that
-frobs files''.  The synopsis should say what the package is---e.g., ``Core
-GNU utilities (file, text, shell)''---or what it is used for---e.g., the
-synopsis for GNU@tie{}grep is ``Print lines matching a pattern''.
-
-Keep in mind that the synopsis must be meaningful for a very wide audience.
-For example, ``Manipulate alignments in the SAM format'' might make sense
-for a seasoned bioinformatics researcher, but might be fairly unhelpful or
-even misleading to a non-specialized audience.  It is a good idea to come up
-with a synopsis that gives an idea of the application domain of the
-package.  In this example, this might give something like ``Manipulate
-nucleotide sequence alignments'', which hopefully gives the user a better
-idea of whether this is what they are looking for.
-
-Descriptions should take between five and ten lines.  Use full sentences,
-and avoid using acronyms without first introducing them.  Please avoid
-marketing phrases such as ``world-leading'', ``industrial-strength'', and
-``next-generation'', and avoid superlatives like ``the most
-advanced''---they are not helpful to users looking for a package and may
-even sound suspicious.  Instead, try to be factual, mentioning use cases and
-features.
-
-@cindex Texinfo markup, in package descriptions
-Descriptions can include Texinfo markup, which is useful to introduce
-ornaments such as @code{@@code} or @code{@@dfn}, bullet lists, or hyperlinks
-(@pxref{Overview,,, texinfo, GNU Texinfo}).  However you should be careful
-when using some characters for example @samp{@@} and curly braces which are
-the basic special characters in Texinfo (@pxref{Special Characters,,,
-texinfo, GNU Texinfo}).  User interfaces such as @command{guix package
---show} take care of rendering it appropriately.
-
-Synopses and descriptions are translated by volunteers
-@uref{http://translationproject.org/domain/guix-packages.html, at the
-Translation Project} so that as many users as possible can read them in
-their native language.  User interfaces search them and display them in the
-language specified by the current locale.
-
-To allow @command{xgettext} to extract them as translatable strings,
-synopses and descriptions @emph{must be literal strings}.  This means that
-you cannot use @code{string-append} or @code{format} to construct these
-strings:
+@cindex Paketbeschreibung
+@cindex Paketzusammenfassung
+Wie wir bereits gesehen haben, enthält jedes Paket in GNU@tie{}Guix eine (im
+Code englischsprachige) Zusammenfassung (englisch: Synopsis) und eine
+Beschreibung (englisch: Description; siehe @ref{Pakete definieren}). Zusammenfassungen und Beschreibungen sind wichtig: Sie werden
+mit @command{guix package --search} durchsucht und stellen eine
+entscheidende Informationsquelle für Nutzer dar, die entscheiden wollen, ob
+das Paket Ihren Bedürfnissen entspricht, daher sollten Paketentwickler Acht
+geben, was sie dort eintragen.
+
+Zusammenfassungen müssen mit einem Großbuchstaben beginnen und dürfen nicht
+mit einem Punkt enden. Sie dürfen nicht mit den Artikeln »a« oder »the«
+beginnen, die meistens ohnehin nichts zum Verständnis beitragen. Zum
+Beispiel sollte »File-frobbing tool« gegenüber »A tool that frobs files«
+vorgezogen werden. Die Zusammenfassung sollte aussagen, um was es sich beim
+Paket handelt — z.B.@: »Core GNU utilities (file, text, shell)« —, oder
+aussagen, wofür es benutzt wird — z.B.@: ist die Zusammenfassung für
+GNU@tie{}grep »Print lines matching a pattern«.
+
+Beachten Sie, dass die Zusammenfassung für eine sehr große Leserschaft einen
+Sinn ergeben muss. Zum Beispiel würde »Manipulate alignments in the SAM
+format« vielleicht von einem erfahrenen Forscher in der Bioinformatik
+verstanden, könnte für die Nicht-Spezialisten in Guix’ Zielgruppe aber wenig
+hilfreich sein oder würde diesen sogar eine falsche Vorstellung geben. Es
+ist eine gute Idee, sich eine Zusammenfassung zu überlegen, die eine
+Vorstellung von der Anwendungsdomäne des Pakets vermittelt. Im Beispiel hier
+würden sich die Nutzer mit »Manipulate nucleotide sequence alignments«
+hoffentlich ein besseres Bild davon machen können, ob das Paket ist, wonach
+sie suchen.
+
+Beschreibungen sollten zwischen fünf und zehn Zeilen lang sein. Benutzen Sie
+vollständige Sätze und vermeiden Sie Abkürzungen, die Sie nicht zuvor
+eingeführt haben. Vermeiden Sie bitte Marketing-Phrasen wie »world-leading«
+(»weltweit führend«), »industrial-strength« (»industrietauglich«) und
+»next-generation« (»der nächsten Generation«) ebenso wie Superlative wie
+»the most advanced« (»das fortgeschrittenste«) — davon haben Nutzer nichts,
+wenn sie ein Paket suchen, und es könnte sogar verdächtig klingen. Versuchen
+Sie stattdessen, bei den Fakten zu bleiben und dabei Anwendungszwecke und
+Funktionalitäten zu erwähnen.
+
+@cindex Texinfo-Auszeichnungen, in Paketbeschreibungen
+Beschreibungen können wie bei Texinfo ausgezeichneten Text enthalten. Das
+bedeutet, Text kann Verzierungen wie @code{@@code} oder @code{@@dfn},
+Auflistungen oder Hyperlinks enthalten (siehe @ref{Overview,,, texinfo, GNU
+Texinfo}). Sie sollten allerdings vorsichtig sein, wenn Sie bestimmte
+Zeichen wie @samp{@@} und geschweifte Klammern schreiben, weil es sich dabei
+um die grundlegenden Sonderzeichen in Texinfo handelt (siehe @ref{Special
+Characters,,, texinfo, GNU Texinfo}). Benutzungsschnittstellen wie
+@command{guix package --show} kümmern sich darum, solche Auszeichnungen
+angemessen darzustellen.
+
+Zusammenfassungen und Beschreibungen werden von Freiwilligen
+@uref{http://translationproject.org/domain/guix-packages.html, beim
+Translation Project} übersetzt, damit so viele Nutzer wie möglich sie in
+ihrer Muttersprache lesen können. Mit Schnittstellen für Benutzer können sie
+in der von der aktuell eingestellten Locale festgelegten Sprache durchsucht
+und angezeigt werden.
+
+Damit @command{xgettext} sie als übersetzbare Zeichenketten extrahieren
+kann, @emph{müssen} Zusammenfassungen und Beschreibungen einfache
+Zeichenketten-Literale sein. Das bedeutet, dass Sie diese Zeichenketten
+nicht mit Prozeduren wie @code{string-append} oder @code{format}
+konstruieren können:
 
 @lisp
 (package
@@ -526,11 +554,12 @@ strings:
   (description (string-append "This is " "*not*" " translatable.")))
 @end lisp
 
-Translation is a lot of work so, as a packager, please pay even more
-attention to your synopses and descriptions as every change may entail
-additional work for translators.  In order to help them, it is possible to
-make recommendations or instructions visible to them by inserting special
-comments like this (@pxref{xgettext Invocation,,, gettext, GNU Gettext}):
+Übersetzen ist viel Arbeit, also passen Sie als Paketentwickler bitte umso
+mehr auf, wenn Sie Ihre Zusammenfassungen und Beschreibungen formulieren,
+weil jede Änderung zusätzliche Arbeit für Übersetzer bedeutet. Um den
+Übersetzern zu helfen, können Sie Empfehlungen und Anweisungen für diese
+sichtbar machen, indem Sie spezielle Kommentare wie in diesem Beispiel
+einfügen (siehe @ref{xgettext Invocation,,, gettext, GNU Gettext}):
 
 @example
 ;; TRANSLATORS: "X11 resize-and-rotate" should not be translated.
@@ -543,70 +572,78 @@ for the X11 resize-and-rotate (RandR) extension. @dots{}")
 @subsection Python-Module
 
 @cindex python
-We currently package Python 2 and Python 3, under the Scheme variable names
-@code{python-2} and @code{python} as explained in @ref{Versionsnummern}.  To
-avoid confusion and naming clashes with other programming languages, it
-seems desirable that the name of a package for a Python module contains the
-word @code{python}.
-
-Some modules are compatible with only one version of Python, others with
-both.  If the package Foo compiles only with Python 3, we name it
-@code{python-foo}; if it compiles only with Python 2, we name it
-@code{python2-foo}. If it is compatible with both versions, we create two
-packages with the corresponding names.
-
-If a project already contains the word @code{python}, we drop this; for
-instance, the module python-dateutil is packaged under the names
-@code{python-dateutil} and @code{python2-dateutil}.  If the project name
-starts with @code{py} (e.g.@: @code{pytz}), we keep it and prefix it as
-described above.
-
-@subsubsection Specifying Dependencies
-@cindex inputs, for Python packages
-
-Dependency information for Python packages is usually available in the
-package source tree, with varying degrees of accuracy: in the
-@file{setup.py} file, in @file{requirements.txt}, or in @file{tox.ini}.
-
-Your mission, when writing a recipe for a Python package, is to map these
-dependencies to the appropriate type of ``input'' (@pxref{»package«-Referenz,
-inputs}).  Although the @code{pypi} importer normally does a good job
-(@pxref{Aufruf von guix import}), you may want to check the following check
-list to determine which dependency goes where.
+Zur Zeit stellen wir ein Paket für Python 2 und eines für Python 3 jeweils
+über die Scheme-Variablen mit den Namen @code{python-2} und @code{python}
+zur Verfügung, entsprechend der Erklärungen im Abschnitt @ref{Versionsnummern}. Um Verwirrungen und Namenskollisionen mit anderen
+Programmiersprachen zu vermeiden, erscheint es als wünschenswert, dass der
+Name eines Pakets für ein Python-Modul auch das Wort @code{python} enthält.
+
+Manche Module sind nur mit einer Version von Python kompatibel, andere mit
+beiden. Wenn das Paket Foo nur mit Python 3 kompiliert werden kann, geben
+wir ihm den Namen @code{python-foo}, wenn es nur mit Python 2 kompilierbar
+ist, wählen wir den Namen @code{python2-foo}. Ist es mit beiden Versionen
+kompatibel, erstellen wir zwei Pakete jeweils mit dem entsprechenden Namen.
+
+Wenn ein Projekt bereits das Wort @code{python} im Namen hat, lassen wir es
+weg; zum Beispiel ist das Modul python-dateutil unter den Namen
+@code{python-dateutil} und @code{python2-dateutil} verfügbar. Wenn der
+Projektname mit @code{py} beginnt (z.B.@: @code{pytz}), behalten wir ihn bei
+und stellen das oben beschriebene Präfix voran.
+
+@subsubsection Abhängigkeiten angeben
+@cindex Eingaben, für Python-Pakete
+
+Informationen über Abhängigkeiten von Python-Paketen, welche mal mehr und
+mal weniger stimmen, finden sich normalerweise im Verzeichnisbaum des
+Paketquellcodes: in der Datei @file{setup.py}, in @file{requirements.txt}
+oder in @file{tox.ini}.
+
+Wenn Sie ein Rezept für ein Python-Paket schreiben, lautet Ihr Auftrag,
+diese Abhängigkeiten auf angemessene Arten von »Eingaben« abzubilden (siehe
+@ref{»package«-Referenz, inputs}). Obwohl der @code{pypi}-Importer hier
+normalerweise eine gute Arbeit leistet (siehe @ref{Aufruf von guix import}),
+könnten Sie die folgende Prüfliste durchgehen wollen, um zu bestimmen, wo
+welche Abhängigkeit eingeordnet werden sollte.
 
 @itemize
 
 @item
-We currently package Python 2 with @code{setuptools} and @code{pip}
-installed like Python 3.4 has per default.  Thus you don't need to specify
-either of these as an input.  @command{guix lint} will warn you if you do.
+Derzeit ist unser Python-2-Paket so geschrieben, dass es @code{setuptools}
+und @code{pip} installiert, wie es auch in den Vorgaben zu Python 3.4
+gemacht wird. Sie müssen also keines der beiden als Eingabe angeben. Wenn
+Sie es doch tun, wird @command{guix lint} Sie darauf mit einer Warnung
+aufmerksam machen.
 
 @item
-Python dependencies required at run time go into @code{propagated-inputs}.
-They are typically defined with the @code{install_requires} keyword in
-@file{setup.py}, or in the @file{requirements.txt} file.
+Python-Abhängigkeiten, die zur Laufzeit gebraucht werden, stehen im
+@code{propagated-inputs}-Feld. Solche werden typischerweise mit dem
+Schlüsselwort @code{install_requires} in @file{setup.py} oder in der Datei
+@file{requirements.txt} definiert.
 
 @item
-Python packages required only at build time---e.g., those listed with the
-@code{setup_requires} keyword in @file{setup.py}---or only for
-testing---e.g., those in @code{tests_require}---go into
-@code{native-inputs}.  The rationale is that (1) they do not need to be
-propagated because they are not needed at run time, and (2) in a
-cross-compilation context, it's the ``native'' input that we'd want.
-
-Examples are the @code{pytest}, @code{mock}, and @code{nose} test
-frameworks.  Of course if any of these packages is also required at
-run-time, it needs to go to @code{propagated-inputs}.
+Python-Pakete, die nur zur Erstellungszeit gebraucht werden — z.B.@: jene,
+die mit dem Schlüsselwort @code{setup_requires} in @file{setup.py}
+aufgeführt sind — oder die nur zum Testen gebraucht werden — also die in
+@code{tests_require} —, stehen in @code{native-inputs}. Die Begründung ist,
+dass (1) sie nicht propagiert werden müssen, weil sie zur Laufzeit nicht
+gebraucht werden, und (2) wir beim Cross-Kompilieren die »native« Eingabe
+des Wirtssystems wollen.
+
+Beispiele sind die Testrahmen @code{pytest}, @code{mock} und
+@code{nose}. Wenn natürlich irgendeines dieser Pakete auch zur Laufzeit
+benötigt wird, muss es doch in @code{propagated-inputs} stehen.
 
 @item
-Anything that does not fall in the previous categories goes to
-@code{inputs}, for example programs or C libraries required for building
-Python packages containing C extensions.
+Alles, was nicht in die bisher genannten Kategorien fällt, steht in
+@code{inputs}, zum Beispiel Programme oder C-Bibliotheken, die zur
+Erstellung von Python-Paketen mit enthaltenen C-Erweiterungen gebraucht
+werden.
 
 @item
-If a Python package has optional dependencies (@code{extras_require}), it is
-up to you to decide whether to add them or not, based on their
-usefulness/overhead ratio (@pxref{Einreichen von Patches, @command{guix size}}).
+Wenn ein Python-Paket optionale Abhängigkeiten hat (@code{extras_require}),
+ist es Ihnen überlassen, sie hinzuzufügen oder nicht hinzuzufügen, je
+nachdem wie es um deren Verhältnis von Nützlichkeit zu anderen Nachteilen
+steht (siehe @ref{Einreichen von Patches, @command{guix size}}).
 
 @end itemize
 
@@ -615,76 +652,82 @@ usefulness/overhead ratio (@pxref{Einreichen von Patches, @command{guix size}}).
 @subsection Perl-Module
 
 @cindex perl
-Perl programs standing for themselves are named as any other package, using
-the lowercase upstream name.  For Perl packages containing a single class,
-we use the lowercase class name, replace all occurrences of @code{::} by
-dashes and prepend the prefix @code{perl-}.  So the class @code{XML::Parser}
-becomes @code{perl-xml-parser}.  Modules containing several classes keep
-their lowercase upstream name and are also prepended by @code{perl-}.  Such
-modules tend to have the word @code{perl} somewhere in their name, which
-gets dropped in favor of the prefix.  For instance, @code{libwww-perl}
-becomes @code{perl-libwww}.
+Eigenständige Perl-Programme bekommen einen Namen wie jedes andere Paket,
+unter Nutzung des Namens beim Anbieter in Kleinbuchstaben. Für Perl-Pakete,
+die eine einzelne Klasse enthalten, ersetzen wir alle Vorkommen von
+@code{::} durch Striche und hängen davor das Präfix @code{perl-} an. Die
+Klasse @code{XML::Parser} wird also zu @code{perl-xml-parser}. Module, die
+mehrere Klassen beinhalten, behalten ihren Namen beim Anbieter, in
+Kleinbuchstaben gesetzt, und auch an sie wird vorne das Präfix @code{perl-}
+angehängt. Es gibt die Tendenz, solche Module mit dem Wort @code{perl}
+irgendwo im Namen zu versehen, das wird zu Gunsten des Präfixes
+weggelassen. Zum Beispiel wird aus @code{libwww-perl} bei uns
+@code{perl-libwww}.
 
 
 @node Java-Pakete
 @subsection Java-Pakete
 
 @cindex java
-Java programs standing for themselves are named as any other package, using
-the lowercase upstream name.
-
-To avoid confusion and naming clashes with other programming languages, it
-is desirable that the name of a package for a Java package is prefixed with
-@code{java-}.  If a project already contains the word @code{java}, we drop
-this; for instance, the package @code{ngsjava} is packaged under the name
+Eigenständige Java-Programme werden wie jedes andere Paket benannt, d.h.@:
+mit ihrem in Kleinbuchstaben geschriebenen Namen beim Anbieter.
+
+Um Verwirrungen und Namenskollisionen mit anderen Programmiersprachen zu
+vermeiden, ist es wünschenswert, dass dem Namem eines Pakets zu einem
+Java-Paket das Präfix @code{java-} vorangestellt wird. Wenn ein Projekt
+bereits das Wort @code{java} im Namen trägt, lassen wir es weg; zum Beispiel
+befindet sich das Java-Paket @code{ngsjava} in einem Paket namens
 @code{java-ngs}.
 
-For Java packages containing a single class or a small class hierarchy, we
-use the lowercase class name, replace all occurrences of @code{.} by dashes
-and prepend the prefix @code{java-}.  So the class @code{apache.commons.cli}
-becomes package @code{java-apache-commons-cli}.
+Bei Java-Paketen, die eine einzelne Klasse oder eine kleine
+Klassenhierarchie enthalten, benutzen wir den Klassennamen in
+Kleinbuchstaben und ersetzen dabei alle Vorkommen von @code{.} durch Striche
+und setzen das Präfix @code{java-} davor. Die Klasse
+@code{apache.commons.cli} wird also zum Paket
+@code{java-apache-commons-cli}.
 
 
 @node Schriftarten
 @subsection Schriftarten
 
 @cindex Schriftarten
-For fonts that are in general not installed by a user for typesetting
-purposes, or that are distributed as part of a larger software package, we
-rely on the general packaging rules for software; for instance, this applies
-to the fonts delivered as part of the X.Org system or fonts that are part of
-TeX Live.
-
-To make it easier for a user to search for fonts, names for other packages
-containing only fonts are constructed as follows, independently of the
-upstream package name.
-
-The name of a package containing only one font family starts with
-@code{font-}; it is followed by the foundry name and a dash @code{-} if the
-foundry is known, and the font family name, in which spaces are replaced by
-dashes (and as usual, all upper case letters are transformed to lower
-case).  For example, the Gentium font family by SIL is packaged under the
-name @code{font-sil-gentium}.
-
-For a package containing several font families, the name of the collection
-is used in the place of the font family name.  For instance, the Liberation
-fonts consist of three families, Liberation Sans, Liberation Serif and
-Liberation Mono.  These could be packaged separately under the names
-@code{font-liberation-sans} and so on; but as they are distributed together
-under a common name, we prefer to package them together as
-@code{font-liberation}.
-
-In the case where several formats of the same font family or font collection
-are packaged separately, a short form of the format, prepended by a dash, is
-added to the package name.  We use @code{-ttf} for TrueType fonts,
-@code{-otf} for OpenType fonts and @code{-type1} for PostScript Type 1
-fonts.
+Wenn Schriftarten in der Regel nicht von Nutzern zur Textbearbeitung
+installiert werden oder als Teil eines größeren Software-Pakets mitgeliefert
+werden, gelten dafür die allgemeinen Paketrichtlinien für Software. Zum
+Beispiel trifft das auf als Teil des X.Org-Systems ausgelieferte
+Schriftarten zu, oder auf Schriftarten, die ein Teil von TeX Live sind.
+
+Damit es Nutzer leichter haben, nach Schriftarten zu suchen, konstruieren
+wir die Namen von anderen Paketen, die nur Schriftarten enthalten, nach dem
+folgenden Schema, egal was der Paketname beim Anbieter ist.
+
+Der Name eines Pakets, das nur eine Schriftfamilie enthält, beginnt mit
+@code{font-}. Darauf folgt der Name des Schriftenherstellers und ein Strich
+@code{-}, sofern bekannt ist, wer der Schriftenhersteller ist, und dann der
+Name der Schriftfamilie, in dem Leerzeichen durch Striche ersetzt werden
+(und wie immer mit Großbuchstaben statt Kleinbuchstaben). Zum Beispiel
+befindet sich die von SIL hergestellte Gentium-Schriftfamilie im Paket mit
+dem Namen @code{font-sil-gentium}.
+
+Wenn ein Paket mehrere Schriftfamilien enthält, wird der Name der Sammlung
+anstelle des Schriftfamiliennamens benutzt. Zum Beispiel umfassen die
+Liberation-Schriftarten drei Familien: Liberation Sans, Liberation Serif und
+Liberation Mono. Man könnte sie getrennt voneinander mit den Namen
+@code{font-liberation-sans} und so weiter in Pakete einteilen, da sie aber
+unter einem gemeinsamen Namen angeboten werden, packen wir sie lieber
+zusammen in ein Paket mit dem Namen @code{font-liberation}.
+
+Für den Fall, dass mehrere Formate derselben Schriftfamilie oder
+Schriftartensammlung in separate Pakete kommen, wird ein Kurzname für das
+Format mit einem Strich vorne zum Paketnamen hinzugefügt. Wir benutzen
+@code{-ttf} für TrueType-Schriftarten, @code{-otf} für OpenType-Schriftarten
+und @code{-type1} für PostScript-Typ-1-Schriftarten.
 
 
 @node Code-Stil
 @section Code-Stil
 
-Im Allgemeinen folgt unser Code den GNU Coding Standards (@pxref{Top,,,
+Im Allgemeinen folgt unser Code den GNU Coding Standards (siehe @ref{Top,,,
 standards, GNU Coding Standards}). Da diese aber nicht viel über Scheme zu
 sagen haben, folgen hier einige zusätzliche Regeln.
 
@@ -747,7 +790,7 @@ Ein paar in Guix eingeführte Sonderformen, wie zum Beispiel das
 sind in der Datei @file{.dir-locals.el} definiert, die Emacs automatisch
 benutzt. Beachten Sie auch, dass Emacs-Guix einen Modus namens
 @code{guix-devel-mode} bereitstellt, der Guix-Code richtig einrückt und
-hervorhebt (@pxref{Development,,, emacs-guix, The Emacs-Guix Reference
+hervorhebt (siehe @ref{Entwicklung,,, emacs-guix, The Emacs-Guix Reference
 Manual}).
 
 @cindex Einrückung, Code-
@@ -800,60 +843,61 @@ unter @uref{https://bugs.gnu.org/guix-patches}, wodurch wir den Überblick
 über Eingereichtes behalten können. Jede an diese Mailing-Liste gesendete
 Nachricht bekommt eine neue Folgenummer zugewiesen, so dass man eine
 Folge-Email zur Einreichung an @code{@var{NNN}@@debbugs.gnu.org} senden
-kann, wobei @var{NNN} für die Folgenummer steht (@pxref{Senden einer Patch-Reihe}).
+kann, wobei @var{NNN} für die Folgenummer steht (siehe @ref{Senden einer Patch-Reihe}).
 
-Bitte schreiben Sie Commit-Logs im ChangeLog-Format (@pxref{Change Logs,,,
-standards, GNU Coding Standards}); dazu finden Sie Beispiele unter den
-bisherigen Commits.
+Bitte schreiben Sie Commit-Logs im ChangeLog-Format (siehe @ref{Change
+Logs,,, standards, GNU Coding Standards}); dazu finden Sie Beispiele unter
+den bisherigen Commits.
 
 Bevor Sie einen Patch einreichen, der eine Paketdefinition hinzufügt oder
 verändert, gehen Sie bitte diese Prüfliste durch:
 
 @enumerate
 @item
-Wenn die Autoren der verpackten Software eine kryptographische Signatur für
-den Tarball der Veröffentlichung anbieten, so machen Sie sich bitte die
-Mühe, die Echtheit des Archivs zu überprüfen.  Für eine abgetrennte
-GPG-Signaturdatei würden Sie das mit dem Befehl @code{gpg --verify} tun.
+Wenn die Autoren der verpackten Software eine kryptografische Signatur
+bzw. Beglaubigung für den Tarball der Veröffentlichung anbieten, so machen
+Sie sich bitte die Mühe, die Echtheit des Archivs zu überprüfen. Für eine
+abgetrennte GPG-Signaturdatei würden Sie das mit dem Befehl @code{gpg
+--verify} tun.
 
 @item
 Nehmen Sie sich die Zeit, eine passende Zusammenfassung und Beschreibung für
-das Paket zu verfassen. Unter @xref{Zusammenfassungen und Beschreibungen} finden Sie
+das Paket zu verfassen. Unter @ref{Zusammenfassungen und Beschreibungen} finden Sie
 dazu einige Richtlinien.
 
 @item
 Verwenden Sie @code{guix lint @var{Paket}}, wobei @var{Paket} das neue oder
-geänderte Paket bezeichnet, und beheben Sie alle gemeldeten Fehler
-(@pxref{Aufruf von guix lint}).
+geänderte Paket bezeichnet, und beheben Sie alle gemeldeten Fehler (siehe
+@ref{Aufruf von guix lint}).
 
 @item
 Stellen Sie sicher, dass das Paket auf Ihrer Plattform erstellt werden kann,
 indem Sie @code{guix build @var{Paket}} ausführen.
 
 @item
-We recommend you also try building the package on other supported
-platforms.  As you may not have access to actual hardware platforms, we
-recommend using the @code{qemu-binfmt-service-type} to emulate them.  In
-order to enable it, add the following service to the list of services in
-your @code{operating-system} configuration:
+Wir empfehlen, dass Sie auch versuchen, das Paket auf anderen unterstützten
+Plattformen zu erstellen. Da Sie vielleicht keinen Zugang zu echter Hardware
+für diese Plattformen haben, empfehlen wir, den
+@code{qemu-binfmt-service-type} zu benutzen, um sie zu emulieren. Um ihn zu
+aktivieren, fügen Sie den folgenden Dienst in die Liste der Dienste
+(»services«) in Ihrer @code{operating-system}-Konfiguration ein:
 
 @example
 (service qemu-binfmt-service-type
  (qemu-binfmt-configuration
-   (platforms (lookup-qemu-platforms "arm" "aarch64" "ppc" "mips64el"))
+   (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
    (guix-support? #t)))
 @end example
 
-Then reconfigure your system.
+Rekonfigurieren Sie anschließend Ihr System.
 
-You can then build packages for different platforms by specifying the
-@code{--system} option.  For example, to build the "hello" package for the
-armhf, aarch64, powerpc, or mips64 architectures, you would run the
-following commands, respectively:
+Sie können Pakete für andere Plattformen erstellen lassen, indem Sie die
+Befehlszeilenoption @code{--system} angeben. Um zum Beispiel das Paket
+»hello« für die Architekturen armhf, aarch64 oder mips64 erstellen zu
+lassen, würden Sie jeweils die folgenden Befehle angeben:
 @example
 guix build --system=armhf-linux --rounds=2 hello
 guix build --system=aarch64-linux --rounds=2 hello
-guix build --system=powerpc-linux --rounds=2 hello
 guix build --system=mips64el-linux --rounds=2 hello
 @end example
 
@@ -874,17 +918,18 @@ einzuspielen, die aber das gesamte System betreffen — gebündelt
 mitgelieferte Kopien würden dies verhindern.
 
 @item
-Take a look at the profile reported by @command{guix size} (@pxref{Aufruf von guix size}).  This will allow you to notice references to other packages
-unwillingly retained.  It may also help determine whether to split the
-package (@pxref{Pakete mit mehreren Ausgaben.}), and which optional
-dependencies should be used.  In particular, avoid adding @code{texlive} as
-a dependency: because of its extreme size, use @code{texlive-tiny} or
-@code{texlive-union} instead.
+Schauen Sie sich das von @command{guix size} ausgegebene Profil an (siehe
+@ref{Aufruf von guix size}). Dadurch können Sie Referenzen auf andere Pakete
+finden, die ungewollt vorhanden sind. Dies kann auch dabei helfen, zu
+entscheiden, ob das Paket aufgespalten werden sollte (siehe @ref{Pakete mit mehreren Ausgaben.}) und welche optionalen Abhängigkeiten verwendet
+werden sollten. Dabei sollten Sie es wegen seiner enormen Größe insbesondere
+vermeiden, @code{texlive} als eine Abhängigkeit hinzuzufügen; benutzen Sie
+stattdessen @code{texlive-tiny} oder @code{texlive-union}.
 
 @item
 Achten Sie bei wichtigen Änderungen darauf, dass abhängige Pakete (falls
 vorhanden) nicht von der Änderung beeinträchtigt werden; @code{guix refresh
---list-dependent @var{Paket}} hilft Ihnen dabei (@pxref{Aufruf von guix refresh}).
+--list-dependent @var{Paket}} hilft Ihnen dabei (siehe @ref{Aufruf von guix refresh}).
 
 @c See <https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00933.html>.
 @cindex Branching-Strategie
@@ -899,9 +944,9 @@ statt, nach ungefähr diesen Regeln:
 
 @item zwischen 300 und 1200 abhängige Pakete
 @code{staging}-Branch (störfreie Änderungen). Dieser Branch wird circa alle
-3 Wochen in @code{master} gemerget. Themenbezogene Änderungen (z.B. eine
-Aktualisierung der GNOME-Plattform) können stattdessen auch auf einem
-eigenen Branch umgesetzt werden (wie @code{gnome-updates}).
+3 Wochen mit @code{master} zusammengeführt. Themenbezogene Änderungen
+(z.B.@: eine Aktualisierung der GNOME-Plattform) können stattdessen auch auf
+einem eigenen Branch umgesetzt werden (wie @code{gnome-updates}).
 
 @item mehr als 1200 abhängige Pakete
 @code{core-updates}-Branch (kann auch größere und womöglich andere Software
@@ -932,7 +977,7 @@ Sie typischerweise, ob eine unabhängige Erstellung des Pakets genau dasselbe
 Ergebnis wie Ihre Erstellung hat, Bit für Bit.
 
 Dies können Sie leicht tun, indem Sie dasselbe Paket mehrere Male
-hintereinander auf Ihrer Maschine erstellen (@pxref{Aufruf von guix build}):
+hintereinander auf Ihrer Maschine erstellen (siehe @ref{Aufruf von guix build}):
 
 @example
 guix build --rounds=2 mein-paket
@@ -942,20 +987,22 @@ Dies reicht aus, um eine ganze Klasse häufiger Ursachen von
 Nichtdeterminismus zu finden, wie zum Beispiel Zeitstempel oder
 zufallsgenerierte Ausgaben im Ergebnis der Erstellung.
 
-Another option is to use @command{guix challenge} (@pxref{Aufruf von guix challenge}).  You may run it once the package has been committed and built
-by @code{@value{SUBSTITUTE-SERVER}} to check whether it obtains the same
-result as you did.  Better yet: Find another machine that can build it and
-run @command{guix publish}.  Since the remote build machine is likely
-different from yours, this can catch non-determinism issues related to the
-hardware---e.g., use of different instruction set extensions---or to the
-operating system kernel---e.g., reliance on @code{uname} or @file{/proc}
-files.
+Eine weitere Möglichkeit ist, @command{guix challenge} (siehe @ref{Aufruf von guix challenge}) zu benutzen. Sie können es ausführen, sobald ein Paket
+commitet und von @code{@value{SUBSTITUTE-SERVER}} erstellt wurde, um zu
+sehen, ob dort dasselbe Ergebnis wie bei Ihnen geliefert wurde. Noch besser:
+Finden Sie eine andere Maschine, die das Paket erstellen kann, und führen
+Sie @command{guix publish} aus. Da sich die entfernte Erstellungsmaschine
+wahrscheinlich von Ihrer unterscheidet, können Sie auf diese Weise Probleme
+durch Nichtdeterminismus erkennen, die mit der Hardware zu tun haben — zum
+Beispiel die Nutzung anderer Befehlssatzerweiterungen — oder mit dem
+Betriebssystem-Kernel — zum Beispiel, indem @code{uname} oder
+@file{/proc}-Dateien verwendet werden.
 
 @item
 Beim Schreiben von Dokumentation achten Sie bitte auf eine
 geschlechtsneutrale Wortwahl, wenn Sie sich auf Personen beziehen, wie
 @uref{https://en.wikipedia.org/wiki/Singular_they, »they«@comma{}
-»their«@comma{} »them« im Singular}, und so weiter.
+»their«@comma{} »them« im Singular} und so weiter.
 
 @item
 Stelllen Sie sicher, dass Ihr Patch nur einen Satz zusammengehöriger
@@ -969,11 +1016,11 @@ zusammen mit Fehlerbehebungen für das Paket.
 @item
 Bitte befolgen Sie unsere Richtlinien für die Code-Formatierung, womöglich
 wollen Sie dies automatisch tun lassen durch das Skript
-@command{etc/indent-code.el} (@pxref{Formatierung von Code}).
+@command{etc/indent-code.el} (siehe @ref{Formatierung von Code}).
 
 @item
-Benutzen Sie, wenn möglich, Spiegelserver (Mirrors) in der Quell-URL
-(@pxref{Aufruf von guix download}). Verwenden Sie verlässliche URLs, keine
+Benutzen Sie, wenn möglich, Spiegelserver (Mirrors) in der Quell-URL (siehe
+@ref{Aufruf von guix download}). Verwenden Sie verlässliche URLs, keine
 automatisch generierten. Zum Beispiel sind Archive von GitHub nicht immer
 identisch von einer Generation auf die nächste, daher ist es in diesem Fall
 besser, als Quelle einen Klon des Repositorys zu verwenden. Benutzen Sie
@@ -984,7 +1031,7 @@ wirklich und wenn sich der Name ändert, stimmt die URL nicht mehr.
 
 Bitte benutzen Sie @samp{[PATCH] @dots{}} als Betreff, wenn Sie einen Patch
 an die Mailing-Liste schicken. Sie können dazu Ihr E-Mail-Programm oder den
-Befehl @command{git send-email} benutzen (@pxref{Senden einer Patch-Reihe}). Wir bevorzugen es, Patches als reine Textnachrichten zu erhalten,
+Befehl @command{git send-email} benutzen (siehe @ref{Senden einer Patch-Reihe}). Wir bevorzugen es, Patches als reine Textnachrichten zu erhalten,
 entweder eingebettet (inline) oder als MIME-Anhänge. Sie sind dazu
 angehalten, zu überprüfen, ob Ihr Mail-Programm solche Dinge wie
 Zeilenumbrüche oder die Einrückung verändert, wodurch die Patches womöglich
@@ -1000,9 +1047,9 @@ Sie eine E-Mail an @email{@var{NNN}-done@@debbugs.gnu.org} senden.
 @cindex @code{git-send-email}
 
 @c Debbugs bug: https://debbugs.gnu.org/db/15/15361.html
-Wenn Sie eine Patch-Reihe senden (z.B. mit @code{git send-email}), schicken
-Sie bitte als Erstes eine Nachricht an @email{guix-patches@@gnu.org} und
-dann nachfolgende Patches an @email{@var{NNN}@@debbugs.gnu.org}, um
-sicherzustellen, dass sie zusammen bearbeitet werden. Siehe
-@uref{https://debbugs.gnu.org/Advanced.html, die Debbugs-Dokumentation} für
-weitere Informationen.
+Wenn Sie eine Patch-Reihe senden (z.B.@: mit @code{git send-email}),
+schicken Sie bitte als Erstes eine Nachricht an
+@email{guix-patches@@gnu.org} und dann nachfolgende Patches an
+@email{@var{NNN}@@debbugs.gnu.org}, um sicherzustellen, dass sie zusammen
+bearbeitet werden. Siehe @uref{https://debbugs.gnu.org/Advanced.html, die
+Debbugs-Dokumentation} für weitere Informationen.