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
Description: PGP signature
