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 

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,



To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to