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