Skip to content
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

Open
max123kl opened this issue Apr 23, 2020 · 6 comments
Open

Language style question #49

max123kl opened this issue Apr 23, 2020 · 6 comments

Comments

@max123kl
Copy link
Contributor

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:

(Source) 		git-clone - Clone a repository into a new directory
(1.Übersetzung) 	git-clone - Klone ein Projektarchiv (repository) in ein neues Verzeichnis
(mein Vorschlag)	git-clone – Klont ein Repository (Projektarchiv) in ein neues Verzeichnis

Ich denke, dass meine Version sich näher an den Übersetzungen der übrigen Manpages orientiert.
Wie soll zukünftig verfahren werden?

@rimrul
Copy link
Contributor

rimrul commented Apr 24, 2020

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.

git-clone - Clone a repository into a new directory
git-mv - Move or rename a file, a directory, or a symlink

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 git clone-Beispiel

git-clone - Ein Repository in einem neuen Verzeichnis klonen

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.

-n::
--dry-run::
Do nothing; only show what would happen

--overwrite-ignore::
--no-overwrite-ignore::
Silently overwrite ignored files from the merge result. This
is the default behavior. Use --no-overwrite-ignore to abort.

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 git help) konsistent sind, dann erst zweitrangig mit anderen Manpages.


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)".

@max123kl
Copy link
Contributor Author

Danke für deinen ausführlichen Kommentar.

Ich sehe, dass meine Frage nicht so einfach zu beantworten ist, da es offensichtlich mehrere Varianten gibt.
Meinem Sprachgefühl nach, halte ich den Imperativ dann für weniger elegant, wenn es sich um allgemeine Beschreibungstexte handelt (wie bei den Abschnitten NAME, BESCHREIBUNG oder OPTIONEN). Stattdessen würde ich dort die 3. Person Singular bevorzugen (unabhängig vom englischen Text).

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.

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.

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“.
Wir haben dort die Datei TRANSLATION_NOTES_DE.asc eingerichtet, um ein paar allgemeine Regeln festzulegen und um Begriffe möglichst gleichartig zu übersetzen (ähnlich dem Glossar bei Weblade).

BTW:

die deutsche Git-Übersetzung

Ich habe die Datei zwar gesehen, aber bisher keine Anleitung gefunden wie ich sie in eine lokale Git-Installation einbinden kann.

@jnavila
Copy link
Owner

jnavila commented Apr 28, 2020

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.

@rimrul
Copy link
Contributor

rimrul commented Apr 28, 2020

Thanks for that remark. Will fix to "<Datei>".

Edit: --ignore-removal in the same man page also has a few stray "<pathspec>"s that should be "<Pfadspezifikation>" instead.

@max123kl
Copy link
Contributor Author

max123kl commented Apr 28, 2020

@rimrul
I can do these fixes, if you want.

EDIT: Done

@rimrul
Copy link
Contributor

rimrul commented Apr 28, 2020

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@jnavila @max123kl @rimrul and others