l10n: de.po: translate 38 new messages

Translate 38 new messages came from git.pot update in fe05e19
(l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
po/TEAMS: add new members to German translation team

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Merge git://github.com/git-l10n/git-po

* git://github.com/git-l10n/git-po:
  po/TEAMS: add new members to German translation team
  l10n: de.po: translate 38 new messages
print an error when remote helpers die during capabilities

The transport-helper code generally relies on the
remote-helper to provide an informative message to the user
when it encounters an error. In the rare cases where the
helper does not do so, the output can be quite confusing.
E.g.:

  $ git clone https://example.com/foo.git
  Cloning into 'foo'...
  $ echo $?
  128
  $ ls foo
  /bin/ls: cannot access foo: No such file or directory

We tried to address this with 81d340d (transport-helper:
report errors properly, 2013-04-10).

But that makes the common case much confusing. The remote
helper protocol's method for signaling normal errors is to
simply hang up. So when the helper does encounter a routine
error and prints something to stderr, the extra error
message is redundant and misleading. So we dropped it again
in 266f1fd (transport-helper: be quiet on read errors from
helpers, 2013-06-21).

This puts the uncommon case right back where it started. We
may be able to do a little better, though. It is common for
the helper to die during a "real" command, like fetching the
list of remote refs. It is not common for it to die during
the initial "capabilities" negotiation, right after we
start. Reporting failure here is likely to catch fundamental
problems that prevent the helper from running (and reporting
errors) at all. Anything after that is the responsibility of
the helper itself to report.