From: Christian Stimming <stimming@tuhh.de>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: "Ralf Thielow" <ralf.thielow@gmail.com>,
"Sven Fuchs" <svenfuchs@artweb-design.de>,
"Ralph Haussmann" <ralph@scanmyfood.de>,
git@vger.kernel.org, "Jan Engelhardt" <jengelh@inai.de>,
"Jan Krüger" <jk@jk.gs>
Subject: Re: English/German terminology, git.git's de.po, and pro-git
Date: Thu, 16 May 2013 12:49:13 +0200 [thread overview]
Message-ID: <2181104.gkP5j47vG8@cs-pc> (raw)
In-Reply-To: <87k3n36nvo.fsf@linux-k42r.v.cablecom.net>
Dear translators,
Here's the main point in this discussion: The translation is not for us! The
translation is for those who don't speak much English and who don't know the
English git terminology very well. By definition, this target audience is not
present here on this mailing list and in this discussion. Hence, arguments
such as "I like word x better" are rather weak. Instead, stating "Word x gives
the intended target audience a better picture of what is going on" is probably
a better argument.
Am Montag, 13. Mai 2013, 14:54:51 schrieb Thomas Rast:
> However, an unfortunate and unsatisfactory situation has developed:
> Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
> Thielow built core git's de.po on top of it, so it's also Ger.
>
> Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
> translation of pro-git (which is also quite mature at this point, having
> apparently begun in 2009), and as you probably guessed by now, it's G+E.
Thanks, Thomas, for spotting the conflicting translations in those excellent
book projects vs. the git core and git gui. I think it's rather obvious why
the pro-git translators chose the G+E approach for their work: Their goal is
to explain the command line usage of git, which means they inevitably have to
use the git command names, which happen to be in English (and will surely stay
so). Hence, any translation approach will have to deal with the English
command names as useful words in the normal translated text. That's probably a
constraint that is true for any translation of a command-line tool to stay
useful.
I noticed with some amusement, though, that even in the pro-git book with the
described constraint there are places where a "pure Ger" translation is almost
shining through... Such as in [1]: "Jedes Mal, wenn Du committest (d.h. den
gegenwärtigen Status deines Projektes als eine Version in Git speicherst)..."
Can you notice how the translators identified "Version" as translation for
"commit (noun)" and "speichern" as translation for "commit (verb)" :-) ? Of
course this is just the explanation and not the actual translation later
during the text.
However, I take this spot as an example that there exist meaningful pure-Ger
translations even for the most important git terminology. In fact, to find
useful Ger translations, I wonder how I would talk to someone from the target
audience a sentence such as "Finde mal den richtigen Commit, also die Version,
..." When I find myself saying such an " - also das xy -" appendix often
enough, I take this as an indication that the latter word can just as well be
used as the main translation.
Back to the original question: I think the book shows quite nicely that for
working with the git command line, a G+E translation is more useful as long as
the command names also appear unchangedly in the translation. However,
everything else that does not appear as a command name can be translated
either in G+E or in Ger. The argument can go on to state that someone who is
geek enough to use the command line is probably more proficient in English
language anyway. Hence, using more English terms in the translation is
probably fine as well and a full G+E translation is probably a good approach.
The pro-git book has some places where the translated word is not always used
consistently (e.g. in [2] "Externes Repository" vs. "Remote Repository"), and
some G+E suggestions from this mailing list have been translated Ger in the
book (they use "zusammenführen" in [2] and [3] instead of "merge" with only a
few exceptions). It is also a good point to make the pro-git and git core
translation consistent, once the approach is decided on.
*However*: This argument is completely different when we talk about the GUI
tools. The target audience of the git gui etc. are those developers who write
great code, but #1 do not know the English language well enough, and #2 are so
far away from the geek corner that they use a development workflow purely in
GUI tools. The question is: What GUI button labels helps those people the most
to get a good picture of what is going on? And in this case I still believe a
pure Ger translation is the better choice! I wonder how feedback on this claim
can be collected from developers of the target audience. When I started on the
git-gui translation, I asked some coworkers that fall into this category for
feedback on the wordings, and their response indicated agreement to my
approach. What feedback have others here heard from people who fall into
described category? At the end of the day that sort of feedback has to be the
ground for a decision on the approach in the GUI translation.
In the meantime I think a different translation approach between git core and
git gui is not a problem at all. For git gui I propose to stick to a Ger
translation. For git core and the books that describe the command line
interface, a G+E translation is probably a good choice but even in this case
there is room for useful German words instead of taking all difficult terms
directly as English ones.
By the way, I'm puzzled why this sort of discussion appears only for German
language translations and not others. Don't other languages have the same
conflict of the English terms and potential translated words which are then
unknown to the geeks on this list? Just curious.
Best Regards,
Christian
[1] http://git-scm.com/book/de/Los-geht%27s-Git-Grundlagen
[2] http://git-scm.com/book/de/Git-Grundlagen-Mit-externen-Repositorys-
arbeiten
[3] http://git-scm.com/book/de/Git-Branching-Basic-Branching-and-Merging
prev parent reply other threads:[~2013-05-16 10:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-13 12:54 English/German terminology, git.git's de.po, and pro-git Thomas Rast
2013-05-13 13:57 ` Jan Engelhardt
2013-05-13 17:19 ` Jens Lehmann
2013-05-13 18:57 ` AW: " Ralph Haußmann
2013-05-13 19:25 ` Jan Engelhardt
2013-05-14 17:51 ` Ralf Thielow
2013-05-15 10:23 ` Holger Hellmuth (IKS)
2013-05-15 11:26 ` Jens Lehmann
2013-05-15 11:56 ` Jan Engelhardt
2013-05-15 12:27 ` Jens Lehmann
2013-05-15 13:14 ` Jan Engelhardt
2013-05-15 15:31 ` Holger Hellmuth (IKS)
2013-05-15 17:28 ` Jan Engelhardt
2013-05-16 5:57 ` Ralf Thielow
2013-05-16 8:48 ` Holger Hellmuth (IKS)
2013-05-19 16:06 ` Ralf Thielow
2013-05-19 16:56 ` Ralf Thielow
2013-05-20 4:01 ` Holger Hellmuth
2013-05-22 14:09 ` Ralf Thielow
2013-05-16 9:00 ` Thomas Rast
2013-05-19 16:49 ` Ralf Thielow
2013-05-19 16:53 ` Ralf Thielow
2013-05-20 19:41 ` Christian Stimming
2013-05-22 15:16 ` Ralf Thielow
2013-05-22 15:52 ` Holger Hellmuth (IKS)
2013-05-22 16:43 ` Jan Engelhardt
2013-05-23 18:16 ` Bernhard R. Link
2013-05-24 16:41 ` Ralf Thielow
2013-06-16 21:22 ` Jan Engelhardt
2013-05-24 16:51 ` Ralf Thielow
2013-05-13 16:30 ` Ralf Thielow
2013-05-16 10:49 ` Christian Stimming [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2181104.gkP5j47vG8@cs-pc \
--to=stimming@tuhh.de \
--cc=git@vger.kernel.org \
--cc=jengelh@inai.de \
--cc=jk@jk.gs \
--cc=ralf.thielow@gmail.com \
--cc=ralph@scanmyfood.de \
--cc=svenfuchs@artweb-design.de \
--cc=trast@inf.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).