# Re: [PATCH 1/2] po/de.po: add German translation 15 messages from 2010-09-15 to 2010-09-17. Participants: Christian Stimming, Thomas Rast, Michael J Gruber, Thomas Hochstein, Andreas Schwab, Jan Krüger, Ævar Arnfjörð Bjarmason, Jens Lehmann, Junio C Hamano. Thread: https://gitlist.dev/t/25107 ## Christian Stimming, 2010-09-15 07:33 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de> URL: https://gitlist.dev/e/20100915093313.44396t6yr62ixccg%40webmail.tu-harburg.de ``` Dear Thomas, Jan, et al., thanks for the discussion of an initial git translation to German. I appreciate the efforts to translate not only the gui tools of git, but also the command line commands as well. I completely agree with Thomas' proposal to discuss and agree on a glossary of terms *first*, and *secondly* preparing the actual translation - otherwise it will be impossible to create a consistent translation. As you might guess, as the (initial) translator of git-gui I've been through this discussion before [1] and as you have noticed, I have decided to take a translation approach different from what you have recently discussed here. I deliberately tried to translate as much of the terms into German as possible. I do not agree about the importance of statements on this mailing list like "This translation translates too much terms - I cannot find the commands I'm used to". The point of a translation is to enable the usage of a program to people who do *not* know the original language. This is the target audience. By definition, this excludes anyone who participates on *this* mailing list from the target audience: Obviously you not only speak English very well, but you are daily familiar with the English git wording for the concepts inside this VCS. Then let me repeat: A translation is not for you. You know, the bait and the fisherman and the fish and such. Instead, a translation is for people who do neither know nor understand the English wording for the git concepts. For this target audience, the goal is to find a set of terms for the different git concepts which makes the concepts most easily accessible for their language. This may or may not include terms which are left at English words. Having said that, I would also take the following inspiration with a grain of salt: > You said on IRC that you left all English terms that > are also used on > http://de.wikipedia.org/wiki/Versionskontrolle Wikipedia is a bad reference for measuring the importance of certain things. I (or you) could have easily adapted that article to my point of view before continuing the discussion. However, in this particular case that article doesn't even mention many of the terms which need to be discussed in a git glossary. Having said that as well, I admit the translation of the command line tools is somewhat more difficult than a GUI tool, because many of the git concepts appear as English words in the command itself. Hence, I admit it is much more difficult to decide on a non-English translation, but having to mention the English term all the time because that's the command which needs to be used. And for sure we won't want to translate the (main porcelain) command names. Hence, the decision on terms which are left in English can surely be decided differently here than in the GUI tools. After this introduction, I would like to comment on a few of the proposed German glossary translations; the IMHO easier ones first: > branch Branch (m.) I'd go for "Zweig". It's even on the wikipedia page and it perfectly represents the concept. > index Index I'd strongly vote for not using "Index". The "Index" is where the "Bundesprüfstelle für jugendgefährdende Schriften" puts the Ballerspiele on. Don't let the identical word fool you into thinking this is a worthwhile translation. Also, the English term is a bad naming anyway IMHO. I'd use git-gui's replacement (staging area) and use "Bereitstellung" here as well. Feel free to propose something different, but please not "Index". Git isn't FSK18. > commit (noun, verb) Commit/committen That's a hard one. It sounds terrible to use "committen" in German. I would strongly vote for not using this word directly, but I admit I also don't have a completely convincing alternative. > revision Revision Die "Revision" kommt ins Haus, um die Bücher zu prüfen. Honestly, please don't use that word in German. Why not "Version"? > tag Tag Der heutige Tag oder der morgige Tag? What's the problem with "Markierung"? This is exactky the git concept which is meant. > tree Tree I would not understand what the "Tree" in German should be. Any German word instead? Many other of the proposals are just fine and very good. Keep up the good work! Regards, Christian Stimming [1] http://article.gmane.org/gmane.comp.version-control.git/58315 ``` ## Thomas Rast, 2010-09-15 09:47 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <201009151147.45314.trast@student.ethz.ch> URL: https://gitlist.dev/e/201009151147.45314.trast%40student.ethz.ch In-Reply-To: <20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de> ``` Hi Christian Christian Stimming wrote: > > As you might guess, as the (initial) translator of git-gui I've been > through this discussion before [1] and as you have noticed, I have > decided to take a translation approach different from what you have > recently discussed here. I deliberately tried to translate as much of > the terms into German as possible. I do not agree about the importance > of statements on this mailing list like "This translation translates > too much terms - I cannot find the commands I'm used to". [...] > Instead, a translation is for people who do neither know nor > understand the English wording for the git concepts. For this target > audience, the goal is to find a set of terms for the different git > concepts which makes the concepts most easily accessible for their > language. This may or may not include terms which are left at English > words. Maybe there should be two sets of translations then. I'm only half serious, but the problem here is what I said earlier in the thread (referring to Jan's draft): } In any case it roughly matches (or still stays slightly on the } more-German side of) the colloquial usage in my group, if that is } any indication. "My group" is a bunch of CS researchers, so I can't say they fall outside the description above. However, in our work we observe a very funny split between translating and keeping the terms in English: graph Graph vertex Knoten edge Kante directed gerichtet DAG (directed acyclic graph) DAG independent set independent set cut (vertex, edge) cut (vertex, edge) degree Grad matching Matching tree Baum MST (minimum spanning tree) MST (minimaler Spannbaum) There are German terms for all the untranslated ones, but I rarely hear them in practical usage. Books probably go for a full translation since they want to be normative (how should I know, it's been a while since I used a German book), but lectures stick to the half-translated version. And much like the average computer scientist around here uses a number of English terms even in German informal speech, I suspect the average German user of git would not translate *every* term. Unless you are aiming for a normative usage, in which case we would also have to translate the theory (manpages, books) using the same terms... I'll leave it at that for my $0.02, since as you note, I'm not actually the intended audience. By the way: > > index Index > > I'd strongly vote for not using "Index". The "Index" is where the > "Bundesprüfstelle für jugendgefährdende Schriften" puts the > Ballerspiele on. Don't let the identical word fool you into thinking > this is a worthwhile translation. Also, the English term is a bad > naming anyway IMHO. I'd use git-gui's replacement (staging area) and > use "Bereitstellung" here as well. Feel free to propose something > different, but please not "Index". Git isn't FSK18. I guess I will have to go for a de_CH translation then. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Michael J Gruber, 2010-09-15 11:10 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <4C90A9A2.5050705@drmicha.warpmail.net> URL: https://gitlist.dev/e/4C90A9A2.5050705%40drmicha.warpmail.net In-Reply-To: <20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de> ``` Christian Stimming venit, vidit, dixit 15.09.2010 09:33: > Dear Thomas, Jan, et al., > > thanks for the discussion of an initial git translation to German. I > appreciate the efforts to translate not only the gui tools of git, but > also the command line commands as well. I completely agree with > Thomas' proposal to discuss and agree on a glossary of terms *first*, > and *secondly* preparing the actual translation - otherwise it will be > impossible to create a consistent translation. I've been holding back a post titled "Halt the l10n madness" in my mental drafts folder for a while, and I'm happy the issue has been raised now. I guess I'm not the only one passing (out) on seeing "PATCH 0/159"... I totally agree on the glossary first approach. I'm just seeing that the actual translations do not undergo much discussion, and I hope that it would be different for a glossary. >> branch Branch (m.) > > I'd go for "Zweig". It's even on the wikipedia page and it perfectly > represents the concept. +1 Zweig, of course, what else? :) The main abstract concept underlying not only Git's revision control is that of a direct acylcic graph (DAG). There are established translations for that concept in combinatorics, which we should follow. > >> index Index > > I'd strongly vote for not using "Index". The "Index" is where the > "Bundesprüfstelle für jugendgefährdende Schriften" puts the > Ballerspiele on. Don't let the identical word fool you into thinking > this is a worthwhile translation. Also, the English term is a bad > naming anyway IMHO. I'd use git-gui's replacement (staging area) and > use "Bereitstellung" here as well. Feel free to propose something > different, but please not "Index". Git isn't FSK18. This reasoning - while certainly entertaining - reflects a very limited view on German vocabulary. I don't think the Bundesprüfstelle has been around in the 19th century when (or earlier) this word made it into the German language. In fact, "Index" is a "Verzeichnis" (in the sense of registry), and its latin root "indicare" which resonates in the original meaning of the German "Index" (announce, make known, indicate) makes it the perfect translation of the word "index" as we use it in Git. "Register" would also make sense, but whenever there is a German word with the same root (index/Index) which is not a "false friend" we should go for that. Note that we should not overemphasise the issue of connotations, or Git should really be FSK16, i.e. PG or stricter - I mean, Git's idea of the result of "committing is 1 files changed, 1 insertions(+), 0 deletions(-) Makes you think differently about "commit early, commit often." ;) > >> commit (noun, verb) Commit/committen > > That's a hard one. It sounds terrible to use "committen" in German. I > would strongly vote for not using this word directly, but I admit I > also don't have a completely convincing alternative. "Eintrag", "eintragen" Here, Git itself leaves the picture of trees and DAGs (or else a commit would be a vertex or node). > >> revision Revision > > Die "Revision" kommt ins Haus, um die Bücher zu prüfen. Honestly, > please don't use that word in German. Why not "Version"? +1 Again, that reflects a limited view of the use of "Revision", but I have no objection against "Version". Even our existing glossary says that a "revision" is what other scms call a "version". > >> tag Tag > > Der heutige Tag oder der morgige Tag? What's the problem with > "Markierung"? This is exactky the git concept which is meant. "Markierung" is OK, but I'd go for the shorter "Marke" as in "Marke setzen" etc. Even the connotation with "Briefmarke" is beneficial, as you tag something by putting a label on it, just like a stamp. > >> tree Tree > > I would not understand what the "Tree" in German should be. Any German > word instead? "Baum"! It's the combinatorics term for an undirected acyclic graph, it's the literal translation, and it's established also in the context where we mostly use it in Git: "Verzeichnisbaum" (directory tree) > > Many other of the proposals are just fine and very good. Keep up the > good work! I guess I'll have to revisit that, it was probably among some 159 patches or so I marked read in one thread... Cheers/Tschüß, Michael ``` ## Thomas Hochstein, 2010-09-15 11:44 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: URL: https://gitlist.dev/e/gcvg.1009151344.2868%40thorondor.akallabeth.de In-Reply-To: <20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de> ``` Christian Stimming schrieb: > I do not agree about the importance > of statements on this mailing list like "This translation translates > too much terms - I cannot find the commands I'm used to". The point of > a translation is to enable the usage of a program to people who do > *not* know the original language. This is the target audience. I don't agree. I prefer to use localized/translated software [1], even though I'm able to speak English, because it's just easier to use, but I strongly consider translated technical terms nearly unusable - you lose a common base for communication with other people and you can't use most documentation any longer as it'll be in English or at least use the original, non-translated technical terms. So I think the target audience for a German translation is neither only nor primarily people not understanding English [2] but all those who do speak English but prefer a localized environment. Don't let us get back to the times where a "computer" was a "Rechenmaschine", the CPU a "Zentralrecheneinheit" or email "elektronische Post" ... -thh [1] And German translations of books, movies etc. - mostly, that is. [2] You won't get far in IT if you're not able to understand at least some English, I think. ``` ## Michael J Gruber, 2010-09-15 11:51 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <4C90B344.6060002@drmicha.warpmail.net> URL: https://gitlist.dev/e/4C90B344.6060002%40drmicha.warpmail.net In-Reply-To: <201009151147.45314.trast@student.ethz.ch> ``` Thomas Rast venit, vidit, dixit 15.09.2010 11:47: > Hi Christian > > Christian Stimming wrote: >> >> As you might guess, as the (initial) translator of git-gui I've been >> through this discussion before [1] and as you have noticed, I have >> decided to take a translation approach different from what you have >> recently discussed here. I deliberately tried to translate as much of >> the terms into German as possible. I do not agree about the importance >> of statements on this mailing list like "This translation translates >> too much terms - I cannot find the commands I'm used to". > [...] >> Instead, a translation is for people who do neither know nor >> understand the English wording for the git concepts. For this target >> audience, the goal is to find a set of terms for the different git >> concepts which makes the concepts most easily accessible for their >> language. This may or may not include terms which are left at English >> words. > > Maybe there should be two sets of translations then. > > I'm only half serious, but the problem here is what I said earlier in > the thread (referring to Jan's draft): > > } In any case it roughly matches (or still stays slightly on the > } more-German side of) the colloquial usage in my group, if that is > } any indication. > > "My group" is a bunch of CS researchers, so I can't say they fall > outside the description above. However, in our work we observe a very > funny split between translating and keeping the terms in English: > > graph Graph > vertex Knoten > edge Kante > directed gerichtet > DAG (directed acyclic graph) DAG > independent set independent set > cut (vertex, edge) cut (vertex, edge) > degree Grad > matching Matching > tree Baum > MST (minimum spanning tree) MST (minimaler Spannbaum) > > There are German terms for all the untranslated ones, but I rarely > hear them in practical usage. Books probably go for a full > translation since they want to be normative (how should I know, it's > been a while since I used a German book), but lectures stick to the > half-translated version. Any active graduate student or researcher is used to English articles and books and doesn't need a translation at all, or could do completely with a translated glossary. I assume we do the (extensive!) translation work for people who could not use Git without a translation. And that mandates translating as much as possible (including man pages...). As far as the various disciplines go, CS is always on the side of importing more terms from English rather than translating. If we agree that a group of CS researchers is the target I'm fine with it - but it would imply backing out l10n ;) Note that I don't want to create any bad feelings against the l10n efforts. If it is done then I want it to be done right and not rushed, a bad one does more harm than anything. I probably won't be contributing to translations of commands, but I'm in for the glossary to help it have a sound start. Michael ``` ## Andreas Schwab, 2010-09-15 16:54 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: URL: https://gitlist.dev/e/m2fwxb6j6r.fsf%40igel.home In-Reply-To: <4C90A9A2.5050705@drmicha.warpmail.net> ``` Michael J Gruber writes: > Christian Stimming venit, vidit, dixit 15.09.2010 09:33: >> >>> revision Revision >> >> Die "Revision" kommt ins Haus, um die Bücher zu prüfen. Honestly, >> please don't use that word in German. Why not "Version"? > > +1 > Again, that reflects a limited view of the use of "Revision", but I have > no objection against "Version". Even our existing glossary says that a > "revision" is what other scms call a "version". A more literal translation would be "Änderung", which I think isn't all that bad. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ``` ## Jan Krüger, 2010-09-16 10:57 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <20100916125751.163d8691@jk.gs> URL: https://gitlist.dev/e/20100916125751.163d8691%40jk.gs In-Reply-To: <20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de> ``` Christian Stimming wrote: > As you might guess, as the (initial) translator of git-gui I've been > through this discussion before [1] and as you have noticed, I have > decided to take a translation approach different from what you have > recently discussed here. I deliberately tried to translate as much > of the terms into German as possible. I do not agree about the > importance of statements on this mailing list like "This translation > translates too much terms - I cannot find the commands I'm used to". > The point of a translation is to enable the usage of a program to > people who do *not* know the original language. Please explain how translating all terms makes it easier for Germans to work with git. As far as I am concerned, all the terms you tried so hard to translate are technical terms, i.e. their full meaning cannot be readily understood without an explanation. That is the reason why we have a glossary for those terms even in the English original. Translating these terms into German does not change anything about that. All terms still need to be explained. There is some slight potential gain in that perhaps *some* translated words will be more easily associated with their corresponding explanations due to the imagery they use, but at the same time there is a cost. I have never met anyone with experience with revision control who used Germanized technical terms. If you never introduce new folks to the terms that are actually used, they are in for a whole world of communication problems. There has always been opposition to borrowing words from other languages, but it's the way language develops. Nobody says "Haareschneider" or "Senf-Eier-Paste" or "dünne Nudelteigfäden". Nobody says "Kompaktscheibe" or "Systemstartverwalter" or "grafisches Dokumentabtastgerät". If I used those words out of the conviction that rigorously translating everything is a good thing, people who have difficulty understanding me if I casually used some of those (and I can think of lots more). I don't actually think that translating words is bad, but I'd rather keep the original word than translate it to something that either doesn't map to the concept half as well or something that is simply extremely unwieldy. There are quite a few examples in the git-gui translation that I consider extremely unwieldy, and in my initial translation of git itself I tried very hard to avoid translations like "Bereitstellung (zum Eintragen)", where I have absolutely no idea what that is supposed to mean. I don't want to turn this into a critique of git-gui's translation, though. > [...] a translation is for people who do neither know nor understand > the English wording for the git concepts. Yes, but when you are first introduced to the words as an English speaker, you don't understand the concepts either. This part of the learning curve cannot be eliminated. > Wikipedia is a bad reference for measuring the importance of certain > things. I (or you) could have easily adapted that article to my > point of view before continuing the discussion. But neither of us have, right? We're adults, after all. You're free to assume that Wikipedia doesn't reflect some kind of social consensus. I do assume that, moreso than I assume that Wikipedia is accurate. > However, in this particular case that article doesn't even mention > many of the terms which need to be discussed in a git glossary. Of course not... but it reflects a tendency for terms to not be translated. > > branch Branch (m.) > > I'd go for "Zweig". It's even on the wikipedia page and it perfectly > represents the concept. My main reason for not translating this one is that we have a command called "branch" and since people need to learn what it means anyway, and we're certainly not going to change the command names in different languages, translating the term in other uses just means that German users have to remember two different words for the same thing. Similar reasoning applies to some other terms. > > index Index > > I'd strongly vote for not using "Index". The "Index" is where the > "Bundesprüfstelle für jugendgefährdende Schriften" puts the > Ballerspiele on. Don't let the identical word fool you into thinking > this is a worthwhile translation. Also, the English term is a bad > naming anyway IMHO. I'd use git-gui's replacement (staging area) and > use "Bereitstellung" here as well. Feel free to propose something > different, but please not "Index". Git isn't FSK18. So we should strike the word "Index" from casual and professional usage when referring to the reference section of a book? > > > commit (noun, verb) Commit/committen > > That's a hard one. It sounds terrible to use "committen" in German. True, but it beats the alternatives. I seriously can't think of any German word that is equivalent to "commit" in the sense that we use it; neither verb nor noun form. The command name reasoning applies here, too. > > revision Revision > > Die "Revision" kommt ins Haus, um die Bücher zu prüfen. Honestly, > please don't use that word in German. Why not "Version"? Sure, why not... though there are a *lot* of other meanings for the word in German. > > tag Tag > > Der heutige Tag oder der morgige Tag? What's the problem with > "Markierung"? This is exactky the git concept which is meant. I believe that the English "tag" is a much better metaphor than the German "Markierung". One use of "tag" refers to a small label that is attached to, for example, baggage. This is exactly the concept we have in git. "Markierung" doesn't come close at all to describing the same concept. Conflicts markers are "Markierungen"; tags are not. The command name reasoning applies here, too. > > tree Tree > > I would not understand what the "Tree" in German should be. Any > German word instead? Okay, fair enough. Anyway, to conclude: I appreciate the feedback, but I think translating all words is not as conducive to making git accessible to Germans as you think. -Jan ``` ## Ævar Arnfjörð Bjarmason, 2010-09-16 11:09 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: URL: https://gitlist.dev/e/AANLkTikvW%3DYY2X9VR8oS2pk3fs9KFkQ_O7m%3DzOEN4nEk%40mail.gmail.com In-Reply-To: <20100916125751.163d8691@jk.gs> ``` On Thu, Sep 16, 2010 at 10:57, Jan Krüger wrote: > My main reason for not translating this one is that we have a command > called "branch" and since people need to learn what it means anyway, > and we're certainly not going to change the command names in different > languages [...] "Markierung" doesn't come close at all to describing the same > concept. Conflicts markers are "Markierungen"; tags are not. > The command name reasoning applies here, too. FWIW we could translate the command names if we wanted to, but whether to do that or not is something we'll have to look at in due time. ``` ## Jens Lehmann, 2010-09-16 11:29 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <4C91FF90.6050902@web.de> URL: https://gitlist.dev/e/4C91FF90.6050902%40web.de In-Reply-To: ``` Am 16.09.2010 13:09, schrieb Ævar Arnfjörð Bjarmason: > On Thu, Sep 16, 2010 at 10:57, Jan Krüger wrote: > >> My main reason for not translating this one is that we have a command >> called "branch" and since people need to learn what it means anyway, >> and we're certainly not going to change the command names in different >> languages [...] "Markierung" doesn't come close at all to describing the same >> concept. Conflicts markers are "Markierungen"; tags are not. >> The command name reasoning applies here, too. > > FWIW we could translate the command names if we wanted to, but whether > to do that or not is something we'll have to look at in due time. Are you seriously thinking about translating the "git branch" command into "git zweig"??? Locale-specific batch files should be real fun ... ``` ## Ævar Arnfjörð Bjarmason, 2010-09-16 11:51 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: URL: https://gitlist.dev/e/AANLkTi%3DD1%2BDQ%3DJXBrWmf142dqTPhQbSa0hw%3Dj8TLrGVX%40mail.gmail.com In-Reply-To: <4C91FF90.6050902@web.de> ``` On Thu, Sep 16, 2010 at 11:29, Jens Lehmann wrote: > Am 16.09.2010 13:09, schrieb Ævar Arnfjörð Bjarmason: >> On Thu, Sep 16, 2010 at 10:57, Jan Krüger wrote: >> >>> My main reason for not translating this one is that we have a command >>> called "branch" and since people need to learn what it means anyway, >>> and we're certainly not going to change the command names in different >>> languages [...] "Markierung" doesn't come close at all to describing the same >>> concept. Conflicts markers are "Markierungen"; tags are not. >>> The command name reasoning applies here, too. >> >> FWIW we could translate the command names if we wanted to, but whether >> to do that or not is something we'll have to look at in due time. > > Are you seriously thinking about translating the "git branch" command > into "git zweig"??? I am. I don't think we should do it, I'm just saying we can. char *allowed_names[] = { "branch", _("branch"), NULL }; Right now we only talk to the user in their native language, but we could extend that so that the user can also talk to us. > Locale-specific batch files should be real fun ... We'd only translate the porcelain commands, and document that using the translated versions anywhere but interactively on the command-line is a bad idea. But to re-iterate, I'm not saying we should do it, just that it would be easy to add it if we want to, and it would presumably be easier to use a translated git in if we did this. ``` ## Michael J Gruber, 2010-09-16 11:51 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <4C9204BE.800@drmicha.warpmail.net> URL: https://gitlist.dev/e/4C9204BE.800%40drmicha.warpmail.net In-Reply-To: <20100916125751.163d8691@jk.gs> ``` Jan Krüger venit, vidit, dixit 16.09.2010 12:57: > Christian Stimming wrote: > >> As you might guess, as the (initial) translator of git-gui I've been >> through this discussion before [1] and as you have noticed, I have >> decided to take a translation approach different from what you have >> recently discussed here. I deliberately tried to translate as much >> of the terms into German as possible. I do not agree about the >> importance of statements on this mailing list like "This translation >> translates too much terms - I cannot find the commands I'm used to". >> The point of a translation is to enable the usage of a program to >> people who do *not* know the original language. > > Please explain how translating all terms makes it easier for Germans to > work with git. As far as I am concerned, all the terms you tried so > hard to translate are technical terms, i.e. their full meaning cannot be > readily understood without an explanation. That is the reason why we > have a glossary for those terms even in the English original. > > Translating these terms into German does not change anything about > that. All terms still need to be explained. Absolutely true, and absolutely irrelevant for the decision whether to translate these, since they need to be explained in any case. > > There is some slight potential gain in that perhaps *some* translated > words will be more easily associated with their corresponding > explanations due to the imagery they use, The aim of a good translation is to reproduce the concept, not the word. I assume we're talking about a (mostly) non-English speaking target audience here, and for them associating meaning with terms in their native language is certainly easier. ... > There are quite a few examples in the git-gui translation that I > consider extremely unwieldy, and in my initial translation of git > itself I tried very hard to avoid translations like "Bereitstellung > (zum Eintragen)", where I have absolutely no idea what that is supposed > to mean. I don't want to turn this into a critique of git-gui's > translation, though. [For the record, I don't like that translation either.] >> I'd go for "Zweig". It's even on the wikipedia page and it perfectly >> represents the concept. > > My main reason for not translating this one is that we have a command > called "branch" and since people need to learn what it means anyway, > and we're certainly not going to change the command names in different > languages, translating the term in other uses just means that German > users have to remember two different words for the same thing. Similar > reasoning applies to some other terms. I really have to oppose this reasoning. Are you seriously suggesting we should not translate the following words as a matter of principle? add am (OK, I'm kidding here) annotate apply archive bisect blame branch bundle cat (...) check checkout cherry(-pick) clean clone commit config count daemon describe diff fast fetch filter for format get grep gui hash help index init log lost mailinfo mailsplit merge mergetool name notes pack parse patch peek prune pull push read rebase receive reflog relink remote repack replace repo request reset revert rev send shell shortlog show stage stash status submodule symbolic tag tar unpack update upload var verify web write We simply need a principle we can follow, which produces readable text, and which helps those in need of a translation. Those with a reasonable passive understanding of English don't need a translation at all. Some suggestions to follow: - Identify term categories which are already in use in the English version, such as "combinatorial graphs". - Within each category, look for established translations in that field; in any case, keep the categorical associations for the translation. - Translate concepts, not words. If there are several choices, favour the one which is linguistically close to the English Git glossary. There's a good chance this will happen quite often with German. >>> tag Tag >> >> Der heutige Tag oder der morgige Tag? What's the problem with >> "Markierung"? This is exactky the git concept which is meant. > > I believe that the English "tag" is a much better metaphor than the > German "Markierung". One use of "tag" refers to a small label that is > attached to, for example, baggage. This is exactly the concept we have > in git. "Markierung" doesn't come close at all to describing the same > concept. Conflicts markers are "Markierungen"; tags are not. That's exactly why I suggested "Marke", see my earlier reply also for the other terms. It conveys the same multiple metaphorical associations. You know, there's a reason why translating is a profession. You need to be proficient in both languages, as well as creative. In fact, I don't think the majority of people are proficient enough for that even in their native language (as a translation target), but every native speaker thinks he or she is, of course. (This is a general remark not aimed at anyone specifically.) Michael ``` ## Junio C Hamano, 2010-09-16 14:52 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <7vsk194u6v.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsk194u6v.fsf%40alter.siamese.dyndns.org In-Reply-To: <4C91FF90.6050902@web.de> ``` Jens Lehmann writes: > Am 16.09.2010 13:09, schrieb Ævar Arnfjörð Bjarmason: >> On Thu, Sep 16, 2010 at 10:57, Jan Krüger wrote: >> >>> My main reason for not translating this one is that we have a command >>> called "branch" and since people need to learn what it means anyway, >>> and we're certainly not going to change the command names in different >>> languages [...] "Markierung" doesn't come close at all to describing the same >>> concept. Conflicts markers are "Markierungen"; tags are not. >>> The command name reasoning applies here, too. >> >> FWIW we could translate the command names if we wanted to, but whether >> to do that or not is something we'll have to look at in due time. > > Are you seriously thinking about translating the "git branch" command > into "git zweig"??? Locale-specific batch files should be real fun ... Perhaps "dumme zweig"? IOW, shouldn't "git" itself be translated in such a case? People, please stop being ridiculous. ``` ## Jens Lehmann, 2010-09-16 15:05 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <4C92323B.40307@web.de> URL: https://gitlist.dev/e/4C92323B.40307%40web.de In-Reply-To: <7vsk194u6v.fsf@alter.siamese.dyndns.org> ``` Am 16.09.2010 16:52, schrieb Junio C Hamano: > Jens Lehmann writes: >> Are you seriously thinking about translating the "git branch" command >> into "git zweig"??? Locale-specific batch files should be real fun ... > > Perhaps "dumme zweig"? IOW, shouldn't "git" itself be translated in such > a case? > > People, please stop being ridiculous. Yup, and just in case people misunderstood me: I was being sarcastic. ``` ## Jan Krüger, 2010-09-16 16:48 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <20100916184803.39576fd2@jk.gs> URL: https://gitlist.dev/e/20100916184803.39576fd2%40jk.gs In-Reply-To: <4C9204BE.800@drmicha.warpmail.net> ``` Michael J Gruber wrote: > > Translating these terms into German does not change anything about > > that. All terms still need to be explained. > > Absolutely true, and absolutely irrelevant for the decision whether to > translate these, since they need to be explained in any case. The argument for translating them in the first place was that that makes it easier to understand the text. My argument was that the translated terms are not more understandable because they still need to be explained. How is that irrelevant? I consider the original argument refuted, and unless you have a different argument for translating them, I will continue to translate terms only if I find a reasonable equivalent in German. > The aim of a good translation is to reproduce the concept, not the > word. I assume we're talking about a (mostly) non-English speaking > target audience here, and for them associating meaning with terms in > their native language is certainly easier. I have not seen a whole lot of good translations, though. Most of them don't represent the original concept nearly as well as the original word. Most of the time the metaphorical expressiveness is worlds apart. > >> I'd go for "Zweig". It's even on the wikipedia page and it > >> perfectly represents the concept. > > > > My main reason for not translating this one is that we have a > > command called "branch" and since people need to learn what it > > means anyway, and we're certainly not going to change the command > > names in different languages, translating the term in other uses > > just means that German users have to remember two different words > > for the same thing. Similar reasoning applies to some other terms. > > I really have to oppose this reasoning. Are you seriously suggesting > we should not translate the following words as a matter of principle? I would indeed keep quite a few of them as they are. But you're right, the fact that they would likely be kept as command names just makes me feel better about keeping them untranslated; the main reason is that I can't find good translations. Let's step through them one by one, against my better judgement. > add This one is straightforward enough, I have to admit. "Hinzufügen" is exactly the concept we're looking for here. > am (OK, I'm kidding here) "pa" für "Postfach anwenden"? ;) > apply I believe that "anwenden" is indeed frequently used in this context. > archive There exists an exactly equivalent word in German, so that's wonderful. > bisect This will be translated to "halbieren" over my cold, dead body. > blame Can't think of anything right now, but my intuition says that this can be translated gracefully; perhaps not in one word, but who cares. > branch I actually think that "Zweig" is not a perfect translation here. "Zweig" is commonly used in the context of describing trees. The git history is not in tree form, though. Instead, I think the concept of a branch in the road is a better fit; it's natural for a road to branch off and later rejoin whatever road it branched off of. A translation of that might be "Abzweig", but I would prefer a word that doesn't currently sound stilted. > bundle I'd argue that the word "Bundle" is already used in German technical lingo. > cat (...) Those (and some others in your list) tend to be plumbing commands. I don't think we need to think about them quite as hard as about porcelain. > checkout There is no good equivalent in German (that I know of). Actually the original term is not very good in the first place. It seems to be using borrowing "checkout" in the sense as used in, for example, a library. (Actually, "auschecken" exists (listed in my dictionary of choice, at least) and is probably close enough...) > cherry(-pick) This is a tricky one. "Pflücken" is certainly not an ideal translation; "herauspicken" is closer but a bit awkward to integrate into a sentence. > clean Straightforward translation: "aufräumen". > clone German equivalent exists: "klonen/Klon". > commit This is about the most complicated term there is. This word unites so many meanings it's not even funny. The most relevant ones which I see reflected in git are: - commit to memory - commit to a decision - commit someone to a mental institution (and aren't there enough commits where you feel a bit like that?) - commit a crime Note that I'm just using these as examples of what "commit" can mean, and I see all of these meanings reflected in git's usage in one way or another. Now try and find a German word that has the same kind of overall meaning. I'll wait. Another important reason why I really wouldn't change this one ("Commit/committen") is that it's widely used like that in German already. By introducing new users to some kind of Germanized metaphor, you end up creating a communication barrier between existing experts and new users. I think that should be avoided at all costs. This is also the reason why I oppose the argument that a translation should exclusively cater to new users who don't speak English. I believe that the meaning of translation should at least be easily apparent to existing German users. The example "Bereitstellung (zum Eintragen)" that I already gave from git-gui shows how not to do that. It took me at least a minute to figure out what that meant. People who don't share my point of view have not responded to this argument so far, but I believe that it's crucially important. > config > count > describe Straightforward. > daemon I wouldn't translate this one. It's a crafted word; there's no reason to replace it with a non-crafted word in German. Also it's commonly used by German UNIX experts anyway. > diff The whole point of this word is to be short. It's close enough to the German "Differenz" that I would keep it, even as a verb ("diffen"). Again, this form is crafted anyway. (No, it's not okay to call it "differenzieren". You'll drive math folks to homicide if you do that. ;)) > fetch I already translated this one. > filter The German word is the same. > format Again, this is difficult. In prose I would just call it "Patch erstellen". > grep Another crafted word. I'd keep it. Any UNIX user will know it anyway. > gui Nobody ever translates this acronym. > hash "Hash" is a widely used technical term in German. > help > index > init Straightforward. > log "Protokoll" seems a bit cumbersome but is close enough to the original concept. > lost I'm beginning to figure out how you generated this list... > merge Again, there is no real equivalent in German. I would be all in favour of going with a more elaborate translation if that wouldn't make certain things extremely convoluted ("Zusammenführungscommit"?). > name Did you even read this part of your mail? ;) > notes Straightforward. > pack Less so. Used as a noun, most straightforward translations will clash with "archive" or "repository" or whatever. "Paket" clashes with its usual meaning of "packet", especially in contexts like "receive pack". I would really like to translate this one (it seems like it shouldn't be too hard), but I don't have any decent ideas. > patch Customarily used in German. > pull Another tricky one. I haven't quite decided yet whether "ziehen" is an accurate translation. I'd probably try to cheat by rephrasing sentences that use this word. > push Same thing. > rebase Tricky. This is another crafted word. I believe the best chance of doing it justice would be in crafting a word with a German base that's very similar to this. Lacking of a good solution, I'd keep the original word. > reflog Another crafted one. Developers tend to know the term "log", so I'd keep this one, especially since it'll be hard to find something else that can be shortened this much. > remote I haven't translated this one yet. I guess it would map nicely to "extern", though then we'd lose the noun meaning of the original. > reset Straightforward, though "reset" doesn't really describe very well what it does in the first place. > revert Literally translating this one out of the dictionary will end up being incorrect. "Zurücknehmen" would be closer. > rev Christian's "Versionsangabe" seems like a good fit. > show Straightforward. > stage I translated this to "vormerken". > stash Tricky. Since some of the original git lingo is fairly casual, though, I might go with "bunkern". And if anyone complains about connotations of war, I'll scream. > status Used in German. > submodule I certainly don't have any good idea here. > We simply need a principle we can follow, which produces readable > text, and which helps those in need of a translation. Those with a > reasonable passive understanding of English don't need a translation > at all. Some suggestions to follow: > > - Identify term categories which are already in use in the English > version, such as "combinatorial graphs". We usually use only a very small part of each taxonomy (see, for example, the word "branch" which is *not* used by us as it is in graph theory), so this doesn't help as much as it might seem. I agree that reusing well-established translated taxonomies is a good thing, though. > - Translate concepts, not words. If there are several choices, favour > the one which is linguistically close to the English Git glossary. I agree with this too, as long as it's done *well*. That includes setting a "maximum distance" between the original and the translations. A rough fit (e.g. commit <-> eintragen, stage <-> bereitstellen and many others) should be rejected as not really making things better. > > I believe that the English "tag" is a much better metaphor than the > > German "Markierung". One use of "tag" refers to a small label that > > is attached to, for example, baggage. This is exactly the concept > > we have in git. "Markierung" doesn't come close at all to > > describing the same concept. Conflicts markers are "Markierungen"; > > tags are not. > > That's exactly why I suggested "Marke", see my earlier reply also for > the other terms. It conveys the same multiple metaphorical > associations. I disagree. Arguably, the strongest association is "Briefmarke" (postage stamp), probably followed by "Erkennungsmarke/Markenzeichen" (trademark) and perhaps "Plakette" (insignia). None of these reflect what a "tag" is about: (more or less) loosely attaching an identifier to a revision, as in the case of a baggage tag or a dog tag. What's more, the word "Tag" is already widely used in German version control lingo. For example, the German translation of the SVN red book uses it. > You know, there's a reason why translating is a profession. You need > to be proficient in both languages, as well as creative. In fact, I > don't think the majority of people are proficient enough for that > even in their native language (as a translation target), but every > native speaker thinks he or she is, of course. (This is a general > remark not aimed at anyone specifically.) The whole profession argument has never sat well with me. I know hobbyists who have ten times the skills of some professionals. I agree that translating is a nontrivial task, though... and I, personally, will not be involved in anything less than a very good translation. I have outlined what I perceive as shortcomings in a number of suggestions made here. I'll be glad to look at alternative suggestions, but so far, for a number of terms, I haven't seen a satisfactory alternative to adopting the English ones. (FWIW, I've bounced some of the more controversial of my translations off a couple of git users, but also off a graduate of German language and literature studies who uses neither git nor English. I'm just mentioning that due to your totally-not-aimed-at-anyone remark, though; I don't think it should actually make any difference.) At any rate, I will stop working on translating git as long as this discussion goes on. And, of course, should you guys end up insisting on bad translations, I'll leave you to writing it that way. Under protest. :) -Jan ``` ## Michael J Gruber, 2010-09-17 07:23 Subject: Re: [PATCH 1/2] po/de.po: add German translation Message-ID: <4C931774.9060808@drmicha.warpmail.net> URL: https://gitlist.dev/e/4C931774.9060808%40drmicha.warpmail.net In-Reply-To: <20100916184803.39576fd2@jk.gs> ``` [snipping most parts to make this shorter] Jan Krüger venit, vidit, dixit 16.09.2010 18:48: > Michael J Gruber wrote: > >>> Translating these terms into German does not change anything about >>> that. All terms still need to be explained. >> >> Absolutely true, and absolutely irrelevant for the decision whether to >> translate these, since they need to be explained in any case. > > The argument for translating them in the first place was that that > makes it easier to understand the text. My argument was that the > translated terms are not more understandable because they still need to > be explained. How is that irrelevant? I consider the original argument If it makes no difference then it is irrelevant for the decision. It's neither pro nor con, other arguments have to be brought up. >> I really have to oppose this reasoning. Are you seriously suggesting >> we should not translate the following words as a matter of principle? > > I would indeed keep quite a few of them as they are. But you're > right, the fact that they would likely be kept as command names just > makes me feel better about keeping them untranslated; the main reason > is that I can't find good translations. Let's step through them one > by one, against my better judgement. This was not meant as a list to be worked through, but as an argument that the principle "do not translate command names at all" (i.e. in *no* context) is not viable. >>> I believe that the English "tag" is a much better metaphor than the >>> German "Markierung". One use of "tag" refers to a small label that >>> is attached to, for example, baggage. This is exactly the concept >>> we have in git. "Markierung" doesn't come close at all to >>> describing the same concept. Conflicts markers are "Markierungen"; >>> tags are not. >> >> That's exactly why I suggested "Marke", see my earlier reply also for >> the other terms. It conveys the same multiple metaphorical >> associations. > > I disagree. Arguably, the strongest association is > "Briefmarke" (postage stamp), probably followed by > "Erkennungsmarke/Markenzeichen" (trademark) and perhaps > "Plakette" (insignia). None of these reflect what a "tag" is about: > (more or less) loosely attaching an identifier to a revision, as in the > case of a baggage tag or a dog tag. What's more, the word "Tag" is dog tag is Hundemarke. I really think Marke conveys most meanings of tag, especially those relevant to the meaning of tag in Git context. If you insist on translating all aspects and connotations of a word then there is no translation at all. > already widely used in German version control lingo. For example, the > German translation of the SVN red book uses it. > >> You know, there's a reason why translating is a profession. You need >> to be proficient in both languages, as well as creative. In fact, I >> don't think the majority of people are proficient enough for that >> even in their native language (as a translation target), but every >> native speaker thinks he or she is, of course. (This is a general >> remark not aimed at anyone specifically.) > > The whole profession argument has never sat well with me. I know > hobbyists who have ten times the skills of some professionals. I agree I talked about "profession", not about hobbyists vs. professionals. And I don't like it when you turn around my words in my mouth. > that translating is a nontrivial task, though... and I, personally, > will not be involved in anything less than a very good translation. I > have outlined what I perceive as shortcomings in a number of > suggestions made here. I'll be glad to look at alternative suggestions, > but so far, for a number of terms, I haven't seen a satisfactory > alternative to adopting the English ones. > > (FWIW, I've bounced some of the more controversial of my translations > off a couple of git users, but also off a graduate of German language > and literature studies who uses neither git nor English. I'm just > mentioning that due to your totally-not-aimed-at-anyone remark, though; You can take that for face-value - it was not aimed at anyone, and you have no reason to claim otherwise. > I don't think it should actually make any difference.) > > At any rate, I will stop working on translating git as long as this > discussion goes on. And, of course, should you guys end up insisting on > bad translations, I'll leave you to writing it that way. Under > protest. :) We simply have to decide about a concept, about an approach first, about what is "bad" and what is "good" (for the yet to be determined target audience) as you put it, before flooding the single de.po with translation pieces without an agreement on a glossary for the main terms. But, given the direction this discussion is taking now, I'm really pessimistic that this is going to happen. Maybe switching to DE would help, I dunno. Michael ```