{"thread":{"id":"25107","subject":"Re: [PATCH 1/2] po/de.po: add German translation","startedAt":"2010-09-15T07:33:13Z","lastAt":"2010-09-17T07:23:32Z","messageCount":15,"participants":["Christian Stimming","Thomas Rast","Michael J Gruber","Thomas Hochstein","Andreas Schwab","Jan Krüger","Ævar Arnfjörð Bjarmason","Jens Lehmann","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"150726","messageId":"20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de","threadId":"25107","inReplyTo":null,"subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2010-09-15T07:33:13Z","receivedAt":"2010-09-15T07:33:13Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Dear Thomas, Jan, et al.,\n\nthanks for the discussion of an initial git translation to German. I  \nappreciate the efforts to translate not only the gui tools of git, but  \nalso the command line commands as well. I completely agree with  \nThomas' proposal to discuss and agree on a glossary of terms *first*,  \nand *secondly* preparing the actual translation - otherwise it will be  \nimpossible to create a consistent translation.\n\nAs you might guess, as the (initial) translator of git-gui I've been  \nthrough this discussion before [1] and as you have noticed, I have  \ndecided to take a translation approach different from what you have  \nrecently discussed here. I deliberately tried to translate as much of  \nthe terms into German as possible. I do not agree about the importance  \nof statements on this mailing list like \"This translation translates  \ntoo much terms - I cannot find the commands I'm used to\". The point of  \na translation is to enable the usage of a program to people who do  \n*not* know the original language. This is the target audience. By  \ndefinition, this excludes anyone who participates on *this* mailing  \nlist from the target audience: Obviously you not only speak English  \nvery well, but you are daily familiar with the English git wording for  \nthe concepts inside this VCS. Then let me repeat: A translation is not  \nfor you. You know, the bait and the fisherman and the fish and such.  \nInstead, a translation is for people who do neither know nor  \nunderstand the English wording for the git concepts. For this target  \naudience, the goal is to find a set of terms for the different git  \nconcepts which makes the concepts most easily accessible for their  \nlanguage. This may or may not include terms which are left at English  \nwords.\n\nHaving said that, I would also take the following inspiration with a  \ngrain of salt:\n\n> You said on IRC that you left all English terms that\n> are also used on\n> http://de.wikipedia.org/wiki/Versionskontrolle\n\nWikipedia is a bad reference for measuring the importance of certain  \nthings. I (or you) could have easily adapted that article to my point  \nof view before continuing the discussion. However, in this particular  \ncase that article doesn't even mention many of the terms which need to  \nbe discussed in a git glossary.\n\nHaving said that as well, I admit the translation of the command line  \ntools is somewhat more difficult than a GUI tool, because many of the  \ngit concepts appear as English words in the command itself. Hence, I  \nadmit it is much more difficult to decide on a non-English  \ntranslation, but having to mention the English term all the time  \nbecause that's the command which needs to be used. And for sure we  \nwon't want to translate the (main porcelain) command names. Hence, the  \ndecision on terms which are left in English can surely be decided  \ndifferently here than in the GUI tools.\n\nAfter this introduction, I would like to comment on a few of the  \nproposed German glossary translations; the IMHO easier ones first:\n\n>  branch                Branch (m.)\n\nI'd go for \"Zweig\". It's even on the wikipedia page and it perfectly  \nrepresents the concept.\n\n>  index                 Index\n\nI'd strongly vote for not using \"Index\". The \"Index\" is where the  \n\"Bundesprüfstelle für jugendgefährdende Schriften\" puts the  \nBallerspiele on. Don't let the identical word fool you into thinking  \nthis is a worthwhile translation. Also, the English term is a bad  \nnaming anyway IMHO. I'd use git-gui's replacement (staging area) and  \nuse \"Bereitstellung\" here as well. Feel free to propose something  \ndifferent, but please not \"Index\". Git isn't FSK18.\n\n>  commit (noun, verb)                Commit/committen\n\nThat's a hard one. It sounds terrible to use \"committen\" in German. I  \nwould strongly vote for not using this word directly, but I admit I  \nalso don't have a completely convincing alternative.\n\n>  revision              Revision\n\nDie \"Revision\" kommt ins Haus, um die Bücher zu prüfen. Honestly,  \nplease don't use that word in German. Why not \"Version\"?\n\n>  tag                   Tag\n\nDer heutige Tag oder der morgige Tag? What's the problem with  \n\"Markierung\"? This is exactky the git concept which is meant.\n\n>  tree                  Tree\n\nI would not understand what the \"Tree\" in German should be. Any German  \nword instead?\n\nMany other of the proposals are just fine and very good. Keep up the  \ngood work!\n\nRegards,\n\nChristian Stimming\n\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/58315\n"},{"id":"150727","messageId":"201009151147.45314.trast@student.ethz.ch","threadId":"25107","inReplyTo":"20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-09-15T09:47:44Z","receivedAt":"2010-09-15T09:47:44Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hi Christian\n\nChristian Stimming wrote:\n> \n> As you might guess, as the (initial) translator of git-gui I've been  \n> through this discussion before [1] and as you have noticed, I have  \n> decided to take a translation approach different from what you have  \n> recently discussed here. I deliberately tried to translate as much of  \n> the terms into German as possible. I do not agree about the importance  \n> of statements on this mailing list like \"This translation translates  \n> too much terms - I cannot find the commands I'm used to\". \n[...]\n> Instead, a translation is for people who do neither know nor  \n> understand the English wording for the git concepts. For this target  \n> audience, the goal is to find a set of terms for the different git  \n> concepts which makes the concepts most easily accessible for their  \n> language. This may or may not include terms which are left at English  \n> words.\n\nMaybe there should be two sets of translations then.\n\nI'm only half serious, but the problem here is what I said earlier in\nthe thread (referring to Jan's draft):\n\n} In any case it roughly matches (or still stays slightly on the\n} more-German side of) the colloquial usage in my group, if that is\n} any indication.\n\n\"My group\" is a bunch of CS researchers, so I can't say they fall\noutside the description above.  However, in our work we observe a very\nfunny split between translating and keeping the terms in English:\n\n  graph                               Graph\n  vertex                              Knoten\n  edge                                Kante\n  directed                            gerichtet\n  DAG (directed acyclic graph)        DAG\n  independent set                     independent set\n  cut (vertex, edge)                  cut (vertex, edge)\n  degree                              Grad\n  matching                            Matching\n  tree                                Baum\n  MST (minimum spanning tree)         MST (minimaler Spannbaum)\n\nThere are German terms for all the untranslated ones, but I rarely\nhear them in practical usage.  Books probably go for a full\ntranslation since they want to be normative (how should I know, it's\nbeen a while since I used a German book), but lectures stick to the\nhalf-translated version.\n\nAnd much like the average computer scientist around here uses a number\nof English terms even in German informal speech, I suspect the average\nGerman user of git would not translate *every* term.  Unless you are\naiming for a normative usage, in which case we would also have to\ntranslate the theory (manpages, books) using the same terms...\n\nI'll leave it at that for my $0.02, since as you note, I'm not\nactually the intended audience.\n\nBy the way:\n\n> >  index                 Index\n> \n> I'd strongly vote for not using \"Index\". The \"Index\" is where the  \n> \"Bundesprüfstelle für jugendgefährdende Schriften\" puts the  \n> Ballerspiele on. Don't let the identical word fool you into thinking  \n> this is a worthwhile translation. Also, the English term is a bad  \n> naming anyway IMHO. I'd use git-gui's replacement (staging area) and  \n> use \"Bereitstellung\" here as well. Feel free to propose something  \n> different, but please not \"Index\". Git isn't FSK18.\n\nI guess I will have to go for a de_CH translation then.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"150729","messageId":"4C90A9A2.5050705@drmicha.warpmail.net","threadId":"25107","inReplyTo":"20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-15T11:10:26Z","receivedAt":"2010-09-15T11:10:26Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Christian Stimming venit, vidit, dixit 15.09.2010 09:33:\n> Dear Thomas, Jan, et al.,\n> \n> thanks for the discussion of an initial git translation to German. I  \n> appreciate the efforts to translate not only the gui tools of git, but  \n> also the command line commands as well. I completely agree with  \n> Thomas' proposal to discuss and agree on a glossary of terms *first*,  \n> and *secondly* preparing the actual translation - otherwise it will be  \n> impossible to create a consistent translation.\n\nI've been holding back a post titled \"Halt the l10n madness\" in my\nmental drafts folder for a while, and I'm happy the issue has been\nraised now. I guess I'm not the only one passing (out) on seeing \"PATCH\n0/159\"...\n\nI totally agree on the glossary first approach. I'm just seeing that the\nactual translations do not undergo much discussion, and I hope that it\nwould be different for a glossary.\n\n\n>>  branch                Branch (m.)\n> \n> I'd go for \"Zweig\". It's even on the wikipedia page and it perfectly  \n> represents the concept.\n\n+1\n\nZweig, of course, what else? :)\n\nThe main abstract concept underlying not only Git's revision control is\nthat of a direct acylcic graph (DAG). There are established translations\nfor that concept in combinatorics, which we should follow.\n\n> \n>>  index                 Index\n> \n> I'd strongly vote for not using \"Index\". The \"Index\" is where the  \n> \"Bundesprüfstelle für jugendgefährdende Schriften\" puts the  \n> Ballerspiele on. Don't let the identical word fool you into thinking  \n> this is a worthwhile translation. Also, the English term is a bad  \n> naming anyway IMHO. I'd use git-gui's replacement (staging area) and  \n> use \"Bereitstellung\" here as well. Feel free to propose something  \n> different, but please not \"Index\". Git isn't FSK18.\n\nThis reasoning - while certainly entertaining - reflects a very limited\nview on German vocabulary. I don't think the Bundesprüfstelle has been\naround in the 19th century when (or earlier) this word made it into the\nGerman language.\n\nIn fact, \"Index\" is a \"Verzeichnis\" (in the sense of registry), and its\nlatin root \"indicare\" which resonates in the original meaning of the\nGerman \"Index\" (announce, make known, indicate) makes it the perfect\ntranslation of the word \"index\" as we use it in Git.\n\n\"Register\" would also make sense, but whenever there is a German word\nwith the same root (index/Index) which is not a \"false friend\" we should\ngo for that.\n\nNote that we should not overemphasise the issue of connotations, or Git\nshould really be FSK16, i.e. PG or stricter - I mean, Git's idea of the\nresult of \"committing is\n\n1 files changed, 1 insertions(+), 0 deletions(-)\n\nMakes you think differently about \"commit early, commit often.\" ;)\n\n\n> \n>>  commit (noun, verb)                Commit/committen\n> \n> That's a hard one. It sounds terrible to use \"committen\" in German. I  \n> would strongly vote for not using this word directly, but I admit I  \n> also don't have a completely convincing alternative.\n\n\"Eintrag\", \"eintragen\"\n\nHere, Git itself leaves the picture of trees and DAGs (or else a commit\nwould be a vertex or node).\n\n> \n>>  revision              Revision\n> \n> Die \"Revision\" kommt ins Haus, um die Bücher zu prüfen. Honestly,  \n> please don't use that word in German. Why not \"Version\"?\n\n+1\nAgain, that reflects a limited view of the use of \"Revision\", but I have\nno objection against \"Version\". Even our existing glossary says that a\n\"revision\" is what other scms call a \"version\".\n\n> \n>>  tag                   Tag\n> \n> Der heutige Tag oder der morgige Tag? What's the problem with  \n> \"Markierung\"? This is exactky the git concept which is meant.\n\n\"Markierung\" is OK, but I'd go for the shorter \"Marke\" as in \"Marke\nsetzen\" etc. Even the connotation with \"Briefmarke\" is beneficial, as\nyou tag something by putting a label on it, just like a stamp.\n\n> \n>>  tree                  Tree\n> \n> I would not understand what the \"Tree\" in German should be. Any German  \n> word instead?\n\n\"Baum\"! It's the combinatorics term for an undirected acyclic graph,\nit's the literal translation, and it's established also in the context\nwhere we mostly use it in Git: \"Verzeichnisbaum\" (directory tree)\n\n> \n> Many other of the proposals are just fine and very good. Keep up the  \n> good work!\n\nI guess I'll have to revisit that, it was probably among some 159\npatches or so I marked read in one thread...\n\nCheers/Tschüß,\nMichael\n"},{"id":"150734","messageId":"gcvg.1009151344.2868@thorondor.akallabeth.de","threadId":"25107","inReplyTo":"20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Thomas Hochstein","fromEmail":"thh@inter.net","sentAt":"2010-09-15T11:44:48Z","receivedAt":"2010-09-15T11:44:48Z","isPatch":true,"sender":{"key":"thh@inter.net","avatar":"https://avatars.githubusercontent.com/u/365129?v=4"},"body":"Christian Stimming schrieb:\n\n>  I do not agree about the importance  \n> of statements on this mailing list like \"This translation translates  \n> too much terms - I cannot find the commands I'm used to\". The point of  \n> a translation is to enable the usage of a program to people who do  \n> *not* know the original language. This is the target audience. \n\nI don't agree. I prefer to use localized/translated software [1], even\nthough I'm able to speak English, because it's just easier to use, but\nI strongly consider translated technical terms nearly unusable - you\nlose a common base for communication with other people and you can't\nuse most documentation any longer as it'll be in English or at least\nuse the original, non-translated technical terms. So I think the\ntarget audience for a German translation is neither only nor primarily\npeople not understanding English [2] but all those who do speak\nEnglish but prefer a localized environment.\n\nDon't let us get back to the times where a \"computer\" was a\n\"Rechenmaschine\", the CPU a \"Zentralrecheneinheit\" or email\n\"elektronische Post\" ...\n\n-thh\n\n[1] And German translations of books, movies etc. - mostly, that is.\n[2] You won't get far in IT if you're not able to understand at least\nsome English, I think.\n"},{"id":"150733","messageId":"4C90B344.6060002@drmicha.warpmail.net","threadId":"25107","inReplyTo":"201009151147.45314.trast@student.ethz.ch","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-15T11:51:32Z","receivedAt":"2010-09-15T11:51:32Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Thomas Rast venit, vidit, dixit 15.09.2010 11:47:\n> Hi Christian\n> \n> Christian Stimming wrote:\n>>\n>> As you might guess, as the (initial) translator of git-gui I've been  \n>> through this discussion before [1] and as you have noticed, I have  \n>> decided to take a translation approach different from what you have  \n>> recently discussed here. I deliberately tried to translate as much of  \n>> the terms into German as possible. I do not agree about the importance  \n>> of statements on this mailing list like \"This translation translates  \n>> too much terms - I cannot find the commands I'm used to\". \n> [...]\n>> Instead, a translation is for people who do neither know nor  \n>> understand the English wording for the git concepts. For this target  \n>> audience, the goal is to find a set of terms for the different git  \n>> concepts which makes the concepts most easily accessible for their  \n>> language. This may or may not include terms which are left at English  \n>> words.\n> \n> Maybe there should be two sets of translations then.\n> \n> I'm only half serious, but the problem here is what I said earlier in\n> the thread (referring to Jan's draft):\n> \n> } In any case it roughly matches (or still stays slightly on the\n> } more-German side of) the colloquial usage in my group, if that is\n> } any indication.\n> \n> \"My group\" is a bunch of CS researchers, so I can't say they fall\n> outside the description above.  However, in our work we observe a very\n> funny split between translating and keeping the terms in English:\n> \n>   graph                               Graph\n>   vertex                              Knoten\n>   edge                                Kante\n>   directed                            gerichtet\n>   DAG (directed acyclic graph)        DAG\n>   independent set                     independent set\n>   cut (vertex, edge)                  cut (vertex, edge)\n>   degree                              Grad\n>   matching                            Matching\n>   tree                                Baum\n>   MST (minimum spanning tree)         MST (minimaler Spannbaum)\n> \n> There are German terms for all the untranslated ones, but I rarely\n> hear them in practical usage.  Books probably go for a full\n> translation since they want to be normative (how should I know, it's\n> been a while since I used a German book), but lectures stick to the\n> half-translated version.\n\nAny active graduate student or researcher is used to English articles\nand books and doesn't need a translation at all, or could do completely\nwith a translated glossary.\n\nI assume we do the (extensive!) translation work for people who could\nnot use Git without a translation. And that mandates translating as much\nas possible (including man pages...).\n\nAs far as the various disciplines go, CS is always on the side of\nimporting more terms from English rather than translating. If we agree\nthat a group of CS researchers is the target I'm fine with it - but it\nwould imply backing out l10n ;)\n\nNote that I don't want to create any bad feelings against the l10n\nefforts. If it is done then I want it to be done right and not rushed, a\nbad one does more harm than anything. I probably won't be contributing\nto translations of commands, but I'm in for the glossary to help it have\na sound start.\n\nMichael\n"},{"id":"150740","messageId":"m2fwxb6j6r.fsf@igel.home","threadId":"25107","inReplyTo":"4C90A9A2.5050705@drmicha.warpmail.net","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-09-15T16:54:52Z","receivedAt":"2010-09-15T16:54:52Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> Christian Stimming venit, vidit, dixit 15.09.2010 09:33:\n>> \n>>>  revision              Revision\n>> \n>> Die \"Revision\" kommt ins Haus, um die Bücher zu prüfen. Honestly,  \n>> please don't use that word in German. Why not \"Version\"?\n>\n> +1\n> Again, that reflects a limited view of the use of \"Revision\", but I have\n> no objection against \"Version\". Even our existing glossary says that a\n> \"revision\" is what other scms call a \"version\".\n\nA more literal translation would be \"Änderung\", which I think isn't all\nthat bad.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"150810","messageId":"20100916125751.163d8691@jk.gs","threadId":"25107","inReplyTo":"20100915093313.44396t6yr62ixccg@webmail.tu-harburg.de","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2010-09-16T10:57:51Z","receivedAt":"2010-09-16T10:57:51Z","isPatch":true,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Christian Stimming <stimming@tuhh.de> wrote:\n\n> As you might guess, as the (initial) translator of git-gui I've been  \n> through this discussion before [1] and as you have noticed, I have  \n> decided to take a translation approach different from what you have  \n> recently discussed here. I deliberately tried to translate as much\n> of the terms into German as possible. I do not agree about the\n> importance of statements on this mailing list like \"This translation\n> translates too much terms - I cannot find the commands I'm used to\".\n> The point of a translation is to enable the usage of a program to\n> people who do *not* know the original language.\n\nPlease explain how translating all terms makes it easier for Germans to\nwork with git. As far as I am concerned, all the terms you tried so\nhard to translate are technical terms, i.e. their full meaning cannot be\nreadily understood without an explanation. That is the reason why we\nhave a glossary for those terms even in the English original.\n\nTranslating these terms into German does not change anything about\nthat. All terms still need to be explained.\n\nThere is some slight potential gain in that perhaps *some* translated\nwords will be more easily associated with their corresponding\nexplanations due to the imagery they use, but at the same time there is\na cost. I have never met anyone with experience with revision control\nwho used Germanized technical terms. If you never introduce new folks\nto the terms that are actually used, they are in for a whole world of\ncommunication problems.\n\nThere has always been opposition to borrowing words from other\nlanguages, but it's the way language develops. Nobody says\n\"Haareschneider\" or \"Senf-Eier-Paste\" or \"dünne Nudelteigfäden\". Nobody\nsays \"Kompaktscheibe\" or \"Systemstartverwalter\" or\n\"grafisches Dokumentabtastgerät\". If I used those words out of the\nconviction that rigorously translating everything is a good thing,\npeople who have difficulty understanding me if I casually used some of\nthose (and I can think of lots more).\n\nI don't actually think that translating words is bad, but I'd rather\nkeep the original word than translate it to something that either\ndoesn't map to the concept half as well or something that is simply\nextremely unwieldy.\n\nThere are quite a few examples in the git-gui translation that I\nconsider extremely unwieldy, and in my initial translation of git\nitself I tried very hard to avoid translations like \"Bereitstellung\n(zum Eintragen)\", where I have absolutely no idea what that is supposed\nto mean. I don't want to turn this into a critique of git-gui's\ntranslation, though. \n\n> [...] a translation is for people who do neither know nor understand\n> the English wording for the git concepts.\n\nYes, but when you are first introduced to the words as an English\nspeaker, you don't understand the concepts either. This part of the\nlearning curve cannot be eliminated.\n\n> Wikipedia is a bad reference for measuring the importance of certain  \n> things. I (or you) could have easily adapted that article to my\n> point of view before continuing the discussion.\n\nBut neither of us have, right? We're adults, after all. You're free to\nassume that Wikipedia doesn't reflect some kind of social consensus. I\ndo assume that, moreso than I assume that Wikipedia is accurate.\n\n> However, in this particular case that article doesn't even mention\n> many of the terms which need to be discussed in a git glossary.\n\nOf course not... but it reflects a tendency for terms to not be\ntranslated.\n\n> >  branch                Branch (m.)  \n>\n> I'd go for \"Zweig\". It's even on the wikipedia page and it perfectly  \n> represents the concept.\n\nMy main reason for not translating this one is that we have a command\ncalled \"branch\" and since people need to learn what it means anyway,\nand we're certainly not going to change the command names in different\nlanguages, translating the term in other uses just means that German\nusers have to remember two different words for the same thing. Similar\nreasoning applies to some other terms.\n\n> >  index                 Index\n> \n> I'd strongly vote for not using \"Index\". The \"Index\" is where the  \n> \"Bundesprüfstelle für jugendgefährdende Schriften\" puts the  \n> Ballerspiele on. Don't let the identical word fool you into thinking  \n> this is a worthwhile translation. Also, the English term is a bad  \n> naming anyway IMHO. I'd use git-gui's replacement (staging area) and  \n> use \"Bereitstellung\" here as well. Feel free to propose something  \n> different, but please not \"Index\". Git isn't FSK18.\n\nSo we should strike the word \"Index\" from casual and professional usage\nwhen referring to the reference section of a book?\n\n> \n> >  commit (noun, verb)                Commit/committen\n> \n> That's a hard one. It sounds terrible to use \"committen\" in German.\n\nTrue, but it beats the alternatives. I seriously can't think of any\nGerman word that is equivalent to \"commit\" in the sense that we use it;\nneither verb nor noun form. The command name reasoning applies here,\ntoo.\n\n> >  revision              Revision\n> \n> Die \"Revision\" kommt ins Haus, um die Bücher zu prüfen. Honestly,  \n> please don't use that word in German. Why not \"Version\"?\n\nSure, why not... though there are a *lot* of other meanings for the word\nin German.\n\n> >  tag                   Tag\n> \n> Der heutige Tag oder der morgige Tag? What's the problem with  \n> \"Markierung\"? This is exactky the git concept which is meant.\n\nI believe that the English \"tag\" is a much better metaphor than the\nGerman \"Markierung\". One use of \"tag\" refers to a small label that is\nattached to, for example, baggage. This is exactly the concept we have\nin git. \"Markierung\" doesn't come close at all to describing the same\nconcept. Conflicts markers are \"Markierungen\"; tags are not.\nThe command name reasoning applies here, too.\n\n> >  tree                  Tree\n> \n> I would not understand what the \"Tree\" in German should be. Any\n> German word instead?\n\nOkay, fair enough.\n\nAnyway, to conclude: I appreciate the feedback, but I think translating\nall words is not as conducive to making git accessible to Germans as you\nthink.\n\n-Jan\n"},{"id":"150812","messageId":"AANLkTikvW=YY2X9VR8oS2pk3fs9KFkQ_O7m=zOEN4nEk@mail.gmail.com","threadId":"25107","inReplyTo":"20100916125751.163d8691@jk.gs","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-09-16T11:09:52Z","receivedAt":"2010-09-16T11:09:52Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Sep 16, 2010 at 10:57, Jan Krüger <jk@jk.gs> wrote:\n\n> My main reason for not translating this one is that we have a command\n> called \"branch\" and since people need to learn what it means anyway,\n> and we're certainly not going to change the command names in different\n> languages [...] \"Markierung\" doesn't come close at all to describing the same\n> concept. Conflicts markers are \"Markierungen\"; tags are not.\n> The command name reasoning applies here, too.\n\nFWIW we could translate the command names if we wanted to, but whether\nto do that or not is something we'll have to look at in due time.\n"},{"id":"150814","messageId":"4C91FF90.6050902@web.de","threadId":"25107","inReplyTo":"AANLkTikvW=YY2X9VR8oS2pk3fs9KFkQ_O7m=zOEN4nEk@mail.gmail.com","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-09-16T11:29:20Z","receivedAt":"2010-09-16T11:29:20Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 16.09.2010 13:09, schrieb Ævar Arnfjörð Bjarmason:\n> On Thu, Sep 16, 2010 at 10:57, Jan Krüger <jk@jk.gs> wrote:\n> \n>> My main reason for not translating this one is that we have a command\n>> called \"branch\" and since people need to learn what it means anyway,\n>> and we're certainly not going to change the command names in different\n>> languages [...] \"Markierung\" doesn't come close at all to describing the same\n>> concept. Conflicts markers are \"Markierungen\"; tags are not.\n>> The command name reasoning applies here, too.\n> \n> FWIW we could translate the command names if we wanted to, but whether\n> to do that or not is something we'll have to look at in due time.\n\nAre you seriously thinking about translating the \"git branch\" command\ninto \"git zweig\"??? Locale-specific batch files should be real fun ...\n"},{"id":"150818","messageId":"AANLkTi=D1+DQ=JXBrWmf142dqTPhQbSa0hw=j8TLrGVX@mail.gmail.com","threadId":"25107","inReplyTo":"4C91FF90.6050902@web.de","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-09-16T11:51:15Z","receivedAt":"2010-09-16T11:51:15Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Sep 16, 2010 at 11:29, Jens Lehmann <Jens.Lehmann@web.de> wrote:\n> Am 16.09.2010 13:09, schrieb Ævar Arnfjörð Bjarmason:\n>> On Thu, Sep 16, 2010 at 10:57, Jan Krüger <jk@jk.gs> wrote:\n>>\n>>> My main reason for not translating this one is that we have a command\n>>> called \"branch\" and since people need to learn what it means anyway,\n>>> and we're certainly not going to change the command names in different\n>>> languages [...] \"Markierung\" doesn't come close at all to describing the same\n>>> concept. Conflicts markers are \"Markierungen\"; tags are not.\n>>> The command name reasoning applies here, too.\n>>\n>> FWIW we could translate the command names if we wanted to, but whether\n>> to do that or not is something we'll have to look at in due time.\n>\n> Are you seriously thinking about translating the \"git branch\" command\n> into \"git zweig\"???\n\nI am. I don't think we should do it, I'm just saying we can.\n\n    char *allowed_names[] = { \"branch\", _(\"branch\"), NULL };\n\nRight now we only talk to the user in their native language, but we\ncould extend that so that the user can also talk to us.\n\n> Locale-specific batch files should be real fun ...\n\nWe'd only translate the porcelain commands, and document that using\nthe translated versions anywhere but interactively on the command-line\nis a bad idea.\n\nBut to re-iterate, I'm not saying we should do it, just that it would\nbe easy to add it if we want to, and it would presumably be easier to\nuse a translated git in if we did this.\n"},{"id":"150819","messageId":"4C9204BE.800@drmicha.warpmail.net","threadId":"25107","inReplyTo":"20100916125751.163d8691@jk.gs","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-16T11:51:26Z","receivedAt":"2010-09-16T11:51:26Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jan Krüger venit, vidit, dixit 16.09.2010 12:57:\n> Christian Stimming <stimming@tuhh.de> wrote:\n> \n>> As you might guess, as the (initial) translator of git-gui I've been  \n>> through this discussion before [1] and as you have noticed, I have  \n>> decided to take a translation approach different from what you have  \n>> recently discussed here. I deliberately tried to translate as much\n>> of the terms into German as possible. I do not agree about the\n>> importance of statements on this mailing list like \"This translation\n>> translates too much terms - I cannot find the commands I'm used to\".\n>> The point of a translation is to enable the usage of a program to\n>> people who do *not* know the original language.\n> \n> Please explain how translating all terms makes it easier for Germans to\n> work with git. As far as I am concerned, all the terms you tried so\n> hard to translate are technical terms, i.e. their full meaning cannot be\n> readily understood without an explanation. That is the reason why we\n> have a glossary for those terms even in the English original.\n> \n> Translating these terms into German does not change anything about\n> that. All terms still need to be explained.\n\nAbsolutely true, and absolutely irrelevant for the decision whether to\ntranslate these, since they need to be explained in any case.\n\n> \n> There is some slight potential gain in that perhaps *some* translated\n> words will be more easily associated with their corresponding\n> explanations due to the imagery they use,\n\nThe aim of a good translation is to reproduce the concept, not the word.\nI assume we're talking about a (mostly) non-English speaking target\naudience here, and for them associating meaning with terms in their\nnative language is certainly easier.\n\n...\n> There are quite a few examples in the git-gui translation that I\n> consider extremely unwieldy, and in my initial translation of git\n> itself I tried very hard to avoid translations like \"Bereitstellung\n> (zum Eintragen)\", where I have absolutely no idea what that is supposed\n> to mean. I don't want to turn this into a critique of git-gui's\n> translation, though. \n[For the record, I don't like that translation either.]\n\n>> I'd go for \"Zweig\". It's even on the wikipedia page and it perfectly  \n>> represents the concept.\n> \n> My main reason for not translating this one is that we have a command\n> called \"branch\" and since people need to learn what it means anyway,\n> and we're certainly not going to change the command names in different\n> languages, translating the term in other uses just means that German\n> users have to remember two different words for the same thing. Similar\n> reasoning applies to some other terms.\n\nI really have to oppose this reasoning. Are you seriously suggesting we\nshould not translate the following words as a matter of principle?\n\nadd\nam (OK, I'm kidding here)\nannotate\napply\narchive\nbisect\nblame\nbranch\nbundle\ncat (...)\ncheck\ncheckout\ncherry(-pick)\nclean\nclone\ncommit\nconfig\ncount\ndaemon\ndescribe\ndiff\nfast\nfetch\nfilter\nfor\nformat\nget\ngrep\ngui\nhash\nhelp\nindex\ninit\nlog\nlost\nmailinfo\nmailsplit\nmerge\nmergetool\nname\nnotes\npack\nparse\npatch\npeek\nprune\npull\npush\nread\nrebase\nreceive\nreflog\nrelink\nremote\nrepack\nreplace\nrepo\nrequest\nreset\nrevert\nrev\nsend\nshell\nshortlog\nshow\nstage\nstash\nstatus\nsubmodule\nsymbolic\ntag\ntar\nunpack\nupdate\nupload\nvar\nverify\nweb\nwrite\n\nWe simply need a principle we can follow, which produces readable text,\nand which helps those in need of a translation. Those with a reasonable\npassive understanding of English don't need a translation at all. Some\nsuggestions to follow:\n\n- Identify term categories which are already in use in the English\nversion, such as \"combinatorial graphs\".\n\n- Within each category, look for established translations in that field;\nin any case, keep the categorical associations for the translation.\n\n- Translate concepts, not words. If there are several choices, favour\nthe one which is linguistically close to the English Git glossary.\nThere's a good chance this will happen quite often with German.\n\n>>>  tag                   Tag\n>>\n>> Der heutige Tag oder der morgige Tag? What's the problem with  \n>> \"Markierung\"? This is exactky the git concept which is meant.\n> \n> I believe that the English \"tag\" is a much better metaphor than the\n> German \"Markierung\". One use of \"tag\" refers to a small label that is\n> attached to, for example, baggage. This is exactly the concept we have\n> in git. \"Markierung\" doesn't come close at all to describing the same\n> concept. Conflicts markers are \"Markierungen\"; tags are not.\n\nThat's exactly why I suggested \"Marke\", see my earlier reply also for\nthe other terms. It conveys the same multiple metaphorical associations.\n\nYou know, there's a reason why translating is a profession. You need to\nbe proficient in both languages, as well as creative. In fact, I don't\nthink the majority of people are proficient enough for that even in\ntheir native language (as a translation target), but every native\nspeaker thinks he or she is, of course. (This is a general remark not\naimed at anyone specifically.)\n\nMichael\n"},{"id":"150830","messageId":"7vsk194u6v.fsf@alter.siamese.dyndns.org","threadId":"25107","inReplyTo":"4C91FF90.6050902@web.de","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-09-16T14:52:24Z","receivedAt":"2010-09-16T14:52:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 16.09.2010 13:09, schrieb Ævar Arnfjörð Bjarmason:\n>> On Thu, Sep 16, 2010 at 10:57, Jan Krüger <jk@jk.gs> wrote:\n>> \n>>> My main reason for not translating this one is that we have a command\n>>> called \"branch\" and since people need to learn what it means anyway,\n>>> and we're certainly not going to change the command names in different\n>>> languages [...] \"Markierung\" doesn't come close at all to describing the same\n>>> concept. Conflicts markers are \"Markierungen\"; tags are not.\n>>> The command name reasoning applies here, too.\n>> \n>> FWIW we could translate the command names if we wanted to, but whether\n>> to do that or not is something we'll have to look at in due time.\n>\n> Are you seriously thinking about translating the \"git branch\" command\n> into \"git zweig\"??? Locale-specific batch files should be real fun ...\n\nPerhaps \"dumme zweig\"?  IOW, shouldn't \"git\" itself be translated in such\na case?\n\nPeople, please stop being ridiculous.\n"},{"id":"150831","messageId":"4C92323B.40307@web.de","threadId":"25107","inReplyTo":"7vsk194u6v.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2010-09-16T15:05:31Z","receivedAt":"2010-09-16T15:05:31Z","isPatch":true,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 16.09.2010 16:52, schrieb Junio C Hamano:\n> Jens Lehmann <Jens.Lehmann@web.de> writes:\n>> Are you seriously thinking about translating the \"git branch\" command\n>> into \"git zweig\"??? Locale-specific batch files should be real fun ...\n> \n> Perhaps \"dumme zweig\"?  IOW, shouldn't \"git\" itself be translated in such\n> a case?\n> \n> People, please stop being ridiculous.\n\nYup, and just in case people misunderstood me: I was being sarcastic.\n"},{"id":"150836","messageId":"20100916184803.39576fd2@jk.gs","threadId":"25107","inReplyTo":"4C9204BE.800@drmicha.warpmail.net","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Jan Krüger","fromEmail":"jk@jk.gs","sentAt":"2010-09-16T16:48:03Z","receivedAt":"2010-09-16T16:48:03Z","isPatch":true,"sender":{"key":"jk@jk.gs","avatar":"https://avatars.githubusercontent.com/u/1774?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> wrote:\n\n> > Translating these terms into German does not change anything about\n> > that. All terms still need to be explained.\n> \n> Absolutely true, and absolutely irrelevant for the decision whether to\n> translate these, since they need to be explained in any case.\n\nThe argument for translating them in the first place was that that\nmakes it easier to understand the text. My argument was that the\ntranslated terms are not more understandable because they still need to\nbe explained. How is that irrelevant? I consider the original argument\nrefuted, and unless you have a different argument for translating them,\nI will continue to translate terms only if I find a reasonable\nequivalent in German.\n\n> The aim of a good translation is to reproduce the concept, not the\n> word. I assume we're talking about a (mostly) non-English speaking\n> target audience here, and for them associating meaning with terms in\n> their native language is certainly easier.\n\nI have not seen a whole lot of good translations, though. Most of them\ndon't represent the original concept nearly as well as the original\nword. Most of the time the metaphorical expressiveness is worlds apart.\n\n> >> I'd go for \"Zweig\". It's even on the wikipedia page and it\n> >> perfectly represents the concept.\n> > \n> > My main reason for not translating this one is that we have a\n> > command called \"branch\" and since people need to learn what it\n> > means anyway, and we're certainly not going to change the command\n> > names in different languages, translating the term in other uses\n> > just means that German users have to remember two different words\n> > for the same thing. Similar reasoning applies to some other terms.\n> \n> I really have to oppose this reasoning. Are you seriously suggesting\n> we should not translate the following words as a matter of principle?\n\nI would indeed keep quite a few of them as they are. But you're\nright, the fact that they would likely be kept as command names just\nmakes me feel better about keeping them untranslated; the main reason\nis that I can't find good translations. Let's step through them one\nby one, against my better judgement.\n\n> add\n\nThis one is straightforward enough, I have to admit. \"Hinzufügen\" is\nexactly the concept we're looking for here.\n\n> am (OK, I'm kidding here)\n\n\"pa\" für \"Postfach anwenden\"? ;)\n\n> apply\n\nI believe that \"anwenden\" is indeed frequently used in this context.\n\n> archive\n\nThere exists an exactly equivalent word in German, so that's wonderful.\n\n> bisect\n\nThis will be translated to \"halbieren\" over my cold, dead body.\n\n> blame\n\nCan't think of anything right now, but my intuition says that this can\nbe translated gracefully; perhaps not in one word, but who cares.\n\n> branch\n\nI actually think that \"Zweig\" is not a perfect translation here.\n\"Zweig\" is commonly used in the context of describing trees. The git\nhistory is not in tree form, though. Instead, I think the concept of a\nbranch in the road is a better fit; it's natural for a road to branch\noff and later rejoin whatever road it branched off of. A translation of\nthat might be \"Abzweig\", but I would prefer a word that doesn't\ncurrently sound stilted.\n\n> bundle\n\nI'd argue that the word \"Bundle\" is already used in German technical\nlingo.\n\n> cat (...)\n\nThose (and some others in your list) tend to be plumbing commands. I\ndon't think we need to think about them quite as hard as about\nporcelain.\n\n> checkout\n\nThere is no good equivalent in German (that I know of). Actually the\noriginal term is not very good in the first place. It seems to be using\nborrowing \"checkout\" in the sense as used in, for example, a library.\n\n(Actually, \"auschecken\" exists (listed in my dictionary of choice, at\nleast) and is probably close enough...)\n\n> cherry(-pick)\n\nThis is a tricky one. \"Pflücken\" is certainly not an ideal translation;\n\"herauspicken\" is closer but a bit awkward to integrate into a sentence.\n\n> clean\n\nStraightforward translation: \"aufräumen\".\n\n> clone\n\nGerman equivalent exists: \"klonen/Klon\".\n\n> commit\n\nThis is about the most complicated term there is. This word unites so\nmany meanings it's not even funny. The most relevant ones which I\nsee reflected in git are:\n\n- commit to memory\n- commit to a decision\n- commit someone to a mental institution (and aren't there enough\n  commits where you feel a bit like that?)\n- commit a crime\n\nNote that I'm just using these as examples of what \"commit\" can mean,\nand I see all of these meanings reflected in git's usage in one way or\nanother.\n\nNow try and find a German word that has the same kind of overall\nmeaning. I'll wait.\n\nAnother important reason why I really wouldn't change this one\n(\"Commit/committen\") is that it's widely used like that in German\nalready. By introducing new users to some kind of Germanized metaphor,\nyou end up creating a communication barrier between existing experts\nand new users. I think that should be avoided at all costs.\n\nThis is also the reason why I oppose the argument that a translation\nshould exclusively cater to new users who don't speak English. I\nbelieve that the meaning of translation should at least be easily\napparent to existing German users. The example \"Bereitstellung (zum\nEintragen)\" that I already gave from git-gui shows how not to do that.\nIt took me at least a minute to figure out what that meant.\n\nPeople who don't share my point of view have not responded to this\nargument so far, but I believe that it's crucially important.\n\n> config\n> count\n> describe\n\nStraightforward.\n\n> daemon\n\nI wouldn't translate this one. It's a crafted word; there's no reason\nto replace it with a non-crafted word in German. Also it's commonly\nused by German UNIX experts anyway.\n\n> diff\n\nThe whole point of this word is to be short. It's close enough to the\nGerman \"Differenz\" that I would keep it, even as a verb (\"diffen\").\nAgain, this form is crafted anyway.\n\n(No, it's not okay to call it \"differenzieren\". You'll drive math folks\nto homicide if you do that. ;))\n\n> fetch\n\nI already translated this one.\n\n> filter\n\nThe German word is the same.\n\n> format\n\nAgain, this is difficult. In prose I would just call it \"Patch\nerstellen\".\n\n> grep\n\nAnother crafted word. I'd keep it. Any UNIX user will know it anyway.\n\n> gui\n\nNobody ever translates this acronym.\n\n> hash\n\n\"Hash\" is a widely used technical term in German.\n\n> help\n> index\n> init\n\nStraightforward.\n\n> log\n\n\"Protokoll\" seems a bit cumbersome but is close enough to the original\nconcept.\n\n> lost\n\nI'm beginning to figure out how you generated this list...\n\n> merge\n\nAgain, there is no real equivalent in German. I would be all in favour\nof going with a more elaborate translation if that wouldn't make\ncertain things extremely convoluted (\"Zusammenführungscommit\"?).\n\n> name\n\nDid you even read this part of your mail? ;)\n\n> notes\n\nStraightforward.\n\n> pack\n\nLess so. Used as a noun, most straightforward translations will clash\nwith \"archive\" or \"repository\" or whatever. \"Paket\" clashes with its\nusual meaning of \"packet\", especially in contexts like \"receive pack\".\n\nI would really like to translate this one (it seems like it shouldn't\nbe too hard), but I don't have any decent ideas.\n\n> patch\n\nCustomarily used in German.\n\n> pull\n\nAnother tricky one. I haven't quite decided yet whether \"ziehen\" is an\naccurate translation. I'd probably try to cheat by rephrasing sentences\nthat use this word.\n\n> push\n\nSame thing.\n\n> rebase\n\nTricky. This is another crafted word. I believe the best chance of\ndoing it justice would be in crafting a word with a German base that's\nvery similar to this. Lacking of a good solution, I'd keep the original\nword.\n\n> reflog\n\nAnother crafted one. Developers tend to know the term \"log\", so I'd\nkeep this one, especially since it'll be hard to find something else\nthat can be shortened this much.\n\n> remote\n\nI haven't translated this one yet. I guess it would map nicely to\n\"extern\", though then we'd lose the noun meaning of the original.\n\n> reset\n\nStraightforward, though \"reset\" doesn't really describe very well what\nit does in the first place.\n\n> revert\n\nLiterally translating this one out of the dictionary will end up being\nincorrect. \"Zurücknehmen\" would be closer.\n\n> rev\n\nChristian's \"Versionsangabe\" seems like a good fit.\n\n> show\n\nStraightforward.\n\n> stage\n\nI translated this to \"vormerken\".\n\n> stash\n\nTricky. Since some of the original git lingo is fairly casual, though,\nI might go with \"bunkern\". And if anyone complains about connotations\nof war, I'll scream.\n\n> status\n\nUsed in German.\n\n> submodule\n\nI certainly don't have any good idea here.\n\n> We simply need a principle we can follow, which produces readable\n> text, and which helps those in need of a translation. Those with a\n> reasonable passive understanding of English don't need a translation\n> at all. Some suggestions to follow:\n> \n> - Identify term categories which are already in use in the English\n> version, such as \"combinatorial graphs\".\n\nWe usually use only a very small part of each taxonomy (see, for\nexample, the word \"branch\" which is *not* used by us as it is in graph\ntheory), so this doesn't help as much as it might seem. I agree that\nreusing well-established translated taxonomies is a good thing, though.\n\n> - Translate concepts, not words. If there are several choices, favour\n> the one which is linguistically close to the English Git glossary.\n\nI agree with this too, as long as it's done *well*. That includes\nsetting a \"maximum distance\" between the original and the translations.\nA rough fit (e.g. commit <-> eintragen, stage <-> bereitstellen and\nmany others) should be rejected as not really making things better.\n\n> > I believe that the English \"tag\" is a much better metaphor than the\n> > German \"Markierung\". One use of \"tag\" refers to a small label that\n> > is attached to, for example, baggage. This is exactly the concept\n> > we have in git. \"Markierung\" doesn't come close at all to\n> > describing the same concept. Conflicts markers are \"Markierungen\";\n> > tags are not.\n> \n> That's exactly why I suggested \"Marke\", see my earlier reply also for\n> the other terms. It conveys the same multiple metaphorical\n> associations.\n\nI disagree. Arguably, the strongest association is\n\"Briefmarke\" (postage stamp), probably followed by\n\"Erkennungsmarke/Markenzeichen\" (trademark) and perhaps\n\"Plakette\" (insignia). None of these reflect what a \"tag\" is about:\n(more or less) loosely attaching an identifier to a revision, as in the\ncase of a baggage tag or a dog tag. What's more, the word \"Tag\" is\nalready widely used in German version control lingo. For example, the\nGerman translation of the SVN red book uses it.\n\n> You know, there's a reason why translating is a profession. You need\n> to be proficient in both languages, as well as creative. In fact, I\n> don't think the majority of people are proficient enough for that\n> even in their native language (as a translation target), but every\n> native speaker thinks he or she is, of course. (This is a general\n> remark not aimed at anyone specifically.)\n\nThe whole profession argument has never sat well with me. I know\nhobbyists who have ten times the skills of some professionals. I agree\nthat translating is a nontrivial task, though... and I, personally,\nwill not be involved in anything less than a very good translation. I\nhave outlined what I perceive as shortcomings in a number of\nsuggestions made here. I'll be glad to look at alternative suggestions,\nbut so far, for a number of terms, I haven't seen a satisfactory\nalternative to adopting the English ones.\n\n(FWIW, I've bounced some of the more controversial of my translations\noff a couple of git users, but also off a graduate of German language\nand literature studies who uses neither git nor English. I'm just\nmentioning that due to your totally-not-aimed-at-anyone remark, though;\nI don't think it should actually make any difference.)\n\nAt any rate, I will stop working on translating git as long as this\ndiscussion goes on. And, of course, should you guys end up insisting on\nbad translations, I'll leave you to writing it that way. Under\nprotest. :)\n\n-Jan\n"},{"id":"150867","messageId":"4C931774.9060808@drmicha.warpmail.net","threadId":"25107","inReplyTo":"20100916184803.39576fd2@jk.gs","subject":"Re: [PATCH 1/2] po/de.po: add German translation","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-09-17T07:23:32Z","receivedAt":"2010-09-17T07:23:32Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"[snipping most parts to make this shorter]\n\nJan Krüger venit, vidit, dixit 16.09.2010 18:48:\n> Michael J Gruber <git@drmicha.warpmail.net> wrote:\n> \n>>> Translating these terms into German does not change anything about\n>>> that. All terms still need to be explained.\n>>\n>> Absolutely true, and absolutely irrelevant for the decision whether to\n>> translate these, since they need to be explained in any case.\n> \n> The argument for translating them in the first place was that that\n> makes it easier to understand the text. My argument was that the\n> translated terms are not more understandable because they still need to\n> be explained. How is that irrelevant? I consider the original argument\n\nIf it makes no difference then it is irrelevant for the decision. It's\nneither pro nor con, other arguments have to be brought up.\n\n>> I really have to oppose this reasoning. Are you seriously suggesting\n>> we should not translate the following words as a matter of principle?\n> \n> I would indeed keep quite a few of them as they are. But you're\n> right, the fact that they would likely be kept as command names just\n> makes me feel better about keeping them untranslated; the main reason\n> is that I can't find good translations. Let's step through them one\n> by one, against my better judgement.\n\nThis was not meant as a list to be worked through, but as an argument\nthat the principle \"do not translate command names at all\" (i.e. in *no*\ncontext) is not viable.\n\n>>> I believe that the English \"tag\" is a much better metaphor than the\n>>> German \"Markierung\". One use of \"tag\" refers to a small label that\n>>> is attached to, for example, baggage. This is exactly the concept\n>>> we have in git. \"Markierung\" doesn't come close at all to\n>>> describing the same concept. Conflicts markers are \"Markierungen\";\n>>> tags are not.\n>>\n>> That's exactly why I suggested \"Marke\", see my earlier reply also for\n>> the other terms. It conveys the same multiple metaphorical\n>> associations.\n> \n> I disagree. Arguably, the strongest association is\n> \"Briefmarke\" (postage stamp), probably followed by\n> \"Erkennungsmarke/Markenzeichen\" (trademark) and perhaps\n> \"Plakette\" (insignia). None of these reflect what a \"tag\" is about:\n> (more or less) loosely attaching an identifier to a revision, as in the\n> case of a baggage tag or a dog tag. What's more, the word \"Tag\" is\n\ndog tag is Hundemarke. I really think Marke conveys most meanings of\ntag, especially those relevant to the meaning of tag in Git context. If\nyou insist on translating all aspects and connotations of a word then\nthere is no translation at all.\n\n> already widely used in German version control lingo. For example, the\n> German translation of the SVN red book uses it.\n> \n>> You know, there's a reason why translating is a profession. You need\n>> to be proficient in both languages, as well as creative. In fact, I\n>> don't think the majority of people are proficient enough for that\n>> even in their native language (as a translation target), but every\n>> native speaker thinks he or she is, of course. (This is a general\n>> remark not aimed at anyone specifically.)\n> \n> The whole profession argument has never sat well with me. I know\n> hobbyists who have ten times the skills of some professionals. I agree\n\nI talked about \"profession\", not about hobbyists vs. professionals. And\nI don't like it when you turn around my words in my mouth.\n\n> that translating is a nontrivial task, though... and I, personally,\n> will not be involved in anything less than a very good translation. I\n> have outlined what I perceive as shortcomings in a number of\n> suggestions made here. I'll be glad to look at alternative suggestions,\n> but so far, for a number of terms, I haven't seen a satisfactory\n> alternative to adopting the English ones.\n> \n> (FWIW, I've bounced some of the more controversial of my translations\n> off a couple of git users, but also off a graduate of German language\n> and literature studies who uses neither git nor English. I'm just\n> mentioning that due to your totally-not-aimed-at-anyone remark, though;\n\nYou can take that for face-value - it was not aimed at anyone, and you\nhave no reason to claim otherwise.\n\n> I don't think it should actually make any difference.)\n> \n> At any rate, I will stop working on translating git as long as this\n> discussion goes on. And, of course, should you guys end up insisting on\n> bad translations, I'll leave you to writing it that way. Under\n> protest. :)\n\nWe simply have to decide about a concept, about an approach first, about\nwhat is \"bad\" and what is \"good\" (for the yet to be determined target\naudience) as you put it, before flooding the single de.po with\ntranslation pieces without an agreement on a glossary for the main terms.\n\nBut, given the direction this discussion is taking now, I'm really\npessimistic that this is going to happen. Maybe switching to DE would\nhelp, I dunno.\n\nMichael\n"}]}