manpages-de: Übersetzung von C-Programmfragmenten

01/10/2010 - 20:50 von Martin Eberhard Schauer | Report spam
Hallo an alle,

insbesondere vielleicht aktive C-Programmierer in der Gruppe.

Ich habe zu Anfang die "italienische Taktik" beim DDTP-Projekt
angewendet: ermitteln, welche
Übersetzungen wenig Aufwand machen und diese dann angehen. Auf dieser
Grundlage habe
ich dann viele Manpages aus den Abschnitten 2 und 3 übersetzt.

Nach den Rückmeldungen einiger sehr engagierter Lektoren scheine ich zu
dem zu neigen, was ich
selber eigentlich nicht prickelnd finde: denglisch. Begriffe nicht
übersetzen und damit Unschàrfe
einführen. Damit argumentieren, dass dies, das und jenes einem
Programmierer ein Begriff sein
sollte. Und implizieren, das eben die Eindeutschung ("in Fachkreisen")
etablierter Begriffe eben den
fachkundigen Nutzer dazu verleitet, doch das Original zu nehmen, damit
er nicht zurück übersetzen
muss. Das wiederum hat zur Folge, dass unsere Arbeit hier zumindest
teilweise für die Katz ist.

Nach dem Vorwort zum Konkreteren:

Befehle für Benutzer (ohne Superuser-Rechte, Abschnitt 1) und die
Systemverwaltung (Abschnitt 8)
haben mit der Referenz für Programmierer (das sind für mich (im engeren
Sinn) die Abschnitte 2 und
3) als Beschreibung die Handbuchseiten gemeinsam.

Der gemeinsamen Struktur der Beschreibung steht der unterschiedliche
Charakter der Inhalte
gegenüber. Für Benutzer- und Administrationsbefehle folge ich der
sinnvollen Praxis, in den
Handbuchseiten Optionen und Argumente zu übersetzen.

Im Programmierhandbuch enthàlt die ÜBERSICHT eine #include-Anweisung für
die zugehörige
Header-Datei und einen (oder mehrere) Funktionsprototyp(en). Die Namen
der Argumente der
Funktionen übersetze ich bislang nicht, damit im folgenden Text der
Bezug zum Header klar bleibt.
Eure Meinung?

Bei den Datentypen sind wohl ganze Zahlen / Ganzzahlen für Integer,
Zeichen für Char(acter),
Zeichenkette für String und Feld für Array gàngig. Was sollte/kann/darf
man noch übersetzen?
Was ist Overkill für / verwirrt den Programmierer?

Viele Grüße
Martin


To UNSUBSCRIBE, email to debian-l10n-german-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/4CA62C4F.3010706@gmx.de
 

Lesen sie die antworten

#1 Frederik Schwarzer
02/10/2010 - 10:50 | Warnen spam
[Martin Eberhard Schauer - Freitag 01 Oktober 2010 20:45:35]
Hallo an alle,

insbesondere vielleicht aktive C-Programmierer in der Gruppe.

Ich habe zu Anfang die "italienische Taktik" beim DDTP-Projekt
angewendet: ermitteln, welche
Übersetzungen wenig Aufwand machen und diese dann angehen. Auf dieser
Grundlage habe
ich dann viele Manpages aus den Abschnitten 2 und 3 übersetzt.

Nach den Rückmeldungen einiger sehr engagierter Lektoren scheine ich zu
dem zu neigen, was ich
selber eigentlich nicht prickelnd finde: denglisch. Begriffe nicht
übersetzen und damit Unschàrfe
einführen. Damit argumentieren, dass dies, das und jenes einem
Programmierer ein Begriff sein
sollte. Und implizieren, das eben die Eindeutschung ("in Fachkreisen")
etablierter Begriffe eben den
fachkundigen Nutzer dazu verleitet, doch das Original zu nehmen, damit
er nicht zurück übersetzen
muss. Das wiederum hat zur Folge, dass unsere Arbeit hier zumindest
teilweise für die Katz ist.



Finde ich nicht. Die meisten Menschen, die des Englischen nicht
màchtig sind, haben ihre Probleme nicht mit ein paar Fachbegriffen,
sondern damit den Kontext verstehen, in dem diese stehen. Ist der
Rest des Satzes deutsch, ist das einfacher.


Nach dem Vorwort zum Konkreteren:

Befehle für Benutzer (ohne Superuser-Rechte, Abschnitt 1) und die
Systemverwaltung (Abschnitt 8)
haben mit der Referenz für Programmierer (das sind für mich (im engeren
Sinn) die Abschnitte 2 und
3) als Beschreibung die Handbuchseiten gemeinsam.

Der gemeinsamen Struktur der Beschreibung steht der unterschiedliche
Charakter der Inhalte
gegenüber. Für Benutzer- und Administrationsbefehle folge ich der
sinnvollen Praxis, in den
Handbuchseiten Optionen und Argumente zu übersetzen.

Im Programmierhandbuch enthàlt die ÜBERSICHT eine #include-Anweisung für
die zugehörige
Header-Datei und einen (oder mehrere) Funktionsprototyp(en). Die Namen
der Argumente der
Funktionen übersetze ich bislang nicht, damit im folgenden Text der
Bezug zum Header klar bleibt.
Eure Meinung?

Bei den Datentypen sind wohl ganze Zahlen / Ganzzahlen für Integer,
Zeichen für Char(acter),
Zeichenkette für String und Feld für Array gàngig. Was sollte/kann/darf
man noch übersetzen?
Was ist Overkill für / verwirrt den Programmierer?



Ich halte das im Rahmen einer allgemeinen Diskussion für nicht klàrbar.
Es müssen schon konkrete Begriffe besprochen werden.
"Unit Test" ist z. B. so ein Begriff, den ich nicht übersetzen würde.
Mir fallen auch viele ein, die gute deutsche Entsprechungen haben,
obwohl diese auch von mir nicht immer verwendet werden:
Namespace -> Namensraum
Scope -> Gültigkeitsbereich
Exception -> Ausnahme
...

Wie gesagt. Es ist schwer, sich jetzt hinzusetzen, und alles aufzuzàhlen,
was einem in den Sinn kommt. Ich würde das am Begriff selbst diskutieren.

MfG


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/

Ähnliche fragen