Hallo, Mario,
(ich habe der Länge der Mail wegen nur die Textteile in dieser Antwort drin
gelassen, auf die ich noch etwas sagen möchte; ich hoffe, das ist Ok für dich.
Am 09.03.2014 13:14, schrieb Mario Blättermann:
> Am 09.03.2014 13:29, schrieb Stephan Beck:
>> [...]
>> Ist es eigentlich immer sicher, dass "man pages" bisher von Muttersprachlern
>> verfasst wurden?
>
> Nein. überhaupt nicht. Handbuchseiten werden in aller Regel in
> Amerikanischem Englisch geschrieben, aber natürlich nicht nur von
> Muttersprachlern. Hier geht es einfach darum, dass ein Autor, auch wenn
> er in englisch zu schreiben hat, eine Anleitung dazu in seiner
> Muttersprache erhält. Selbst für mich, der als Übersetzer sowieso
> Englisch können muss (auf welchem Level auch immer), ist es hilfreich,
> wenn die Anleitung in deutsch ist. Das Problem war halt nur, dass alle
> Strings, die Bestandteile der zukünftigen Handbuchseite sind, auch in
> Englisch angezeigt werden, sonst müsste sich der Leser die erst zurück
> übersetzen, um sie verwenden zu können.
Ok, danke. Wozu der Text dient, wusste ich ja schon aus deinen vorherigen Mails,
aber mir kam bei bestimmten Formulierungen des Originals der Gedanke, dass es
nicht unbedingt (dennoch aber möglich) ein Muttersprachler gewesen sein muss.
>
>> ------------------------------------------------------------------------
>> #. type: TP
>> #, no-wrap
>> msgid "B<VERSIONS>"
>> msgstr "B<VERSIONS>"
>>
>> #. type: Plain text
>> msgid ""
>> "A brief summary of the Linux kernel or glibc versions where a system call or "
>> "library function appeared, or changed significantly in its operation. As a "
>> "general rule, every new interface should include a VERSIONS section in its "
>> "manual page. Unfortunately, many existing manual pages don't include this "
>> "information (since there was no policy to do so when they were written). "
>> "Patches to remedy this are welcome, but, from the perspective of programmers "
>> "writing new code, this information probably matters only in the case of "
>> "kernel interfaces that have been added in Linux 2.4 or later (i.e., changes "
>> "since kernel 2.2), and library functions that have been added to glibc since "
>> "version 2.1 (i.e., changes since glibc 2.0)."
>> msgstr ""
>> "Hier steht eine kurze Zusammenfassung der Linux-Kernel oder Glibc-Versionen, "
>> "in denen ein Systemaufruf oder eine Bibliotheksfunktion erschien oder das "
>> "Verhalten wesentlich veränderte. Als allgemeine Regel gilt, dass jede neue "
>> "Schnittstelle einen VERSIONS-Abschnitt in der Handbuchseite bewirkt. Leider "
>> "verfügen viele bestehende Handbuchseiten nicht über diese Informationen (da "
>> "es dafür keine entsprechende Richtlinie gab, als sie geschrieben wurden). "
>> "Patches zur Ergänzung dieser Abschnitte sind willkommen. Aus der Sicht von "
>> "Programmierern, die neuen Code schreiben, werden diese Informationen wohl "
>> "nur für Kernel-Schnittstellen interessant sein, die in Linux 2.4 oder später "
>> "hinzugefügt wurden und für geänderte Bibliotheksfunktionen in der Glibc seit "
>> "Version 2.1. (D. h. also Veränderungen seit Kernel 2.2 und Glibc 2.0)."
>>
>> s/erschien/enthalten war (erscheinen passt nicht so gut, "vorkommen" , siehe
>> nächster Satz, passt viel besser!!)
> Hier geht es um das erste Erscheinen der Funktion, nicht ob sie mal
> irgendwo enthalten war. Das erste Auftreten soll hier dokumentiert werden.
Ja, ich verstehe, aber "erscheinen" würde ich vielleicht nur bei der
Software-Version (wie auch bei einem Buch oder CD) selbst verwenden. Bspw.
"erscheinen" manchen Leuten Engel oder Elfen, um mal spaßhaft deutlich zu
machen, wie das Verb ansonsten meist verwendet wird. "Erstmals enthalten war"
ginge doch, aber ich mach kein Drama daraus.
>> #. type: TP
>> #, no-wrap
>> msgid "B<CONFORMING TO>"
>> msgstr "B<CONFORMING TO>"
>>
>> #. type: Plain text
>> msgid ""
>> "describes any standards or conventions that relate to the function or "
>> "command described by the manual page. The preferred terms to use for the "
>> "various standards are listed as headings in B<standards>(7). For a page in "
>> "Section 2 or 3, this section should note the POSIX.1 version(s) that the "
>> "call conforms to, and also whether the call is specified in C99. (Don't "
>> "worry too much about other standards like SUS, SUSv2, and XPG, or the SVr4 "
>> "and 4.xBSD implementation standards, unless the call was specified in those "
>> "standards, but isn't in the current version of POSIX.1.) (See "
>> "B<standards>(7).)"
>> msgstr ""
>> "Dieser Abschnitt beschreibt alle Normen oder Konventionen, die die Funktion "
>> "oder einen von der Handbuchseite beschrieben Befehl betreffen. Die "
>> "bevorzugten Ausdrücke für die verschiedenen Standards sind als Überschriften "
>> "in B<standards>(7) aufgeführt. Für eine Handbuchseite in Abschnitt 2 oder 3, "
>> "sollten hier die POSIX.1-Version(en) stehen, denen der Aufruf entspricht. "
>> "Auch sollte angegeben werden, ob der Aufruf in C99 beschrieben ist. (Sorgen "
>> "Sie sich nicht zu sehr über andere Standards wie SUS, SUSv2 und XPG oder die "
>> "SVr4- und 4.xBSD-Implementierungsstandards, es sei denn, der Aufruf wurde in "
>> "diesen Standards beschrieben, ist aber nicht in der aktuellen Version von "
>> "POSIX.1 enthalten; siehe B<standards>(7).)"
>>
>> s/die Funktion oder einen von der Handbuchseite beschrieben Befehl betreffen/
>> Funktionen oder Befehle betreffen, die auf den Handbuchseiten beschrieben
>> werden. (hier kann man meines Erachtens ohne Gefahr pluralisieren, da es bei
>> dieser Handbuchschreiberanleitung ums Allgemeine geht, d.h. wie man überhaupt
>> ein Handbuch/=Handbücher für UNIX-Programme schreiben sollte)
> Hm, so viel deutlicher macht es das auch nicht. Die Handbuchschreiber
> sind keine Low-Level-Benutzer, denen man für die einfachsten Sachen noch
> ein Tutorial an die Hand geben muss. Der Autor weiß, dass es hier um
> *seine* Handbuchseite geht, davon gehe ich aus.
Ja,aber beim Originalsatz bezieht sich das "described by the manual page" sowohl
auf Funktionen als auch auf Befehle; in deinem Satz nicht, während es durch das
Versetzen in die (unbestimmte) Mehrzahl wiederum erreicht wird. Nur darum ging
es mir.
>> s/sorgen über Standards/sorgen um Standards
>> vielleicht wäre es besser, durchgängig entweder Standards oder Normen zu
>> verwenden, nur um der begrifflichen Geschlossenheit willen)
>>
> Ich habe es während der Revision einer anderen Handbuchseitenübersetzung
> mal etwa so formuliert: Ich bin durchaus für Konsistenz, aber die
> Begriffe müssen nicht immer unbedingt im preußischen Stechschritt am
> Leser vorbeimarschieren. Man beachte das Zielpublikum. Es sind
> Entwickler oder wenigstens Benutzer auf einem höheren Niveau. Die werden
> wissen, wie sie mit »Normen« und »Standards« umzugehen haben.
> »um Standards« habe ich so übernommen.
Auweia, das muss aber eine polemische Diskussion gewesen sein! Ich hoffe, ich
mache nicht einen gleichartigen Eindruck auf dich. :-(
Ich habe nur darauf hingewiesen, dass begriffliche Konsistenz zumindest bei
technischen Übersetzungen wichtig ist, weil ich das in den 15 Jahren, die ich
als freiberuflicher Übersetzer tätig war, auch erst habe lernen müssen.
Ansonsten hat Helge mit seiner Nachricht vollkommen Recht, das hatte ich nicht
erwähnt. Hier sollte "Normen" nicht verwendet werden. Die Gründe hat Helge ja
schon genannt.
>>
>>
>> #. type: Plain text
>> msgid ""
>> "If the call is not governed by any standards but commonly exists on other "
>> "systems, note them. If the call is Linux-specific, note this."
>> msgstr ""
>> "Wenn der Aufruf von keinen Standards geregelt ist, aber allgemein auf "
>> "anderen Systemen vorhanden ist, erwähnen Sie das. Wenn der Aufruf Linux-"
>> "spezifisch ist, erwähnen Sie auch das."
>>
>> s/das(1)/diese (genauerer Bezug)
>>
> Der Autor soll »das« erwähnen, also die Tatsache. Wie soll er »diese«
> Standards erwähnen, wenn der Aufruf von keinen Standards geregelt ist?
"...note them" = erwähnen Sie (die anderen Systeme)
>>
>> #. type: Plain text
>> msgid ""
>> "(Using this format, rather than the use of \"\\efB...\\efP()\" makes it "
>> "easier to write tools that parse man page source files.)"
>> msgstr ""
>> "Die Verwendung dieses Formats anstatt der Verwendung von »\\efB...\\efP()« "
>> "erleichtert die Entwicklung von Werkzeugen für die Auswertung von Handbuch-"
>> "Quelltexten."
>>
>> s/der Verwendung von/- - - (redundant)
>> s/Auswertung/syntaktische Analyse und Aufgliederung (?)
>>
> Redundanz beseitigt, aber Letzteres ist etwas übertrieben. Ob Debugger
> oder Validierungswerkzeuge davon profitieren, ist dem Autor egal. Hier
> geht es in erster Linie um die Auswertung durch den Parser, der die
> Syntax einliest und daraus eine Bildschirmanzeige, einfachen Text,
> DocBook, PDF oder was auch immer daraus macht. Die Einzelheiten sind
> eher uninteressant. Der Autor (in seiner Eigenschaft als Leser dieser
> Anleitung) ist hier das Frontend, nicht das Backend.
Ok, "Auswertung" passt besser.
>>
>> #. type: SS
>> #, no-wrap
>> msgid "Preferred terms"
>> msgstr "Bevorzugte Ausdrücke"
>>
>> #. type: Plain text
>> msgid ""
>> "The following table lists some preferred terms to use in man pages, mainly "
>> "to ensure consistency across pages."
>> msgstr ""
>> "Die folgende Tabelle führt einige bevorzugte Ausdrücke auf, die in "
>> "Handbuchseiten verwendet werden sollten, hauptsächlich um Konsistenz "
>> "innerhalb der Sammlung der Handbuchseiten sicherzustellen."
>>
>> s/Ausdrücke/Begriffe
>> ("Expressions" wurden oben bereits als "Ausdrücke" übersetzt: begriffliche
>> Konsistenz/Verwechslungsgefahr!)
Ich bin nicht im Stechschritt unterwegs :-) Du hast es unkommentiert gelassen.
Hier wäre ich trotzdem dafür, Ausdrücke nicht zu verwenden, auch wenn bei
"expressions" Ausdrücke im mathematischen Sinn gemeint sind, und hier bei
"terms" im (allgemein-)sprachlichen Sinn. Es könnte bei dem ein oder anderen
Verwirrung stiften.
(Denkpause)
Ok, ich bin ein Fanatiker ;-)
>
> Ich habe die Datei ins Git eingebracht. Aufgrund deiner zahlreichen
> Änderungsvorschläge habe ich mir die Freiheit genommen, deinen Namen
> samt Mailadresse im Dateikopf zu hinterlassen, so dass er später im
> Addendum der übersetzten Handbuchseite erscheint.
Danke, das freut mich natürlich: ich hoffe aber, du stehst da wenigstens auch
noch drin, falls es Kritik hagelt! ;-)
LG
Stephan
>
> Gruß Mario
>
>
Attachment:
signature.asc
Description: OpenPGP digital signature