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
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 : "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  "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  and  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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html