-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Language style question #49
Comments
Die Beispielübersetzung stammt glaub ich sogar noch aus dem alten (2008) Versuch einer deutschen Übersetzung. Deshalb wird da auch noch von "Projektarchiv (repository)" gesprochen wogegen die deutsche Git-Übersetzung eigentlich nur noch von "Repository" spricht. Die englischen Git-Manpages haben meistens (wenn es um einen Befehl geht) unter NAME den jeweiligen Git-Befehl gefolgt von einer ausformulierten englischen Variante des Befehls den man Git gibt. z.B.
Aktuell folgt die Übersetzung da meistens recht nah dem Original, d.h. normalerweise Imperativ, Singular. Das klingt auf deutsch leider tatsächlich manchmal ein bischen wie ein Befehl an den Leser Die Debian-Manpages haben diese Zusammenfassung als ausformulierten Befehl zum Teil auch, sind aber in sich nicht unbedingt konsistent, wie sie das übersetzen. Bei dpkg-buildpackage(1), dpkg-genbuildinfo(1), dpkg-gensymbols(1) und dpkg-scanpackages(1) verwendet Debian auch den Imperativ, bei apt-mark(8), addgroup(8), deluser(8) und grep(1) verwendet Debian 3. Person Singular und bei cp(1), apt-cache(8) und dpkg-parsechangelog(1) ist noch eine dritte Variante im Spiel, die ich sehr gelungen finde. Diese Variante scheint auch dem zu entsprechen was die Git-Übersetzung mit diesen Kurzzusammenfassungen macht. Also für das
wobei ich hier fast sagen würde, dass "in ein neues Verzeichnis" sinnvoller als "in einem neuen Verzeichnis" ist. Dann gibt es noch Beschreibungen von Kommandozeilenoptionen, die im Original auch oft im Imperativ formuliert sind.
Da habe ich es ähnlich gehalten, habe mir aber öfter erlaubt vom Imperativ abzuweichen, wenn die Übersetzung komisch klang, insbesondere, da diese Beschreibungen teilweise auch im Original nichtmal innerhalb einer Manpage konsequent im Imperativ geschrieben sind. Der Rest sollte eigentlich 3. Person Singular sein. Prinzipiell orientiere ich mich an den Debian-Manpages, wenn es nichts vergleichbares in der Git-Übersetzung finde und denke das sollten wir auch so beibehalten, dass die Git-Manpages vorrangig mit Git (hauptsächlich Sonstige stilistische oder potentiell hilfreiche Hinweise Für Git-spezifische Begriffe, die sich nicht in der Git-Übersetzung finden gucke ich auch manchmal in die deutsche ProGit2-Übersetzung, allerdings muss man da meistens erst den englischen Begriff im original raussuchen um herauszufinden, wo man ungefähr in der Übersetzung suchen muss. Wenn der Leser direkt angesprochen wird sieze ich den Leser. Das entspricht soweit ich das sehe sowohl der Git-Übersetzung, als auch den Debian-Manpages und der Progit2-Übersetzung. Prinzipiell stammen viele Übersetzungen bei denen ein deutscher Begriff gefolgt vom englischen Begriff in Klammern verwendet wird (und sich das so durch die ganze Datei ziehen) aus der alten Manpage-Übersetzung und sind Begriffe die früher auch in der Git-Übersetzung so verwendet wurden. Diese sollten an die Begriffe aus der modernen Git-Übersetzung angepasst werden. Also z.B. "Repository" statt "Projektarchiv (repository)". Stellenweise kann es aber sinnvoll sein einmalig in Klammern auf die englische Bezeichnung hinzuweisen, z.B. "Markierung (tag)". |
Danke für deinen ausführlichen Kommentar. Ich sehe, dass meine Frage nicht so einfach zu beantworten ist, da es offensichtlich mehrere Varianten gibt. Wenn in EXAMPLES (ich bevorzuge hier den dt. Begriff BEISPIELE) dagegen, die direkte Ansprache über „you“ benutzt wird, sollte „Sie“ verwendet werden, statt dem neutralen „man“ oder dem persönlichen „Du“. Falls dort aber der Imperativ verwendet wird, würde ich dem auch so folgen. Auf diese Art könnten wir Inkonsistenzen aus den englischen Texten vermeiden/entfernen und die Übersetzung einheitlicher gestalten. Viele dieser Probleme entstehen, weil eine Vielzahl von Autoren an der Entstehung der Texte beteiligt sind/waren. Das sollte uns aber nicht hindern, bei „subjektiv“ für unrichtig empfundene Passagen einen Gegenvorschlag zu machen.
Da ich zu einem nicht unerheblichen Teil diese Übersetzung mit verfasst habe, ist es schon lustig zu sehen, dass wir gegenseitig versucht haben voneinander „abzuschreiben“. BTW:
Ich habe die Datei zwar gesehen, aber bisher keine Anleitung gefunden wie ich sie in eine lokale Git-Installation einbinden kann. |
Hello, just to tell you that some of the manpages in German are already available on git-scm.com. I have a remark though: in https://git-scm.com/docs/git-add/de#git-add---pathspec-from-fileltDateigt You can see a divergence between bracketed terms in the definition list item and the definition text. |
Thanks for that remark. Will fix to "<Datei>". Edit: |
@rimrul EDIT: Done |
Thanks. |
This question only concerns the German translations, so I am formulating it here in German in order to be better understood.
@rimrul
Eine grundsätzliche Frage zum Sprachstil in den Übersetzungen der Git-Manpages.
In den mir bekannten Übersetzungen von Manpages (z.B. apt(8) und dpkg-buildpackage(1) aus der Debian Distribution) werden die erklärenden Texte zu einem Befehl oder einer Option in der 3. Person Singular verfasst. Dabei ist der Text so formuliert als, ob er das Ergebnis des Befehl-Aufrufs sei.
Hier, in einigen vorhandenen Übersetzungen, wird der Text dagegen wie eine Aufforderung formuliert den Befehl auszuführen.
Beispiel:
Ich denke, dass meine Version sich näher an den Übersetzungen der übrigen Manpages orientiert.
Wie soll zukünftig verfahren werden?
The text was updated successfully, but these errors were encountered: