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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ca62c4f.3010...@gmx.de
