Re: [RFR] man://manpages-l10n/perl5422delta.1perl.po

Helge Kreutzmann <[email protected]> Fri, 29 May 2026 15:32:05 +0000
Newsgroups	gmane.linux.debian.internationalization.german
Message-ID	<[email protected]>
Moin Mario,
Am Thu, May 28, 2026 at 09:43:03PM +0200 schrieb Mario Blättermann:
> Am Do., 28. Mai 2026 um 20:47 Uhr schrieb Helge Kreutzmann
> <[email protected]>:
> >
> >
> > > #. type: Plain text
> > > #: archlinux
> > > msgid ""
> > > "The list above is almost certainly incomplete as it is automatically "
> > > "generated from version control history.  In particular, it does not include "
> > > "the names of the (very much appreciated) contributors who reported issues to "
> > > "the Perl bug tracker."
> > > msgstr ""
> > > "Die vorstehende Liste ist wahrscheinlich unvollständig, da sie automatisch "
> > > "aus dem Verlauf einer Revisionssteuerung erstellt wurde. Insbesondere "
> > > "enthält sie die (besonders wertgeschätzten) Beitragenden nicht, die Probleme "
> > > "in die Fehlerdatenbank von Perl berichteten."
> > >
> > > die Probleme in die Fehlerdatenbank von Perl berichteten.
> > > →
> > > die im Fehlererfassungssystem von Perl Probleme gemeldet haben.
> >
> > Ich finde „Fehlerdatenbank“ gar nicht so schlecht, und so steht es
> > auch in unserer Wortliste. Ich habe mal geschaut, auf der Webseite von
> > Perl (selbst im „Issue tracker“) konnte ich auf die schnelle keine
> > deutsche Übersetzung finden und im Wikipedia-Artikel gibts auch
> > anscheinen keinen Treffer.
> 
> Das »Fehlererfassungssystem« als Begriff ist damals im
> Gnome-Übersetzungsteam entstanden:
> https://wiki.gnome.org/de/StandardUebersetzungen
> Wenn ich mich recht entsinne, hatten wir uns deshalb dafür
> entschieden, weil der Benutzer Fehler _erfassen_ soll; dass eine
> Datenbank im Hintergrund werkelt, kann ihm ja schnuppe sein. Er kriegt
> davon nichts mit, der _Vorgang_ des Meldens ist entscheidend.

Danke für die Erläuterung, wie genau es zur Fehlerdatenbank gekommen
ist, weiß ich nicht, der Begriff war schon zu meinen Anfängen gesetzt.
Er ist etwas freier, ich fand' ihn aber nicht schlecht. 

Ich verstehe Deine Argumentation, aber ganz streng genommen möchte der
Benutzer, dass die Fehler behoben werden, das Erfassen ist nur ein
notwendiges Übel. 

Als optimal finde ich es noch nicht, aber Deine Argumetation ist etwas
näher Richtung Optimum, daher ändere ich es. 

> > > msgid ""
> > > "If the bug you are reporting has security implications which make it "
> > > "inappropriate to send to a public issue tracker, then see \"SECURITY "
> > > "VULNERABILITY CONTACT INFORMATION\" in perlsec for details of how to report "
> > > "the issue."
> > > msgstr ""
> > > "Falls Ihr Fehlerbericht Sicherheits-Implikationen enthält, weswegen er nicht "
> > > "zum Senden an eine öffentliche Fehlerdatenbank geeignet ist, dann lesen Sie "
> > > "den Abschnitt »SECURITY VULNERABILITY CONTACT INFORMATION« in B<perlsec>(1), "
> > > "um Details zum Berichten des Problems zu erfahren."
> > >
> > > Falls Ihr Fehlerbericht Sicherheits-Implikationen enthält,
> > > →
> > > Falls Ihr Fehlerbericht sicherheitskritische Informationen enthält,
> >
> > Würde „Auswirkungen“ statt „Implikationen“ für Dich besser klingen?
> > Oder „Auswirkungen auf die Sicherheit“?
> >
> 
> Wenn du nicht so am Wortlaut des Originals kleben würdest, dann wäre
> meine Version für dich sicher akzeptabel. Aber von mir aus auch
> »Implikationen → Auswirkungen«. Ist kaum besser, aber es ist deine
> Entscheidung.

Deine Übersetzung ist mir zu frei. Ich nehme dann „Auswirkungen“.

> > > #. type: Plain text
> > > #: archlinux
> > > msgid ""
> > > "The I<Changes> file for an explanation of how to view exhaustive details on "
> > > "what changed."
> > > msgstr ""
> > > "Die Datei I<Changes> für eine Erläuterung, wie die vollständigen Details der "
> > > "Änderungen betrachtet werden können."
> > >
> > > → In der Datei I<Changes> finden Sie detaillierte Informationen über
> > > die Änderungen.
> >
> > Nein, das ist Teil von „siehe auch“, und immer gleich strukturiert.
> >
> 
> Ja, eben… Wenn schon so etwas in SEE ALSO steht, dann gern mit
> Weblinks. Diese immer gleich strukturierten Einträge gehen
> stillschweigend davon aus, dass der Leser weiß, wo er nach den Dateien
> suchen muss. Das ist schon das Grundproblem. Die Formulierung ist das
> nächste…

Den ersten Teil (wo die Dateien liegen) adressiere ich mit einem
FIXME.

Zur Formulierung: Ich finde, es ist vielleicht nicht elegant, aber
passt:

SEE ALSO The I<Changes> file for an explanation …

> > > So ähnlich sollte es idealerweise auch im Original lauten. Ich bin nun
> > > wahrlich alles andere als ein englischer Muttersprachler, aber
> > > stilistisch ist die ganze Handbuchseite grausig. Entweder braucht es
> > > hier jede Menge FIXMEs oder du verabschiedest dich vom wortgetreuen
> > > Übersetzen und lässt das Original, wie es eben ist.
> >
> > Es ist ja im wesentlichen ein Änderungsprotokoll. Aber ich berichte
> > auch dazu, wenn ich die FIXMEs komme, bin hier aber nicht sehr
> > kritisch dran gegangen, weil die Datei ja nur eine endliche Relevanz
> > hat.
> >
> Warum es überhaupt ein Änderungsprotokoll in Form einer Handbuchseite
> geben muss, erschließt sich mir sowieso nicht. Die Seite ist de facto
> statisch, also brauchst du eigentlich gar keine FIXMEs zu bemühen, es
> wird sich sowieso nichts ändern.

Ich schaue mal, ein paar Perl-FIXMEs wurden ja wohl schon adressiert,
ich war dadurch mal auf perl porters aktiv. 

Vielen Dank für die Erläuterungen.

Viele Grüße

          Helge

-- 
      Dr. Helge Kreutzmann                     [email protected]
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/
signature.asc (application/pgp-signature, 833 B)