{"thread":{"id":"33807","subject":"English/German terminology, git.git's de.po, and pro-git","startedAt":"2013-05-13T12:54:51Z","lastAt":"2013-06-16T21:22:29Z","messageCount":32,"participants":["Thomas Rast","Jan Engelhardt","Ralf Thielow","Jens Lehmann","Ralph Haußmann","Holger Hellmuth (IKS)","Christian Stimming","Holger Hellmuth","Bernhard R. Link"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"217161","messageId":"87k3n36nvo.fsf@linux-k42r.v.cablecom.net","threadId":"33807","inReplyTo":null,"subject":"English/German terminology, git.git's de.po, and pro-git","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-05-13T12:54:51Z","receivedAt":"2013-05-13T12:54:51Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Hi\n\nI hope I got together a Cc list that pretty much represents everyone\ninvolved in git core and pro-git book translation into German.\n\nAs I am sure you are all aware, there are two main religions as to how\none can translate technical material into German: leave the technical\nterms mostly in English, or translate them to an appropriate\ncorresponding word. I'll denote them G+E and Ger, respectively. I\nwould really like to avoid rehashing that entire discussion in this\nthread, if at all possible; we've flogged that horse enough. See\ne.g. [1] for previous threads on the git list about the transation.\n\nHowever, an unfortunate and unsatisfactory situation has developed:\nChristian Stimming's git-gui de.po uses a Ger translation, and Ralf\nThielow built core git's de.po on top of it, so it's also Ger.\n\nMeanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a\ntranslation of pro-git (which is also quite mature at this point, having\napparently begun in 2009), and as you probably guessed by now, it's G+E.\n\nSo that leaves us at a point where \"the\" libre Git book (and also the\none that happens to be hosted on git-scm.com, the official site) does\nnot match the terminology used by German git.\n\nLike, at all. They're not even remotely near each other.\n\nTherefore, a total newbie would find at least one of those two totally\nuseless. I haven't done a comprehensive survey yet, but it is my\nimpression that the commercial git books are also G+E, so the\nhypothetical newbie would be stuck learning the English terms in one of\nthe two regardless.\n\nSo where to go from this mess?\n\nObviously -- unless the agreement is that the status quo should persist\n-- we'd first have to sort out what the preferable translation should\nbe. And I'm a bit scared of trying, except that a straw poll on IRC\ngave me some hope that a simple majority vote could help settle it.\n\nMy vote is G+E.\n\nAfter that, we should create a unified glossary. Even in the G+E case,\na few terms would presumably be translated fully and some others might\nhave partial translations (checkout -> auschecken?). The current\nglossary for git's de.po is [2]. I have no idea what Sven and Ralph do.\nPerhaps a github wiki page would be fine for everyone?\n\nFinally, converting the existing translation will require some manpower.\nI'll help review things, as I have previously done for translation\nupdates of core git de.po; perhaps with a few more volunteers it can be\ndone pretty quickly.\n\nThanks for your time.\n\n- Thomas\n\n\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/58315\n http://thread.gmane.org/gmane.comp.version-control.git/156226/focus=156373\n http://thread.gmane.org/gmane.comp.version-control.git/196779/focus=196792\n\n[2] https://github.com/ralfth/git-po-de/wiki/Glossary\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"217172","messageId":"alpine.LNX.2.01.1305131542210.30808@nerf07.vanv.qr","threadId":"33807","inReplyTo":"87k3n36nvo.fsf@linux-k42r.v.cablecom.net","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-05-13T13:57:47Z","receivedAt":"2013-05-13T13:57:47Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Monday 2013-05-13 14:54, Thomas Rast wrote:\n>As I am sure you are all aware, there are two main religions as to how\n>one can translate technical material into German: leave the technical\n>terms mostly in English, or translate them to an appropriate\n>corresponding word. I'll denote them G+E and Ger, respectively.\n\nThe problem is that there are often no technical equivalent terms\nin Ger, leaving you only with Eng which are paraphrased (in more\nor less detail) in the German-language manpages.\n\n\"treeish\" is one of those. The literal translation would be \"baumig\",\n\"bäumlich\". This is strange in German and at best only used by kids.\nIn the SYNOPSIS section of e.g. git-ls-tree(1), you can get away with\n\"baumähnlich\", but in flowtext (prose), the sane choices are, for\nexample:\n\n\tgit-ls-tree erfordert als ersten nicht-Options-Parameter...\n\n\t~... einen \"tree-ish\", d.h. eine Referenz, aus der sich ein\n\tBaum-Objekt ableiten lässt.\n\n\t~... eine zu einem Baum-Objekt führende Refernz\n\n\t~... eine Baum-Objekt-Referenz\n\t(dies kann auch ein Commit sein, da jedem Commit genau ein\n\tBaum-Objekt zugeordnet ist)\n\n\n>My vote is G+E.\n\nEssentially, so is mine. German terms will be used where such have\nbeen used in prior computing (Bäume have been used in the 90s too,\nso that term is fine, for example). Stash however is something that\ncould be seen as something that has had its first appearence in Git,\nwith no corresponding native German term, in which case we should\ndo it roughly like Wikipedia, that is, provide a German equivalent,\nbut only for the introductory sake:\n\n\tDer Stash (dt: Versteck) bezeichnet einen Bereich ...\n\nafterwards which the meaning of stash is at most re-recognizable\nin the verb:\n\n\t... mit `git stash` wird der aktuelle Zustand im Stash\n\tweggespeichert.\n\nThat's my common-world use.\n\n>glossary for git's de.po is [2]. I have no idea what Sven and Ralph do.\n>Perhaps a github wiki page would be fine for everyone?\n\nA single wiki page might not suffice; we may need as much as one\nwiki page per term, so that there is ample visual space to record\neach person's comments and justification for choosing a particular\nGerman translation. (Just look at my go at \"treeish\" above, for\nexample.)\n"},{"id":"217206","messageId":"CAN0XMOK=A2yp3eL7BEUyiEaMUwnxeH4TezcUKS=8uap_nkH9Fg@mail.gmail.com","threadId":"33807","inReplyTo":"87k3n36nvo.fsf@linux-k42r.v.cablecom.net","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-13T16:30:30Z","receivedAt":"2013-05-13T16:30:30Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"2013/5/13 Thomas Rast :\n> Hi\n>\n> I hope I got together a Cc list that pretty much represents everyone\n> involved in git core and pro-git book translation into German.\n>\n> As I am sure you are all aware, there are two main religions as to how\n> one can translate technical material into German: leave the technical\n> terms mostly in English, or translate them to an appropriate\n> corresponding word. I'll denote them G+E and Ger, respectively. I\n> would really like to avoid rehashing that entire discussion in this\n> thread, if at all possible; we've flogged that horse enough. See\n> e.g. [1] for previous threads on the git list about the transation.\n>\n> However, an unfortunate and unsatisfactory situation has developed:\n> Christian Stimming's git-gui de.po uses a Ger translation, and Ralf\n> Thielow built core git's de.po on top of it, so it's also Ger.\n>\n> Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a\n> translation of pro-git (which is also quite mature at this point, having\n> apparently begun in 2009), and as you probably guessed by now, it's G+E.\n>\n> So that leaves us at a point where \"the\" libre Git book (and also the\n> one that happens to be hosted on git-scm.com, the official site) does\n> not match the terminology used by German git.\n>\n> Like, at all. They're not even remotely near each other.\n>\n> Therefore, a total newbie would find at least one of those two totally\n> useless. I haven't done a comprehensive survey yet, but it is my\n> impression that the commercial git books are also G+E, so the\n> hypothetical newbie would be stuck learning the English terms in one of\n> the two regardless.\n>\n> So where to go from this mess?\n>\n> Obviously -- unless the agreement is that the status quo should persist\n> -- we'd first have to sort out what the preferable translation should\n> be. And I'm a bit scared of trying, except that a straw poll on IRC\n> gave me some hope that a simple majority vote could help settle it.\n>\n> My vote is G+E.\n>\n\nMy vote is G+E, too. IMO the users should read the same terms in Git\nmessages as they read in the majority of German Git-books/blogs/etc.\n(I don't know one of them where Git terms are translated.) I think that\nwould make users life easier and less confusing.\n\n> After that, we should create a unified glossary. Even in the G+E case,\n> a few terms would presumably be translated fully and some others might\n> have partial translations (checkout -> auschecken?). The current\n> glossary for git's de.po is [2]. I have no idea what Sven and Ralph do.\n> Perhaps a github wiki page would be fine for everyone?\n>\n> Finally, converting the existing translation will require some manpower.\n> I'll help review things, as I have previously done for translation\n> updates of core git de.po; perhaps with a few more volunteers it can be\n> done pretty quickly.\n>\n> Thanks for your time.\n>\n> - Thomas\n>\n>\n>\n> [1] http://thread.gmane.org/gmane.comp.version-control.git/58315\n> http://thread.gmane.org/gmane.comp.version-control.git/156226/focus=156373\n> http://thread.gmane.org/gmane.comp.version-control.git/196779/focus=196792\n>\n> [2] https://github.com/ralfth/git-po-de/wiki/Glossary\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n"},{"id":"217209","messageId":"51912093.4030201@web.de","threadId":"33807","inReplyTo":"alpine.LNX.2.01.1305131542210.30808@nerf07.vanv.qr","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-05-13T17:19:15Z","receivedAt":"2013-05-13T17:19:15Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 13.05.2013 15:57, schrieb Jan Engelhardt:\n> On Monday 2013-05-13 14:54, Thomas Rast wrote:\n>> My vote is G+E.\n> \n> Essentially, so is mine. ...\n\nSame here. I frequently get asked to switch Git back to English when the\n\"LANG=C\" gets lost, because my coworkers and myself - almost all of which\nare native German speakers - are terribly confused by the current git gui\ntranslations.\n\nHaving said that, no matter how this vote turns out the term \"submodule\"\nshould be translated as \"Submodul\" and not \"Unterprojekt\". The former is\na perfectly valid German word and I see no reason to arbitrarily use a\ndifferent one here.\n"},{"id":"217220","messageId":"001d01ce500b$c7c08b70$5741a250$@scanmyfood.de","threadId":"33807","inReplyTo":"alpine.LNX.2.01.1305131542210.30808@nerf07.vanv.qr","subject":"AW: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralph Haußmann","fromEmail":"ralph@scanmyfood.de","sentAt":"2013-05-13T18:57:55Z","receivedAt":"2013-05-13T18:57:55Z","isPatch":false,"sender":{"key":"ralph@scanmyfood.de","avatar":null},"body":"Hi,\n\nMy vote is G+E, too. \n\nlb1a, Florian Breisch and I are working on the german translation of the \npro-git book (hosted on git-scm.com). We use the repository [1] to share \nour work. If someone wants to help us, JOIN US!\n\nThe current translation of pro-git is mixed, Ger and G+E. For example, \nthe translation of \"annotated tag\" is \"Annotated Tag\", \"kommentierter Tag\" \nand also \"kommentierte Markierung\". I agree with the opinion of Jan \nEngelhardt that german terms should be used if they are commonly \nused in technical context (\"tree\"=> \"Baum\" but \"tag\" should be \"Tag\" \nin german, too).\n\nThere is a glossary for the pro-git book (see [2]) but it is not up-to-date \nand it is also mixed. Therefor I would like to avoid using this glossary. \nI like the idea of a shared wiki (git de.po and pro-git). \nI suggest a single page as overview and single pages for \ncomplicated terms. Maybe we can use our GitHub wiki (see also [3]).\n\n So long\n\nRalph\n\n[1] https://github.com/progit-de/progit\n\n[2] https://github.com/progit/progit/blob/master/de/NOTES\n\n[3] https://github.com/progit-de/progit/wiki/Glossar\n"},{"id":"217223","messageId":"alpine.LNX.2.01.1305132119220.2288@nerf07.vanv.qr","threadId":"33807","inReplyTo":"001d01ce500b$c7c08b70$5741a250$@scanmyfood.de","subject":"Re: AW: English/German terminology, git.git's de.po, and pro-git","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-05-13T19:25:23Z","receivedAt":"2013-05-13T19:25:23Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Monday 2013-05-13 20:57, Ralph Haußmann wrote:\n>\n>There is a glossary for the pro-git book (see [2]) but it is not up-to-date \n>and it is also mixed. Therefor I would like to avoid using this glossary. \n>I like the idea of a shared wiki (git de.po and pro-git). \n>I suggest a single page as overview and single pages for \n>complicated terms. Maybe we can use our GitHub wiki (see also [3]).\n>\n>[2] https://github.com/progit/progit/blob/master/de/NOTES\n>[3] https://github.com/progit-de/progit/wiki/Glossar\n\nThis is how I envision a good glossary\n\n\thttp://inai.de/files/git-glossary.txt\n\nMaybe the \"Benevolent Dictator\" model might be better suited\ninstead of a wiki? (Think of the edit wars.)\n"},{"id":"217336","messageId":"CAN0XMOL3rkYDinSCN2GLaRj7dOvbF=SdMRxM4PHCZ5h7g5Nkkw@mail.gmail.com","threadId":"33807","inReplyTo":"alpine.LNX.2.01.1305132119220.2288@nerf07.vanv.qr","subject":"Re: AW: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-14T17:51:40Z","receivedAt":"2013-05-14T17:51:40Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Hi all,\n\nI tried to merge these different glossaries together (based on git de.po)\nas a new wiki page [1]. You can see the diff against the current git de.po\nglossary at [2]. I've also created a branch in my repository which only contains\nthe wiki page as a text file. This allows comments on each line of a commit,\nwhich perhaps can be used for discussions (see [3]) and/or pull-requests?!\nIf we really want to use one glossary, I'm also happy with other solutions or\nrepositories.\n\nThe new wiki page is in WIP state and it turns out that there aren't so many\nchanges to the current one as I expected. I want to give a few comments on\nthe most important changes:\n\n- tree = Baum\n+ tree = Baum, Baum-Objekt, \"Tree\"-Objekt\n\n\"Baum\" is already fine. Depending on the message context we could use\n\"Baum-Objekt\", but not necessarily.\n\n- submodule = Unterprojekt\n+ submodule = Submodul (suggested by JL) (before it was \"Unterprojekt\")\n\nI'm fine with that.\n\n- ancestor = Vorfahre\n+ ancestor = Vorfahre, Vorgänger, Vorgänger-Commit\n\n\"Vorgänger\" sounds a bit better for me.\n\n- repository = Projektarchiv\n- bare repository = bloßes Projektarchiv\n+ repository = Projektarchiv, (or just Repository?)\n+ bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)\n\nI'm not sure about using \"Repository\". I think \"Projektarchiv\" is\nactually good enough.\n\n- committer = Eintragender\n- tagger = Markierer\n+ committer = Eintragender (or Committer, Commit-Ersteller)\n+ tagger = Markierer (or Tagger, Tag-Ersteller)\n...[each usage of commit and tag]...\n\nThis goes to the question if we should translate \"Commit\" and \"Tag\".\nI think we shouldn't since everyone who uses/learn Git or come from\nother SCMs know what it means.\n\n+ revision = Revision (use Commit instead (see dfb4410 (glossary: a\nrevision is just a commit))\n\nSo just \"Commit\".\n\n+ branch = Zweig (or Branch)\n\nI think \"Zweig\" is already fine.\n\n+ stage/index (noun) = Bereitstellung (Staging-Area, Index)\n+ stage/index (verb) = stagen, für einen Commit vormerken, zur Staging\nArea hinzufügen, dem Index hinzufügen\n+ unstage (verb) = unstagen, aus Staging Area entfernen/nehmen, aus\nIndex entfernen/nehmen\n\nI think we should replace \"Bereitstellung\" and \"bereitstellen\". \"für\neinen/den Commit vormerken\" is\nnice when \"stage\" is used as a verb. When \"stage\" is used as a noun,\nwe have to decide between\n\"Index\" and \"Staging Area\" (and \"Cache\"?) I'd prefer \"Index\".\n\n+ merge = Zusammenführung (Merge)\n\nWe currently translate the noun of \"merge\" as \"Zusammenführung\" and\nthe verb as \"zusammenführen\".\nI'd change it so \"der Merge\" and \"mergen\".\n\nThe diff in [2] shows a couple of more changes but they're all based\non the things I've mentioned here.\n\n[1]\nhttps://github.com/ralfth/git-po-de/wiki/Glossary-new-WIP\n[2]\nhttps://github.com/ralfth/git-po-de/wiki/_compare/25baaa323929949283a0b920c1ef66dc16288d0b...12f08b8973bd4b7ea55779f6eb5ad3a86bac13d8\n[3]\nhttps://github.com/ralfth/git-po-de/commit/28852f8ea33ac6a9dbf7e3b17dfa00ddd4e7ecb5\n\nThanks,\nRalf\n\n2013/5/13 Jan Engelhardt :\n>\n> On Monday 2013-05-13 20:57, Ralph Haußmann wrote:\n>>\n>>There is a glossary for the pro-git book (see [2]) but it is not up-to-date\n>>and it is also mixed. Therefor I would like to avoid using this glossary.\n>>I like the idea of a shared wiki (git de.po and pro-git).\n>>I suggest a single page as overview and single pages for\n>>complicated terms. Maybe we can use our GitHub wiki (see also [3]).\n>>\n>>[2] https://github.com/progit/progit/blob/master/de/NOTES\n>>[3] https://github.com/progit-de/progit/wiki/Glossar\n>\n> This is how I envision a good glossary\n>\n> http://inai.de/files/git-glossary.txt\n>\n> Maybe the \"Benevolent Dictator\" model might be better suited\n> instead of a wiki? (Think of the edit wars.)\n"},{"id":"217424","messageId":"51936218.9020306@ira.uka.de","threadId":"33807","inReplyTo":"CAN0XMOL3rkYDinSCN2GLaRj7dOvbF=SdMRxM4PHCZ5h7g5Nkkw@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-05-15T10:23:20Z","receivedAt":"2013-05-15T10:23:20Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 14.05.2013 19:51, schrieb Ralf Thielow:\n> - repository = Projektarchiv\n> - bare repository = bloßes Projektarchiv\n> + repository = Projektarchiv, (or just Repository?)\n> + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)\n\nI would vote for Repository or if it needs to be translated, simply \nArchiv. Neither Projektarchiv nor Archiv is commonly used by me but \nArchiv is shorter and not everything in a repository is a project.\n\n> I'm not sure about using \"Repository\". I think \"Projektarchiv\" is\n> actually good enough.\n>\n> - committer = Eintragender\n> - tagger = Markierer\n> + committer = Eintragender (or Committer, Commit-Ersteller)\n> + tagger = Markierer (or Tagger, Tag-Ersteller)\n> ...[each usage of commit and tag]...\n\nBoth \"commit\" and \"tag\" are used in commands so with the exception of \nthe place where they are defined the english words should be used. I \nthink Commit-/Tag-Ersteller actually sounds fine and german enough so no \none notices there is an english word in there ;-)\n\n\n> + branch = Zweig (or Branch)\n>\n> I think \"Zweig\" is already fine.\n\nSame reason, branch is used as a command and should not be translated. \nBut \"Zweig\" is a really natural and together with \"Baum\" fitting \ntranslation, so I'm conflicted here.\n"},{"id":"217426","messageId":"519370D3.3000306@web.de","threadId":"33807","inReplyTo":"51936218.9020306@ira.uka.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-05-15T11:26:11Z","receivedAt":"2013-05-15T11:26:11Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 15.05.2013 12:23, schrieb Holger Hellmuth (IKS):\n> Am 14.05.2013 19:51, schrieb Ralf Thielow:\n>> - repository = Projektarchiv\n>> - bare repository = bloßes Projektarchiv\n>> + repository = Projektarchiv, (or just Repository?)\n>> + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)\n> \n> I would vote for Repository or if it needs to be translated, simply Archiv. Neither Projektarchiv nor Archiv is commonly used by me but Archiv is shorter and not everything in a repository is a project.\n\nHmm, I rather tend towards using \"Repository\" instead of \"Archiv\" too, as\n\"Archiv\" can mean anything from a tar-file to a git repository, while we are\ntalking about something very specific here (and a German might be surprised\nwhat the command \"git archive\" is about if we use \"Archiv\" here ;-). So if\nit has to be translated, I like \"Projektarchiv\" better than \"Archiv\" for\nthose reasons. We can also think about using \"Repo\" as an abbreviated form,\nwe often use that when talking about repositories in German. That would be a\nnew term without ambiguity and will be pronounced pretty much correctly by\nall Germans too. But this remains one of the tougher questions.\n\nAnd then \"pack\" is currently translated as \"Archiv\":\n\n pack(noun) = Archiv\n\nbut I believe \"Packdatei\" would be a much better translation (especially as\nthe translation of \"pack(verb)\" is \"packen\"). I find it natural that a file\nwith the extension \".pack\" is named Packdatei, just like a file with the\nextension \".zip\" is a \"Zipdatei\" (known by the Duden) in German. And the\nDuden already knows \"Pack\" as an assembly of smaller parts, so we should be\nsafe here.\n\n>> I'm not sure about using \"Repository\". I think \"Projektarchiv\" is\n>> actually good enough.\n>>\n>> - committer = Eintragender\n>> - tagger = Markierer\n>> + committer = Eintragender (or Committer, Commit-Ersteller)\n>> + tagger = Markierer (or Tagger, Tag-Ersteller)\n>> ...[each usage of commit and tag]...\n> \n> Both \"commit\" and \"tag\" are used in commands so with the exception of the place where they are defined the english words should be used. I think Commit-/Tag-Ersteller actually sounds fine and german enough so no one notices there is an english word in there ;-)\n\nYup, im my experience \"committen\" (to commit), \"einchecken\" (to check in),\n\"auschecken\" (to check out) und \"taggen\" (to tag) made it into our daily\nGerman language use. To avoid e.g. having past tenses look strange (like\n\"committet\") the combined Form (\"Commit erstellt\") could solve that problem.\n\n>> + branch = Zweig (or Branch)\n>>\n>> I think \"Zweig\" is already fine.\n> \n> Same reason, branch is used as a command and should not be translated. But \"Zweig\" is a really natural and together with \"Baum\" fitting translation, so I'm conflicted here.\n\nYes, Baum, Wurzel and Zweig are obviously equivalent to tree, root and branch,\nso I don't care much if we translate that or not.\n"},{"id":"217427","messageId":"alpine.LNX.2.01.1305151351130.20281@nerf07.vanv.qr","threadId":"33807","inReplyTo":"519370D3.3000306@web.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-05-15T11:56:46Z","receivedAt":"2013-05-15T11:56:46Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Wednesday 2013-05-15 13:26, Jens Lehmann wrote:\n>\n>Hmm, I rather tend towards using \"Repository\" instead of \"Archiv\" too, as\n>\"Archiv\" can mean anything from a tar-file to a git repository\n\nIt's exactly the reasoning I made in my git-glossary.txt sample\n(of which the reasoning apparently has not made it into ralfth's\nlatest wiki, but that's the most essential part of a glossary IMHO).\n\n>but I believe \"Packdatei\" would be a much better translation (especially as\n>the translation of \"pack(verb)\" is \"packen\"). I find it natural that a file\n>with the extension \".pack\" is named Packdatei\n\nWhile it's spoken Packdatei, the way to actually write it is\n.pack-Datei or \".pack\"-Datei.\n\n>extension \".zip\" is a \"Zipdatei\" (known by the Duden)\n\nIf that's how Duden specifies it, it's time to call wrong upon Duden.\nIt's ZIP-Datei, of course, and follows the same origin (\".zip\"-Datei).\nThe history of \"ZIP-Datei\" can be explained by way of MSDOS showing\nthe filename in the DIR command without the dot - which is also\nwhy we do not pronounce the dot in \".zip\"- or \".pack\"-Datei.\n\n\n>Yup, im my experience \"committen\" (to commit), \"einchecken\" (to check in),\n>\"auschecken\" (to check out) und \"taggen\" (to tag) made it into our daily\n>German language use. To avoid e.g. having past tenses look strange (like\n>\"committet\")\n\nNot so strange. We have other words with -tet.\nbitten -> erbittete -> habe erbittet.\n"},{"id":"217429","messageId":"51937F2D.90608@web.de","threadId":"33807","inReplyTo":"alpine.LNX.2.01.1305151351130.20281@nerf07.vanv.qr","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2013-05-15T12:27:25Z","receivedAt":"2013-05-15T12:27:25Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 15.05.2013 13:56, schrieb Jan Engelhardt:\n> On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:\n>> but I believe \"Packdatei\" would be a much better translation (especially as\n>> the translation of \"pack(verb)\" is \"packen\"). I find it natural that a file\n>> with the extension \".pack\" is named Packdatei\n> \n> While it's spoken Packdatei, the way to actually write it is\n> .pack-Datei or \".pack\"-Datei.\n\nI actually had the '-' in there too until I tried to look up \"Zip-Datei\"\nin the Duden. While I don't get the leading '.' (I cannot remember having\nseen that anywhere, AFAIK the file extensions are always used without the\ndot), I'm not a grammar expert and will be fine either way.\n\n>> extension \".zip\" is a \"Zipdatei\" (known by the Duden)\n> \n> If that's how Duden specifies it, it's time to call wrong upon Duden.\n\nGo ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-)\n\n>> Yup, im my experience \"committen\" (to commit), \"einchecken\" (to check in),\n>> \"auschecken\" (to check out) und \"taggen\" (to tag) made it into our daily\n>> German language use. To avoid e.g. having past tenses look strange (like\n>> \"committet\")\n> \n> Not so strange. We have other words with -tet.\n> bitten -> erbittete -> habe erbittet.\n\nThat example was not the best, what about \"wenn Du das mergest(?)\" (if\nyou merge that), I cannot really say how to write that correctly (as in\nGerman we would want to drop the last 'e', right?). All that goes away\nwhen we use \"Merge\" as a noun: \"wenn Du den Merge machst\". But again,\nsomebody else might come up with a grammatically correct solution for\nthat I'm missing.\n"},{"id":"217432","messageId":"alpine.LNX.2.01.1305151502220.15513@nerf07.vanv.qr","threadId":"33807","inReplyTo":"51937F2D.90608@web.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-05-15T13:14:25Z","receivedAt":"2013-05-15T13:14:25Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Wednesday 2013-05-15 14:27, Jens Lehmann wrote:\n>>\n>> While it's spoken Packdatei, the way to actually write it is\n>> .pack-Datei or \".pack\"-Datei.\n>\n>I actually had the '-' in there too until I tried to look up \"Zip-Datei\"\n>in the Duden. While I don't get the leading '.' (I cannot remember having\n>seen that anywhere, AFAIK the file extensions are always used without the\n>dot), I'm not a grammar expert and will be fine either way.\n\nIn UNIX-land, extension seemed to always include the dot.\nIn DOS-land, it's without (inherited from VMS too, perhaps?)\nAs such, either way to write it is acceptable.\n\n>>> extension \".zip\" is a \"Zipdatei\" (known by the Duden)\n>> \n>> If that's how Duden specifies it, it's time to call wrong upon Duden.\n>\n>Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-)\n\n(There seems to be no way to send corrections. Sucks not\nto be a wiki.) Ah well that explains their cluelessness:\n\n nach englisch zip file, zu: to zip = (mit dem Reißverschluss) schließen und\n file = Datei \n\n\"ZIP-Datei\" kommt daher, weil die Erweiterung ZIP/.zip ist, nicht\nweil da ein symbolischer Reißverschluss zugezogen wird oder ein\nProgrammicon selbiges suggerieren will.\n\nWir haben ja schließlich auch RAR-Dateien, die deswegen so heißen,\nweil sie eben .rar als Endung tragen und nicht, weil sie\nwertvolle Mangelware sind. ;-)\n\n\n>> Not so strange. We have other words with -tet.\n>> bitten -> erbittete -> habe erbittet.\n>\n>That example was not the best, what about \"wenn Du das mergest(?)\" (if\n\nKonjugation wie merken, nur Aussprache mit [dʒ] statt [k]-Laut.\nmerge/mergst/mergt/mergen/mergt/mergen/mergte/(habe,hatte) (ge)mergt.\nIch sehe da keine Komplikationen.\n\n>you merge that), I cannot really say how to write that correctly (as in\n>German we would want to drop the last 'e', right?)\n"},{"id":"217445","messageId":"5193AA61.2040205@ira.uka.de","threadId":"33807","inReplyTo":"alpine.LNX.2.01.1305151502220.15513@nerf07.vanv.qr","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-05-15T15:31:45Z","receivedAt":"2013-05-15T15:31:45Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 15.05.2013 15:14, schrieb Jan Engelhardt:\n>\n> On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:\n>>>\n>>> While it's spoken Packdatei, the way to actually write it is\n>>> .pack-Datei or \".pack\"-Datei.\n>>\n>> I actually had the '-' in there too until I tried to look up \"Zip-Datei\"\n>> in the Duden. While I don't get the leading '.' (I cannot remember having\n>> seen that anywhere, AFAIK the file extensions are always used without the\n>> dot), I'm not a grammar expert and will be fine either way.\n>\n> In UNIX-land, extension seemed to always include the dot.\n> In DOS-land, it's without (inherited from VMS too, perhaps?)\n> As such, either way to write it is acceptable.\n\nEven in unix-land no one adds a dot because usually the extension is \nnamed after the data format, only that the file extension is used as the \ncommon abbreviation (at least that is my interpretation). Compare with \njpeg. You often write jpeg-Datei instead of jpg-Datei because the data \nformat is called jpeg.\nThis is why I don't think the dot has any reason to be there. I can't \nremember ever seeing anyone writing .jpg-Datei (or .doc-Datei, \n.rar-Datei) except to ask what a .xyz Datei contains (i.e. when he \ndoesn't know what the data format is)\n"},{"id":"217455","messageId":"alpine.LNX.2.01.1305151924240.8332@nerf07.vanv.qr","threadId":"33807","inReplyTo":"5193AA61.2040205@ira.uka.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-05-15T17:28:12Z","receivedAt":"2013-05-15T17:28:12Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote:\n>>>\n>>> I actually had the '-' in there too until I tried to look up \"Zip-Datei\"\n>>> in the Duden. While I don't get the leading '.' (I cannot remember having\n>>> seen that anywhere, AFAIK the file extensions are always used without the\n>>> dot), I'm not a grammar expert and will be fine either way.\n>>\n>> In UNIX-land, extension seemed to always include the dot.\n>> In DOS-land, it's without (inherited from VMS too, perhaps?)\n>> As such, either way to write it is acceptable.\n>\n> Even in unix-land no one adds a dot because usually the extension is named\n> after the data format, only that the file extension is used as the common\n> abbreviation (at least that is my interpretation). Compare with jpeg. You often\n> write jpeg-Datei instead of jpg-Datei because the data format is called jpeg.\n\nThat too is correct, and actually a third way of describing files.\nFor example, .doc/.xls-Datei in speech is very seldom, if at all; MS\nOffice output has had generally been called Word-Datei,\nExcel-Tabelle/-Datei and so on.\n\nWhat I meant however is that the extension is \".jpg\" (or .jpeg) from\na programming aspect (like, when naïvely trying to figure out the\nfiletype) as in\n ($name, $ext) = (/^[^\\.]+(\\..+)?/)\n"},{"id":"217509","messageId":"CAN0XMOJ7hRwTAR+i8_C2z2NmmcycLQkiya0ayfWS0vAw3-zqkg@mail.gmail.com","threadId":"33807","inReplyTo":"519370D3.3000306@web.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-16T05:57:11Z","receivedAt":"2013-05-16T05:57:11Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Hi,\n\nI think the discussion might work better via ML than GitHub.\nThis is the full glossary of git's de.po as it would look\nlike with (hopefully) all the changes included that have been\ndiscussed here. Still without any reasoning for decisions\n(except HEAD).\n\nThanks for reading.\n\n+Basic repository objects:\n+\n+ blob = Blob\n+ tree = Baum, Baum-Objekt (bevorzugt), \"Tree\"-Objekt\n+ submodule = Submodul\n+ pack(noun) = Pack-Datei\n+ pack(verb) = packen (ggf. Pack-Datei erstellen)\n+ ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt)\n+\n+Content in a repository:\n+\n+ file(s) = Datei(en)\n+ tracked file = beobachtete Datei\n+ track file = beobachte Datei\n+ untracked file = unbeobachtete Datei\n+ directory = Verzeichnis\n+\n+Repositories / tracking concepts:\n+\n+ clone (verb) = klonen\n+ clone (noun) = der Klon\n+ repository = Repository\n+\n+ bare repository = bloßes Repository\n+ working directory = Arbeitsverzeichnis\n+\n+ remote branch = externer Zweig\n+ remote tracking branch = externer Übernahmezweig\n+ upstream branch = -||-\n+ tracking branch = Übernahmezweig\n+\n+ remote repository = externes Repository\n+ remote(noun) = -||-\n+ remote(adj) = extern\n+\n+Authorship:\n+\n+ author = Autor\n+ committer = Commit-Ersteller\n+ tagger = Tag-Ersteller\n+\n+Commits, tags and other references:\n+\n+ HEAD = HEAD\n+ Konzept aus der Git-Welt, daher nicht zu übersetzen.\n+ detached HEAD = losgelöster HEAD\n+\n+ commit(noun) = Commit\n+ commit(verb) = committen\n+ commit the result = das Ergebnis committen\n+ parent commit = Eltern-Commit\n+ child commit = Kind-Commit\n+ commit message = Commit-Beschreibung\n+\n+ stash(noun) = der Stash\n+ stash(verb) = \"stashen\", \"stash\" benutzen (bevorzugt)\n+ unstash(verb) = \"unstashen\", \"zurückladen\", \"aus 'stash'\nzurückladen\" (bevorzugt)\n+\n+ reference = Referenz\n+ revision = Commit\n+ branch = Zweig (or Branch)\n+ tag(noun) = Tag\n+ tag(verb) = taggen, Tag erstellen\n+ annotated tag = annotierter Tag\n+ tag message = Tag-Beschreibung\n+\n+ orphan commit =\n+ orphan reference =\n+\n+ boundary commit = Grenz-Commit\n+ root commit = Ursprungs-Commit, Wurzel-Commit\n+\n+ stage/index (noun) = Staging-Area, Index\n+ stage/index (verb) = (für einen | zum) Commit vormerken, zur\nStaging Area hinzufügen, dem Index hinzufügen\n+ unstage (verb) = aus Staging Area entfernen/nehmen, aus Index\nentfernen/nehmen\n+\n+The DAG:\n+\n+ commit graph = Commit-Graph\n+ merge = Merge\n+\n+References in relation to other references:\n+\n+ branches that have diverged = Zweige sind divergiert\n+ diverging references = divergierte Referenzen\n+ your branch is ahead = dein Zweig ist voraus\n+ your branch is behind = dein Zweig ist hinterher\n+\n+Moving data around:\n+\n+ fetch = anfordern\n+ pull = zusammenführen\n+ push = versenden\n+\n+ fast-forward = vorspulen\n+ non-fast-forward = nicht vorspulen\n+\n+Commands:\n+\n+ log = Log\n+ interactive commit = interaktiver Commit\n+ cherry-pick = \"cherry-pick\" benutzen\n+ rebase(verb) = \"rebase\" benutzen\n+ rebase(noun) = \"rebase\"\n+ archive = archivieren\n+ revert = zurücknehmen\n+ clean(verb) =\n+ clean(noun) =\n+ merge = mergen\n+\n+ bundle(noun) = Paket\n+ bundle(verb) = Paket erstellen\n+ unbundle(verb) = Paket entpacken\n+\n+ bisect = binäre Suche\n+ bisecting = bei einer binären Suche sein, binäre Suche durchführen\n+\n+Diff/patch related:\n+\n+ diff = Differenz\n+ delta = Differenz (or Delta)\n+ patch = Patch\n+ apply = anwenden\n+ diffstat = (leave it as it is)\n+ hunk = Bereich\n+ whitespace = Leerzeichen (FIXME?) (maybe \"Leerraum\")\n+\n+Still being worked out:\n+\n+ prune = veraltete(n) Zweig(e) entfernen\n+ checkout(verb) = auschecken\n+\n+ git add = hinzufügen\n+\n+ merge conflict = Merge-Konflikt\n+ 3-way merge = 3-Wege-Merge\n+ paths = Pfade\n+\n+ symbolic link = symbolische Verknüfung\n+ path = Pfad\n+ link = Verknüpfung\n+\n+ reflog = Referenzprotokoll\n+ partial commit = teilweise committen, partiell committen\n+\n+ reset = neu setzen (maybe \"umsetzen\"?)\n+\n+ register = in die Konfiguration eintragen\n+ unregister = aus der Konfiguration austragen\n--\n"},{"id":"217538","messageId":"51949D65.7050001@ira.uka.de","threadId":"33807","inReplyTo":"CAN0XMOJ7hRwTAR+i8_C2z2NmmcycLQkiya0ayfWS0vAw3-zqkg@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-05-16T08:48:37Z","receivedAt":"2013-05-16T08:48:37Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"\n> + bare repository = bloßes Repository\n\nSince \"bloßes Rep.\" does not convey any sensible meaning to a german \nreader (at least it doesn't to me) it might as well be \"bare\". Also bare \nis used as parameter to commands\n\n> + remote tracking branch = externer Übernahmezweig\n\nAnyone used to the english client will switch as soon as he has to read \nthis. No idea how to improve that though except to just use the english \nterms like the pro git translation does.\n\n> + upstream branch = -||-\n\nUse upstream as it is used as parameter to commands\n\n> + fetch = anfordern\nfetch = fetch\n> + pull = zusammenführen\npull = pull\n> + push = versenden\npush = push\n\nestablished vocabulary used in stack programming as well as in vcs. \nShould not be translated.\n\n> + clean(verb) =\nclean(verb) = säubern/aufräumen\n> + clean(noun) =\nclean(noun) = Säuberung\n\n\"aufräumen\" is the better verb but there is no noun for it.\n\n> + whitespace = Leerzeichen (FIXME?) (maybe \"Leerraum\")\nwhitespace = whitespace\n\nThere is no german word for whitespace\n\n> +Still being worked out:\n> +\n> + prune = veraltete(n) Zweig(e) entfernen\n> + checkout(verb) = auschecken\n> +\n> + git add = hinzufügen\n\n\"mittels \"git add\" hinzufügen\" if you want to emphasize that you add \nsomething with the command\n\n> +\n> + merge conflict = Merge-Konflikt\n> + 3-way merge = 3-Wege-Merge\n> + paths = Pfade\n> +\n> + symbolic link = symbolische Verknüfung\n> + path = Pfad\n> + link = Verknüpfung\n> +\n> + reflog = Referenzprotokoll\n> + partial commit = teilweise committen, partiell committen\n\nAs a noun, \"Teil-Commit\"\n\n> +\n> + reset = neu setzen (maybe \"umsetzen\"?)\n\n\"zurücksetzen\"\n"},{"id":"217542","messageId":"87wqqze1ub.fsf@linux-k42r.v.cablecom.net","threadId":"33807","inReplyTo":"CAN0XMOJ7hRwTAR+i8_C2z2NmmcycLQkiya0ayfWS0vAw3-zqkg@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-05-16T09:00:28Z","receivedAt":"2013-05-16T09:00:28Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Ralf Thielow writes:\n\n> Hi,\n>\n> I think the discussion might work better via ML than GitHub.\n> This is the full glossary of git's de.po as it would look\n> like with (hopefully) all the changes included that have been\n> discussed here. Still without any reasoning for decisions\n> (except HEAD).\n[...]\n> + remote branch = externer Zweig\n> + remote tracking branch = externer Übernahmezweig\n\nHrm, before we (erm, you) do any extensive work on redoing the glossary,\nI think we should step back and agree on a direction.\n\nRemember what this thread started with:\n\n} However, an unfortunate and unsatisfactory situation has developed:\n} Christian Stimming's git-gui de.po uses a Ger translation, and Ralf\n} Thielow built core git's de.po on top of it, so it's also Ger.\n} \n} Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a\n} translation of pro-git (which is also quite mature at this point, having\n} apparently begun in 2009), and as you probably guessed by now, it's G+E.\n} \n} So that leaves us at a point where \"the\" libre Git book (and also the\n} one that happens to be hosted on git-scm.com, the official site) does\n} not match the terminology used by German git.\n} \n} Like, at all. They're not even remotely near each other.\n\nMy thinly veiled opinion in the thread starter was that we should redo\ngit's de.po from scratch using a translation similar to pro-git.\n\nI can accept that discussion takes a different turn, and thus the\ntranslation does something else. But my impression in the thread so far\nwas that:\n\n* Everyone voted for G+E.\n\n* The thread went of on a tangent, bikeshedding on some Ger\n translations.\n\nPlease tell me I'm wrong...\n\nOtherwise, assuming any agreement can be reached, IMHO the first step\nmust be to write/complete a glossary that matches *current usage* in\npro-git. We can perhaps bikeshed about some glaring issues in the\nresult, but remember that -- again assuming G+E is the conclusion -- any\nsuch change again either means a divergence between book and git (bad!)\nor a lot of work for the book translators.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"217580","messageId":"2181104.gkP5j47vG8@cs-pc","threadId":"33807","inReplyTo":"87k3n36nvo.fsf@linux-k42r.v.cablecom.net","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2013-05-16T10:49:13Z","receivedAt":"2013-05-16T10:49:13Z","isPatch":false,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Dear translators,\n\nHere's the main point in this discussion: The translation is not for us! The \ntranslation is for those who don't speak much English and who don't know the \nEnglish git terminology very well. By definition, this target audience is not \npresent here on this mailing list and in this discussion. Hence, arguments \nsuch as \"I like word x better\" are rather weak. Instead, stating \"Word x gives \nthe intended target audience a better picture of what is going on\" is probably \na better argument.\n\nAm Montag, 13. Mai 2013, 14:54:51 schrieb Thomas Rast:\n> However, an unfortunate and unsatisfactory situation has developed:\n> Christian Stimming's git-gui de.po uses a Ger translation, and Ralf\n> Thielow built core git's de.po on top of it, so it's also Ger.\n> \n> Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a\n> translation of pro-git (which is also quite mature at this point, having\n> apparently begun in 2009), and as you probably guessed by now, it's G+E.\n\nThanks, Thomas, for spotting the conflicting translations in those excellent \nbook projects vs. the git core and git gui. I think it's rather obvious why \nthe pro-git translators chose the G+E approach for their work: Their goal is \nto explain the command line usage of git, which means they inevitably have to \nuse the git command names, which happen to be in English (and will surely stay \nso). Hence, any translation approach will have to deal with the English \ncommand names as useful words in the normal translated text. That's probably a \nconstraint that is true for any translation of a command-line tool to stay \nuseful.\n\nI noticed with some amusement, though, that even in the pro-git book with the \ndescribed constraint there are places where a \"pure Ger\" translation is almost \nshining through... Such as in [1]: \"Jedes Mal, wenn Du committest (d.h. den \ngegenwärtigen Status deines Projektes als eine Version in Git speicherst)...\" \nCan you notice how the translators identified \"Version\" as translation for \n\"commit (noun)\" and \"speichern\" as translation for \"commit (verb)\" :-) ? Of \ncourse this is just the explanation and not the actual translation later \nduring the text. \n\nHowever, I take this spot as an example that there exist meaningful pure-Ger \ntranslations even for the most important git terminology. In fact, to find \nuseful Ger translations, I wonder how I would talk to someone from the target \naudience a sentence such as \"Finde mal den richtigen Commit, also die Version, \n...\" When I find myself saying such an \" - also das xy -\" appendix often \nenough, I take this as an indication that the latter word can just as well be \nused as the main translation.\n\nBack to the original question: I think the book shows quite nicely that for \nworking with the git command line, a G+E translation is more useful as long as \nthe command names also appear unchangedly in the translation. However, \neverything else that does not appear as a command name can be translated \neither in G+E or in Ger. The argument can go on to state that someone who is \ngeek enough to use the command line is probably more proficient in English \nlanguage anyway. Hence, using more English terms in the translation is \nprobably fine as well and a full G+E translation is probably a good approach. \n\nThe pro-git book has some places where the translated word is not always used \nconsistently (e.g. in [2] \"Externes Repository\" vs. \"Remote Repository\"), and \nsome G+E suggestions from this mailing list have been translated Ger in the \nbook (they use \"zusammenführen\" in [2] and [3] instead of \"merge\" with only a \nfew exceptions). It is also a good point to make the pro-git and git core \ntranslation consistent, once the approach is decided on.\n\n*However*: This argument is completely different when we talk about the GUI \ntools. The target audience of the git gui etc. are those developers who write \ngreat code, but #1 do not know the English language well enough, and #2 are so \nfar away from the geek corner that they use a development workflow purely in \nGUI tools. The question is: What GUI button labels helps those people the most \nto get a good picture of what is going on? And in this case I still believe a \npure Ger translation is the better choice! I wonder how feedback on this claim \ncan be collected from developers of the target audience. When I started on the \ngit-gui translation, I asked some coworkers that fall into this category for \nfeedback on the wordings, and their response indicated agreement to my \napproach. What feedback have others here heard from people who fall into \ndescribed category? At the end of the day that sort of feedback has to be the \nground for a decision on the approach in the GUI translation. \n\nIn the meantime I think a different translation approach between git core and \ngit gui is not a problem at all. For git gui I propose to stick to a Ger \ntranslation. For git core and the books that describe the command line \ninterface, a G+E translation is probably a good choice but even in this case \nthere is room for useful German words instead of taking all difficult terms \ndirectly as English ones. \n\nBy the way, I'm puzzled why this sort of discussion appears only for German \nlanguage translations and not others. Don't other languages have the same \nconflict of the English terms and potential translated words which are then \nunknown to the geeks on this list? Just curious.\n\nBest Regards,\n\nChristian\n\n\n[1] http://git-scm.com/book/de/Los-geht%27s-Git-Grundlagen\n[2] http://git-scm.com/book/de/Git-Grundlagen-Mit-externen-Repositorys-\narbeiten\n[3] http://git-scm.com/book/de/Git-Branching-Basic-Branching-and-Merging\n"},{"id":"217919","messageId":"CAN0XMO+TG7uXGPjqQZXX5KetQkf63gRtSdMxFK8r_40Dr4BGLQ@mail.gmail.com","threadId":"33807","inReplyTo":"51949D65.7050001@ira.uka.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-19T16:06:48Z","receivedAt":"2013-05-19T16:06:48Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"2013/5/16 Holger Hellmuth (IKS) :\n>\n>> + bare repository = bloßes Repository\n>\n>\n> Since \"bloßes Rep.\" does not convey any sensible meaning to a german reader\n> (at least it doesn't to me) it might as well be \"bare\". Also bare is used as\n> parameter to commands\n>\n>\n>> + remote tracking branch = externer Übernahmezweig\n>\n>\n> Anyone used to the english client will switch as soon as he has to read\n> this. No idea how to improve that though except to just use the english\n> terms like the pro git translation does.\n>\n>\n>> + upstream branch = -||-\n>\n>\n> Use upstream as it is used as parameter to commands\n>\n>> + fetch = anfordern\n>\n> fetch = fetch\n>>\n>> + pull = zusammenführen\n>\n> pull = pull\n>>\n>> + push = versenden\n>\n> push = push\n>\n> established vocabulary used in stack programming as well as in vcs. Should\n> not be translated.\n>\n\nI think the messages would become a bit too G+E when we'd say something\nlike \"Das Fetchen in den Branch...\", \"Fetche von %s\". Some for merge as\na verb.\n\n>> + clean(verb) =\n>\n> clean(verb) = säubern/aufräumen\n>>\n>> + clean(noun) =\n>\n> clean(noun) = Säuberung\n>\n> \"aufräumen\" is the better verb but there is no noun for it.\n>\n>\n>> + whitespace = Leerzeichen (FIXME?) (maybe \"Leerraum\")\n>\n> whitespace = whitespace\n>\n> There is no german word for whitespace\n>\n>\n>> +Still being worked out:\n>> +\n>> + prune = veraltete(n) Zweig(e) entfernen\n>> + checkout(verb) = auschecken\n>> +\n>> + git add = hinzufügen\n>\n>\n> \"mittels \"git add\" hinzufügen\" if you want to emphasize that you add\n> something with the command\n>\n>\n>> +\n>> + merge conflict = Merge-Konflikt\n>> + 3-way merge = 3-Wege-Merge\n>> + paths = Pfade\n>> +\n>> + symbolic link = symbolische Verknüfung\n>> + path = Pfad\n>> + link = Verknüpfung\n>> +\n>> + reflog = Referenzprotokoll\n>> + partial commit = teilweise committen, partiell committen\n>\n>\n> As a noun, \"Teil-Commit\"\n>\n>\n>> +\n>> + reset = neu setzen (maybe \"umsetzen\"?)\n>\n>\n> \"zurücksetzen\"\n>\n>\n\nI'll send a new version to the list later.\n\nThanks\n"},{"id":"217920","messageId":"CAN0XMO+jGzW7yUNytv=HJ6AQNuyzTKQ28OTEnDOnFq+w97cz-g@mail.gmail.com","threadId":"33807","inReplyTo":"87wqqze1ub.fsf@linux-k42r.v.cablecom.net","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-19T16:49:01Z","receivedAt":"2013-05-19T16:49:01Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"2013/5/16 Thomas Rast :\n> Ralf Thielow writes:\n>\n>> Hi,\n>>\n>> I think the discussion might work better via ML than GitHub.\n>> This is the full glossary of git's de.po as it would look\n>> like with (hopefully) all the changes included that have been\n>> discussed here. Still without any reasoning for decisions\n>> (except HEAD).\n> [...]\n>> + remote branch = externer Zweig\n>> + remote tracking branch = externer Übernahmezweig\n>\n> Hrm, before we (erm, you) do any extensive work on redoing the glossary,\n> I think we should step back and agree on a direction.\n>\n> Remember what this thread started with:\n>\n> } However, an unfortunate and unsatisfactory situation has developed:\n> } Christian Stimming's git-gui de.po uses a Ger translation, and Ralf\n> } Thielow built core git's de.po on top of it, so it's also Ger.\n> }\n> } Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a\n> } translation of pro-git (which is also quite mature at this point, having\n> } apparently begun in 2009), and as you probably guessed by now, it's G+E.\n> }\n> } So that leaves us at a point where \"the\" libre Git book (and also the\n> } one that happens to be hosted on git-scm.com, the official site) does\n> } not match the terminology used by German git.\n> }\n> } Like, at all. They're not even remotely near each other.\n>\n> My thinly veiled opinion in the thread starter was that we should redo\n> git's de.po from scratch using a translation similar to pro-git.\n>\n> I can accept that discussion takes a different turn, and thus the\n> translation does something else. But my impression in the thread so far\n> was that:\n>\n> * Everyone voted for G+E.\n>\n> * The thread went of on a tangent, bikeshedding on some Ger\n> translations.\n>\n> Please tell me I'm wrong...\n>\n> Otherwise, assuming any agreement can be reached, IMHO the first step\n> must be to write/complete a glossary that matches *current usage* in\n> pro-git. We can perhaps bikeshed about some glaring issues in the\n> result, but remember that -- again assuming G+E is the conclusion -- any\n> such change again either means a divergence between book and git (bad!)\n> or a lot of work for the book translators.\n>\n\nWell, that's what I'm trying to do, writing a new glossary. But I took\nthe current git's de.po glossay as the base, because it's the biggest one\nand easier to apply to de.po instead of using a complete new one.\nI tried to merge [1] (link is dead) to match ProGit-Book where it's possible.\nIMO it's OK if we don't match the ProGit-book in all terms (I didn't do it with\nintention), but it's not OK if the translations are so far away from each other\nthat it becomes a problem to the users because they're using totally different\n\"languages\".\nWhat I'm doing now is collecting objections and suggestions from others (ML, GH)\nand apply them to the glossary in order to get a version where everybody\nmore or less agree with.\n\n[1] https://github.com/progit/progit/blob/master/de/NOTES\n\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n"},{"id":"217921","messageId":"CAN0XMOKCppZVwwvowzrSDuAKRo-DMeD7GpryjA2deE5mYuSb4Q@mail.gmail.com","threadId":"33807","inReplyTo":"CAN0XMOJ7hRwTAR+i8_C2z2NmmcycLQkiya0ayfWS0vAw3-zqkg@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-19T16:53:18Z","receivedAt":"2013-05-19T16:53:18Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Hi,\n\nhere's an updated version of the glossary. Comments are appreciated.\n\nBasic repository objects:\n\n blob = Blob\n tree = Baum, Baum-Objekt (bevorzugt), \"Tree\"-Objekt\n submodule = Submodul\n pack(noun) = Pack-Datei\n pack(verb) = packen (ggf. Pack-Datei erstellen)\n ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt)\n\nContent in a repository:\n\n file(s) = Datei(en)\n tracked file = beobachtete Datei\n track file = beobachte Datei\n untracked file = unbeobachtete Datei\n directory = Verzeichnis\n\nRepositories / tracking concepts:\n\n clone (verb) = klonen\n clone (noun) = der Klon\n repository = Repository\n bare repository = Bare Repository\n working directory = Arbeitsverzeichnis\n working tree = -||-\n\n remote branch = Remote-Branch\n remote-tracking branch = Remote-Tracking-Branch\n upstream branch = Upstream-Branch\n\n remote repository = Remote-Repository\n remote(noun) = -||-\n remote(adj) = extern, entfernt liegend\n\nAuthorship:\n\n author = Autor\n committer = Commit-Ersteller\n tagger = Tag-Ersteller\n\nCommits, tags and other references:\n\n HEAD = HEAD\nKonzept aus der Git-Welt, daher nicht zu übersetzen.\n detached HEAD = losgelöster HEAD\n\n commit(noun) = Commit\n commit(verb) = committen\n commit the result = das Ergebnis committen\n parent commit = Eltern-Commit\n child commit = Kind-Commit\n commit message = Commit-Beschreibung\n\n stash(noun) = der Stash\n stash(verb) = \"stashen\", \"stash\" benutzen (bevorzugt)\n unstash(verb) = \"unstashen\", \"zurückladen\", \"aus 'stash'\nzurückladen\" (bevorzugt)\n\n reference = Referenz\n revision = Commit\n branch = Branch\n tag(noun) = Tag\n tag(verb) = taggen, Tag erstellen\n annotated tag = annotierter Tag\n tag message = Tag-Beschreibung\n\n orphan commit =\n orphan reference =\n\n boundary commit = Grenz-Commit\n root commit = Ursprungs-Commit, Wurzel-Commit\n\n stage/index (noun) = Staging-Area, Index\n stage/index (verb) = (für einen | zum) Commit vormerken\n(bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen\n unstage (verb) = aus Staging Area entfernen, aus Index entfernen\n\nThe DAG:\n\n commit graph = Commit-Graph\n merge = Merge\n\nReferences in relation to other references:\n\n branches that have diverged = Branches sind divergiert\n diverging references = divergierte Referenzen\n your branch is ahead = Ihr Branch ist voraus\n your branch is behind = Ihr Branch ist hinterher\n\nMoving data around:\n\n fetch = anfordern\n pull = zusammenführen\n push = versenden\n\n fast-forward = vorspulen\n non-fast-forward = nicht vorspulen\n\nCommands:\n\n log = Log\n interactive commit = interaktiver Commit\n cherry-pick = \"cherry-pick\" benutzen\n rebase(verb) = \"rebase\" benutzen\n rebase(noun) = \"rebase\"\n archive = archivieren\n revert = zurücknehmen\n clean(verb) = säubern/aufräumen\n clean(noun) = Säuberung\n merge = zusammenführen\n\n bundle(noun) = Paket\n bundle(verb) = Paket erstellen\n unbundle(verb) = Paket entpacken\n\n bisect = binäre Suche\n bisecting = bei einer binären Suche sein, binäre Suche durchführen\n\nDiff/patch related:\n\n diff = Differenz\n delta = Differenz (or Delta)\n patch = Patch\n apply = anwenden\n diffstat = (leave it as it is)\n hunk = Bereich\n whitespace = Whitespace\n\nStill being worked out:\n\n prune = veraltete(n) Branch(es) entfernen\n checkout(verb) = auschecken\n\n git add = hinzufügen\n\n merge conflict = Merge-Konflikt\n 3-way merge = 3-Wege-Merge\n paths = Pfade\n\n symbolic link = symbolische Verknüfung\n path = Pfad\n link = Verknüpfung\n\n reflog = Referenzprotokoll\n partial commit (verb) = teilweise committen, partiell committen\n partial commit (noun) = Teil-Commit\n\n reset = neu setzen (maybe \"umsetzen\"?)\n\n register = in die Konfiguration eintragen\n unregister = aus der Konfiguration austragen\n"},{"id":"217922","messageId":"CAN0XMOJutVZ9ZX-0a=T38AnzH9SQN=X_pu-6+tTRifbL-zQigg@mail.gmail.com","threadId":"33807","inReplyTo":"51949D65.7050001@ira.uka.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-19T16:56:15Z","receivedAt":"2013-05-19T16:56:15Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"2013/5/16 Holger Hellmuth (IKS) :\n>\n[...]\n>> + reset = neu setzen (maybe \"umsetzen\"?)\n>\n>\n> \"zurücksetzen\"\n>\n\n\"reset\" can be used with every existing commit. \"zurücksetzen\"\nwould imply that it have to be a recent commit, no?\n"},{"id":"217952","messageId":"51999FFF.8090004@gspranz.de","threadId":"33807","inReplyTo":"CAN0XMOJutVZ9ZX-0a=T38AnzH9SQN=X_pu-6+tTRifbL-zQigg@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Holger Hellmuth","fromEmail":"holger@gspranz.de","sentAt":"2013-05-20T04:01:03Z","receivedAt":"2013-05-20T04:01:03Z","isPatch":false,"sender":{"key":"holger@gspranz.de","avatar":null},"body":"Am 19.05.2013 18:56, schrieb Ralf Thielow:\n> 2013/5/16 Holger Hellmuth (IKS) :\n>>\n> [...]\n>>> + reset = neu setzen (maybe \"umsetzen\"?)\n>>\n>>\n>> \"zurücksetzen\"\n>>\n>\n> \"reset\" can be used with every existing commit. \"zurücksetzen\"\n> would imply that it have to be a recent commit, no?\n\nIt implies that it sets to something that already existed or came before.\nSo it even fits in a case where you reset to an older commit and reset \nback to HEAD because the HEAD commit existed already.\n\nIf you still don't like it, I would prefer \"umsetzen\" to \"neu setzen\".\n"},{"id":"217994","messageId":"7402110.vsgz8zEiin@cs-pc","threadId":"33807","inReplyTo":"CAN0XMOKCppZVwwvowzrSDuAKRo-DMeD7GpryjA2deE5mYuSb4Q@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2013-05-20T19:41:48Z","receivedAt":"2013-05-20T19:41:48Z","isPatch":false,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Thanks for the update. I would like to add some comments on this G+E glossary \nand I hope you are interested in reading those, even though it is known that I \nprefer a \"pure Ger\" translation. However, as I wrote in my other message I \nagree that for the command line tool the criteria for choosing the translation \napproach are different from those for a GUI tool. So I can very well envision \na good G+E translation for git core and subsequently all related books.\n\nAm Sonntag, 19. Mai 2013, 18:53:18 schrieb Ralf Thielow:\n> Basic repository objects:\n> \n> blob = Blob\n> tree = Baum, Baum-Objekt (bevorzugt), \"Tree\"-Objekt\n> submodule = Submodul\n> pack(noun) = Pack-Datei\n> pack(verb) = packen (ggf. Pack-Datei erstellen)\n> ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt)\n\nYes. Does the \"Pack-Datei\" appear anywhere in the book? I wouldn't understand \nthe term, but then again, this is probably because I don't understand the \nsemantic of this thingy as a repository object regardless of the language...\n\n> Content in a repository:\n> \n> file(s) = Datei(en)\n> tracked file = beobachtete Datei\n> track file = beobachte Datei\n> untracked file = unbeobachtete Datei\n> directory = Verzeichnis\n\nYes.\n\n> Repositories / tracking concepts:\n> \n> clone (verb) = klonen\n> clone (noun) = der Klon\n> repository = Repository\n> bare repository = Bare Repository\n\nYes. After some evaluation of the git-gui translation I think using \n\"Repository\" there as well is probably the better choice.\n\n> working directory = Arbeitsverzeichnis\n> working tree = -||-\n> \n> remote branch = Remote-Branch\n> remote-tracking branch = Remote-Tracking-Branch\n> upstream branch = Upstream-Branch\n\nYes. What's the main reason for using \"Branch\" in the German text? Consistency \nwith the commands, or assumed familiarity of the term within the target \naudience? \"Zweig\" is available.\n\n> remote repository = Remote-Repository\n> remote(noun) = -||-\n> remote(adj) = extern, entfernt liegend\n> \n> Authorship:\n> \n> author = Autor\n> committer = Commit-Ersteller\n> tagger = Tag-Ersteller\n\nYes.\n\n> Commits, tags and other references:\n> \n> HEAD = HEAD\n> Konzept aus der Git-Welt, daher nicht zu übersetzen.\n> detached HEAD = losgelöster HEAD\n> \n> commit(noun) = Commit\n> commit(verb) = committen\n> commit the result = das Ergebnis committen\n> parent commit = Eltern-Commit\n> child commit = Kind-Commit\n> commit message = Commit-Beschreibung\n\nYes, for the G+E approach.\n\n> stash(noun) = der Stash\n> stash(verb) = \"stashen\", \"stash\" benutzen (bevorzugt)\n> unstash(verb) = \"unstashen\", \"zurückladen\", \"aus 'stash'\n> zurückladen\" (bevorzugt)\n\nUsing \"Stash\" in G+E is quite ugly, but the noun is probably unavoidable \nbecause the feature is pretty much unique to git. I'd suggest to use only the \nnoun and use the verbs as \"stash benutzen\" and \"aus stash zurückladen\" as \nproposed.\n\n> reference = Referenz\n> revision = Commit\n> branch = Branch\n> tag(noun) = Tag\n> tag(verb) = taggen, Tag erstellen\n> annotated tag = annotierter Tag\n> tag message = Tag-Beschreibung\n\nI've commented on \"Branch\" above. As for \"Tag\": Yes, the term is familiar \namong the target audience. However, do you really want this noun which is the \nsame word as \"Tag wie in Datum\"? Some more disambiguation between the tag and \nthe date would be helpful, wouldn't it?\nThe derived forms are fine, and also here I'd suggest to use only the G+E noun \nbut construct the verbs with other German words: \"Tag erstellen\".\n\n> stage/index (noun) = Staging-Area, Index\n> stage/index (verb) = (für einen | zum) Commit vormerken\n> (bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen\n> unstage (verb) = aus Staging Area entfernen, aus Index entfernen\n\nI'd strongly suggest not to use \"Index\". I've never understood why this term \nshowed up in the English wording to begin with. It took me years until I got \nthe point that from the user's point of view, this thingy has nothing to do \nwith a book's index or a database's index, which is where I go to look up more \ninformation about a keyword. It is a big improvement to use \"staging area\" on \nthe English side. If it has to be an English word due to consistency with the \ncommands, I'd suggest \"Staging-Area\" or \"Staging-Bereich\". For the verb I'd \nagree to keep only the noun in English but construct the verb with German \nverbs, like already proposed here.\n\n> Moving data around:\n> \n> fetch = anfordern\n> pull = zusammenführen\n> push = versenden\n> \n> fast-forward = vorspulen\n> non-fast-forward = nicht vorspulen\n\nIMHO yes, and the German terms make me even understand what is going on. (On \nthe English side it took me ages to memorize the difference between fetch and \npull, as the words don't offer any difference in meaning. But that's a \ndifferent story.) However, you probably get a hard time here when explaining \nhow to keep consistency with the command names: It isn't clear for the user \nwhy \"fetch\" should be the command name related to \"anfordern\" but \"pull\" is \nnot. This unfortunately probably means you have to introduce the words \"pull\" \nand \"fetch\" somewhere in the German text.\n\n> Commands:\n> \n> log = Log\n> interactive commit = interaktiver Commit\n> cherry-pick = \"cherry-pick\" benutzen\n> rebase(verb) = \"rebase\" benutzen\n> rebase(noun) = \"rebase\"\n> archive = archivieren\n> revert = zurücknehmen\n> clean(verb) = säubern/aufräumen\n> clean(noun) = Säuberung\n> merge = zusammenführen\n\nYes. (I'd hope to see some German word for \"cherry-pick\" and \"rebase\" \n(\"pflücken\" and \"neu aufbauen\"), but then again, in G+E you probably keep that \nwords.)\n\n> bundle(noun) = Paket\n> bundle(verb) = Paket erstellen\n> unbundle(verb) = Paket entpacken\n> \n> bisect = binäre Suche\n> bisecting = bei einer binären Suche sein, binäre Suche\n> durchführen\n\nYes\n\n> Diff/patch related:\n> \n> diff = Differenz\n> delta = Differenz (or Delta)\n> patch = Patch\n> apply = anwenden\n> diffstat = (leave it as it is)\n> hunk = Bereich\n\nIMHO \"Kontext\" is better if you use a German word. Technically the context is \nsomething else, but in a German text IMHO it fits nicer when explaining to the \nuser where he/she can select the n-th hunk.\n\n> whitespace = Whitespace\n\nYes. Indeed I haven't heard a good German word that transports the same \nmeaning.\n\n\n> Still being worked out:\n> \n> prune = veraltete(n) Branch(es) entfernen\n\nYes, and it makes me even understand what the command is about to do.\n\n> checkout(verb) = auschecken\n> \n> git add = hinzufügen\n> \n> merge conflict = Merge-Konflikt\n> 3-way merge = 3-Wege-Merge\n\nIf merge was \"zusammenführen\" above, it should be \"Zusammenführungs-Konflikt\" \nhere, and \"3-Wege-Zusammenführung\".\n\n> paths = Pfade\n> \n> symbolic link = symbolische Verknüfung\n> path = Pfad\n> link = Verknüpfung\n> \n> reflog = Referenzprotokoll\n> partial commit (verb) = teilweise committen, partiell committen\n\nTeilweise committen. (No partial derivatives here...)\n\n> partial commit (noun) = Teil-Commit\n> \n> reset = neu setzen (maybe \"umsetzen\"?)\n> \n> register = in die Konfiguration eintragen\n> unregister = aus der Konfiguration austragen\n\nBest Regards,\n\nChristian\n"},{"id":"218177","messageId":"CAN0XMOJuWTZLOYHafjZTBkazV2diuT_ZfD551kMZz-XQUBg66g@mail.gmail.com","threadId":"33807","inReplyTo":"51999FFF.8090004@gspranz.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-22T14:09:31Z","receivedAt":"2013-05-22T14:09:31Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"2013/5/20 Holger Hellmuth :\n> Am 19.05.2013 18:56, schrieb Ralf Thielow:\n>\n>> 2013/5/16 Holger Hellmuth (IKS) :\n>>>\n>>>\n>> [...]\n>>>>\n>>>> + reset = neu setzen (maybe \"umsetzen\"?)\n>>>\n>>>\n>>>\n>>> \"zurücksetzen\"\n>>>\n>>\n>> \"reset\" can be used with every existing commit. \"zurücksetzen\"\n>> would imply that it have to be a recent commit, no?\n>\n>\n> It implies that it sets to something that already existed or came before.\n> So it even fits in a case where you reset to an older commit and reset back\n> to HEAD because the HEAD commit existed already.\n>\n> If you still don't like it, I would prefer \"umsetzen\" to \"neu setzen\".\n>\n\nI'd still understand \"zurücksetzen\" as \"set something *back* to\" but this\n\"back\" can also be something that was made after HEAD perhaps on\nanother branch and HEAD (or the current ref) was never at this point before,\nso \"zurücksetzen\" is not true in this case.\n\nI prefer \"umsetzen\" to \"neu setzen\", too. I'll change the glossary to this.\n\nThanks\n\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"218184","messageId":"CAN0XMOK4oniunZz5KpC1x=JrY4yH4HnecxMSCyPF+kEyYRRjTw@mail.gmail.com","threadId":"33807","inReplyTo":"7402110.vsgz8zEiin@cs-pc","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-22T15:16:54Z","receivedAt":"2013-05-22T15:16:54Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"2013/5/20 Christian Stimming :\n> Thanks for the update. I would like to add some comments on this G+E glossary\n> and I hope you are interested in reading those, even though it is known that I\n> prefer a \"pure Ger\" translation. However, as I wrote in my other message I\n> agree that for the command line tool the criteria for choosing the translation\n> approach are different from those for a GUI tool. So I can very well envision\n> a good G+E translation for git core and subsequently all related books.\n>\n\nThanks for your comments.\n\n> Am Sonntag, 19. Mai 2013, 18:53:18 schrieb Ralf Thielow:\n>> Basic repository objects:\n>>\n>> blob = Blob\n>> tree = Baum, Baum-Objekt (bevorzugt), \"Tree\"-Objekt\n>> submodule = Submodul\n>> pack(noun) = Pack-Datei\n>> pack(verb) = packen (ggf. Pack-Datei erstellen)\n>> ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt)\n>\n> Yes. Does the \"Pack-Datei\" appear anywhere in the book? I wouldn't understand\n> the term, but then again, this is probably because I don't understand the\n> semantic of this thingy as a repository object regardless of the language...\n>\n\nThe book has this word in it's index (\"9.4 Pack-Dateien\")\nhttp://git-scm.com/book/de\nso we're fine here.\n\nWhile at there, I just read \"Die Refspec\" in the index. The current glossary\ndoesn't contain \"refspec\" and we translate is as \"Referenzspezifikation\".\nSo if we want to match the book, we should add \"refspec = Refspec\" to\nthe glossary.\n\n>> Content in a repository:\n>>\n>> file(s) = Datei(en)\n>> tracked file = beobachtete Datei\n>> track file = beobachte Datei\n>> untracked file = unbeobachtete Datei\n>> directory = Verzeichnis\n>\n> Yes.\n>\n>> Repositories / tracking concepts:\n>>\n>> clone (verb) = klonen\n>> clone (noun) = der Klon\n>> repository = Repository\n>> bare repository = Bare Repository\n>\n> Yes. After some evaluation of the git-gui translation I think using\n> \"Repository\" there as well is probably the better choice.\n>\n>> working directory = Arbeitsverzeichnis\n>> working tree = -||-\n>>\n>> remote branch = Remote-Branch\n>> remote-tracking branch = Remote-Tracking-Branch\n>> upstream branch = Upstream-Branch\n>\n> Yes. What's the main reason for using \"Branch\" in the German text? Consistency\n> with the commands, or assumed familiarity of the term within the target\n> audience? \"Zweig\" is available.\n>\n\nI think it's at the same level as \"Commit\" and a well known SCM-term. Users\n(even beginners) who know \"Commit\" and \"Tag\" do also know \"Branch\". And\nI think it sounds better in combination with \"Remote-\", \"Remote-Tracking-\" and\n\"Upstream-\" which are english words.\n\n>> remote repository = Remote-Repository\n>> remote(noun) = -||-\n>> remote(adj) = extern, entfernt liegend\n>>\n>> Authorship:\n>>\n>> author = Autor\n>> committer = Commit-Ersteller\n>> tagger = Tag-Ersteller\n>\n> Yes.\n>\n>> Commits, tags and other references:\n>>\n>> HEAD = HEAD\n>> Konzept aus der Git-Welt, daher nicht zu übersetzen.\n>> detached HEAD = losgelöster HEAD\n>>\n>> commit(noun) = Commit\n>> commit(verb) = committen\n>> commit the result = das Ergebnis committen\n>> parent commit = Eltern-Commit\n>> child commit = Kind-Commit\n>> commit message = Commit-Beschreibung\n>\n> Yes, for the G+E approach.\n>\n>> stash(noun) = der Stash\n>> stash(verb) = \"stashen\", \"stash\" benutzen (bevorzugt)\n>> unstash(verb) = \"unstashen\", \"zurückladen\", \"aus 'stash'\n>> zurückladen\" (bevorzugt)\n>\n> Using \"Stash\" in G+E is quite ugly, but the noun is probably unavoidable\n> because the feature is pretty much unique to git. I'd suggest to use only the\n> noun and use the verbs as \"stash benutzen\" and \"aus stash zurückladen\" as\n> proposed.\n>\n\nYes.\n\n>> reference = Referenz\n>> revision = Commit\n>> branch = Branch\n>> tag(noun) = Tag\n>> tag(verb) = taggen, Tag erstellen\n>> annotated tag = annotierter Tag\n>> tag message = Tag-Beschreibung\n>\n> I've commented on \"Branch\" above. As for \"Tag\": Yes, the term is familiar\n> among the target audience. However, do you really want this noun which is the\n> same word as \"Tag wie in Datum\"? Some more disambiguation between the tag and\n> the date would be helpful, wouldn't it?\n> The derived forms are fine, and also here I'd suggest to use only the G+E noun\n> but construct the verbs with other German words: \"Tag erstellen\".\n>\n>> stage/index (noun) = Staging-Area, Index\n>> stage/index (verb) = (für einen | zum) Commit vormerken\n>> (bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen\n>> unstage (verb) = aus Staging Area entfernen, aus Index entfernen\n>\n> I'd strongly suggest not to use \"Index\". I've never understood why this term\n> showed up in the English wording to begin with. It took me years until I got\n> the point that from the user's point of view, this thingy has nothing to do\n> with a book's index or a database's index, which is where I go to look up more\n> information about a keyword. It is a big improvement to use \"staging area\" on\n> the English side. If it has to be an English word due to consistency with the\n> commands, I'd suggest \"Staging-Area\" or \"Staging-Bereich\". For the verb I'd\n> agree to keep only the noun in English but construct the verb with German\n> verbs, like already proposed here.\n>\n\nYes.\n\n>> Moving data around:\n>>\n>> fetch = anfordern\n>> pull = zusammenführen\n>> push = versenden\n>>\n>> fast-forward = vorspulen\n>> non-fast-forward = nicht vorspulen\n>\n> IMHO yes, and the German terms make me even understand what is going on. (On\n> the English side it took me ages to memorize the difference between fetch and\n> pull, as the words don't offer any difference in meaning. But that's a\n> different story.) However, you probably get a hard time here when explaining\n> how to keep consistency with the command names: It isn't clear for the user\n> why \"fetch\" should be the command name related to \"anfordern\" but \"pull\" is\n> not. This unfortunately probably means you have to introduce the words \"pull\"\n> and \"fetch\" somewhere in the German text.\n>\n\nUnfortunately, I don't know a place where we could introduce\nsomething. After looking\nthrough git's de.po, I didn't found a message where \"pull\" is\ntranslated. But I've\nfound\nmsgid \"Pull is not possible ...\nmsgstr \"\\\"pull\\\" ist nicht möglich\n:)\nBut, for example, \"fetch\" is used in help messages for options, e.g.\nmsgid \"fetch from all remotes\"\nmsgstr \"fordert von allen externen Projektarchiven an\"\n(same for push). In other messages, the translation is in the same message\nas the command itself. I think it's OK when we just use \"fetch\" and \"push\"\nwhen the command is meant (as it's done for \"pull\", e.g. in error messages),\nand the translation when the messages tell what the command is doing (e.g. help\nmessages). So it would depends on the message whether we translate the word\nor not. This would apply to other terms that are commands, too, like\n\"clean\" or \"revert\".\n\n>> Commands:\n>>\n>> log = Log\n>> interactive commit = interaktiver Commit\n>> cherry-pick = \"cherry-pick\" benutzen\n>> rebase(verb) = \"rebase\" benutzen\n>> rebase(noun) = \"rebase\"\n>> archive = archivieren\n>> revert = zurücknehmen\n>> clean(verb) = säubern/aufräumen\n>> clean(noun) = Säuberung\n>> merge = zusammenführen\n>\n> Yes. (I'd hope to see some German word for \"cherry-pick\" and \"rebase\"\n> (\"pflücken\" and \"neu aufbauen\"), but then again, in G+E you probably keep that\n> words.)\n>\n>> bundle(noun) = Paket\n>> bundle(verb) = Paket erstellen\n>> unbundle(verb) = Paket entpacken\n>>\n>> bisect = binäre Suche\n>> bisecting = bei einer binären Suche sein, binäre Suche\n>> durchführen\n>\n> Yes\n>\n>> Diff/patch related:\n>>\n>> diff = Differenz\n>> delta = Differenz (or Delta)\n>> patch = Patch\n>> apply = anwenden\n>> diffstat = (leave it as it is)\n>> hunk = Bereich\n>\n> IMHO \"Kontext\" is better if you use a German word. Technically the context is\n> something else, but in a German text IMHO it fits nicer when explaining to the\n> user where he/she can select the n-th hunk.\n>\n\nNot sure if German users would know what \"hunk\" means, in case we\nleave it untranslated. And I'm not sure if I would understand \"Kontext\".\nI tend to leave it untranslated.\n\n>> whitespace = Whitespace\n>\n> Yes. Indeed I haven't heard a good German word that transports the same\n> meaning.\n>\n>\n>> Still being worked out:\n>>\n>> prune = veraltete(n) Branch(es) entfernen\n>\n> Yes, and it makes me even understand what the command is about to do.\n>\n>> checkout(verb) = auschecken\n>>\n>> git add = hinzufügen\n>>\n>> merge conflict = Merge-Konflikt\n>> 3-way merge = 3-Wege-Merge\n>\n> If merge was \"zusammenführen\" above, it should be \"Zusammenführungs-Konflikt\"\n> here, and \"3-Wege-Zusammenführung\".\n>\n\nYes.\n\n>> paths = Pfade\n>>\n>> symbolic link = symbolische Verknüfung\n>> path = Pfad\n>> link = Verknüpfung\n>>\n>> reflog = Referenzprotokoll\n>> partial commit (verb) = teilweise committen, partiell committen\n>\n> Teilweise committen. (No partial derivatives here...)\n>\n\nYes.\n\n>> partial commit (noun) = Teil-Commit\n>>\n>> reset = neu setzen (maybe \"umsetzen\"?)\n>>\n>> register = in die Konfiguration eintragen\n>> unregister = aus der Konfiguration austragen\n>\n> Best Regards,\n>\n> Christian\n"},{"id":"218186","messageId":"519CE9AA.9010502@ira.uka.de","threadId":"33807","inReplyTo":"CAN0XMOK4oniunZz5KpC1x=JrY4yH4HnecxMSCyPF+kEyYRRjTw@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-05-22T15:52:10Z","receivedAt":"2013-05-22T15:52:10Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 22.05.2013 17:16, schrieb Ralf Thielow:\n>>> hunk = Bereich\n>>\n>> IMHO \"Kontext\" is better if you use a German word. Technically the context is\n>> something else, but in a German text IMHO it fits nicer when explaining to the\n>> user where he/she can select the n-th hunk.\n>>\n>\n> Not sure if German users would know what \"hunk\" means, in case we\n> leave it untranslated. And I'm not sure if I would understand \"Kontext\".\n> I tend to leave it untranslated.\n\nI don't think \"Bereich\" is a bad choice. As \"hunk\" is not a word with \nspecial meaning in cvs and not used in any commands I don't see a lot of \nreasons to keep it in english.\n\nAlternative translations might be \"Teilbereich\", \"Dateibereich\". \n\"Kontext\" would be very confusing IMHO\n"},{"id":"218191","messageId":"alpine.LNX.2.01.1305221842430.8918@nerf07.vanv.qr","threadId":"33807","inReplyTo":"519CE9AA.9010502@ira.uka.de","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-05-22T16:43:29Z","receivedAt":"2013-05-22T16:43:29Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote:\n>>\n>> Not sure if German users would know what \"hunk\" means, in case we\n>> leave it untranslated. And I'm not sure if I would understand \"Kontext\".\n>> I tend to leave it untranslated.\n>\n> I don't think \"Bereich\" is a bad choice. As \"hunk\" is not a word with special\n> meaning in cvs and not used in any commands I don't see a lot of reasons to\n> keep it in english.\n\nhunk is chunk without a c, but otherwise with pretty much the same meaning.\nEspecially when it rejects :)\n"},{"id":"218294","messageId":"20130523181615.GB3270@client.brlink.eu","threadId":"33807","inReplyTo":"CAN0XMOK4oniunZz5KpC1x=JrY4yH4HnecxMSCyPF+kEyYRRjTw@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Bernhard R. Link","fromEmail":"brl+git@mail.brlink.eu","sentAt":"2013-05-23T18:16:16Z","receivedAt":"2013-05-23T18:16:16Z","isPatch":false,"sender":{"key":"brl+git@mail.brlink.eu","avatar":null},"body":"* Ralf Thielow [130522 17:17]:\n> >> remote branch = Remote-Branch\n> >> remote-tracking branch = Remote-Tracking-Branch\n> >> upstream branch = Upstream-Branch\n> >\n> > Yes. What's the main reason for using \"Branch\" in the German text? Consistency\n> > with the commands, or assumed familiarity of the term within the target\n> > audience? \"Zweig\" is available.\n> >\n> \n> I think it's at the same level as \"Commit\" and a well known SCM-term. Users\n> (even beginners) who know \"Commit\" and \"Tag\" do also know \"Branch\". And\n> I think it sounds better in combination with \"Remote-\", \"Remote-Tracking-\" and\n> \"Upstream-\" which are english words.\n\nAdditionally \"Zweig\" might be a bit misleading. A branch is not part of\nthe \"tree\"s. It is called branch because in other VCSes the commits\nbuild a tree and a any commit outside of the main branch of that tree is\npart of exactly one different branch (so the head of that branch and the\nbranch are synonymns). With git the commits are no longer a tree, so a\ngit-branch is no branch and does not describe the whole branch of the\ntree of commits but is just a names pointer into the graph of commits.\nAs it lost all meanings of the original word \"branch\", translating it\nwith a translation of the original English word might more confusion\nthan helping anyone.\n\n> (same for push). In other messages, the translation is in the same message\n> as the command itself. I think it's OK when we just use \"fetch\" and \"push\"\n> when the command is meant (as it's done for \"pull\", e.g. in error messages),\n> and the translation when the messages tell what the command is doing (e.g. help\n> messages). So it would depends on the message whether we translate the word\n> or not. This would apply to other terms that are commands, too, like\n> \"clean\" or \"revert\".\n\nI'd not call it \"OK\". It's the only sane possibility. If you speak\nabout the magic keyword you have to give the command line, you won't\ntranslate it, of course[1]. (The obvious interesting case is where the\nEnglish text plays with the command name having a meaning as word\nitself. Here the translation will have to diverge to differentiate\nbetween both (or sacrifice one of them, where it is not important)).\n\n[1] Unlike you want to introduce a translated command line interface,\nlike \"Depp anfordere Herkunft Original\" instead of \"git fetch origin master\"\n\n> >> diff = Differenz\n> >> delta = Differenz (or Delta)\n> >> patch = Patch\n> >> apply = anwenden\n> >> diffstat = (leave it as it is)\n> >> hunk = Bereich\n> >\n> > IMHO \"Kontext\" is better if you use a German word. Technically the context is\n> > something else, but in a German text IMHO it fits nicer when explaining to the\n> > user where he/she can select the n-th hunk.\n> >\n>\n> Not sure if German users would know what \"hunk\" means, in case we\n> leave it untranslated. And I'm not sure if I would understand \"Kontext\".\n> I tend to leave it untranslated.\n\nAnyone found a German translation of the Patch manpage? Translating the\nEnglish word-play here, I'd suggest \"Block\" or \"Patch-Block\".\n\n> >> paths = Pfade\n> >>\n> >> symbolic link = symbolische Verknüfung\n> >> path = Pfad\n> >> link = Verknüpfung\n\nIn the filesystem a \"Link\" is a \"Verweis\" in Unix, not a \"Verknüpfung\"\n(that are usually the pseudo-links Windows supports).\n\n Bernhard R. Link\n"},{"id":"218393","messageId":"CAN0XMOJn7jW_7FUpEvdSc4X0oop4VWm83vVq6Usu3O5EBJupjw@mail.gmail.com","threadId":"33807","inReplyTo":"20130523181615.GB3270@client.brlink.eu","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-24T16:41:45Z","receivedAt":"2013-05-24T16:41:45Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"2013/5/23 Bernhard R. Link :\n> * Ralf Thielow [130522 17:17]:\n>> >> remote branch = Remote-Branch\n>> >> remote-tracking branch = Remote-Tracking-Branch\n>> >> upstream branch = Upstream-Branch\n>> >\n>> > Yes. What's the main reason for using \"Branch\" in the German text? Consistency\n>> > with the commands, or assumed familiarity of the term within the target\n>> > audience? \"Zweig\" is available.\n>> >\n>>\n>> I think it's at the same level as \"Commit\" and a well known SCM-term. Users\n>> (even beginners) who know \"Commit\" and \"Tag\" do also know \"Branch\". And\n>> I think it sounds better in combination with \"Remote-\", \"Remote-Tracking-\" and\n>> \"Upstream-\" which are english words.\n>\n> Additionally \"Zweig\" might be a bit misleading. A branch is not part of\n> the \"tree\"s. It is called branch because in other VCSes the commits\n> build a tree and a any commit outside of the main branch of that tree is\n> part of exactly one different branch (so the head of that branch and the\n> branch are synonymns). With git the commits are no longer a tree, so a\n> git-branch is no branch and does not describe the whole branch of the\n> tree of commits but is just a names pointer into the graph of commits.\n> As it lost all meanings of the original word \"branch\", translating it\n> with a translation of the original English word might more confusion\n> than helping anyone.\n>\n>> (same for push). In other messages, the translation is in the same message\n>> as the command itself. I think it's OK when we just use \"fetch\" and \"push\"\n>> when the command is meant (as it's done for \"pull\", e.g. in error messages),\n>> and the translation when the messages tell what the command is doing (e.g. help\n>> messages). So it would depends on the message whether we translate the word\n>> or not. This would apply to other terms that are commands, too, like\n>> \"clean\" or \"revert\".\n>\n> I'd not call it \"OK\". It's the only sane possibility. If you speak\n> about the magic keyword you have to give the command line, you won't\n> translate it, of course[1]. (The obvious interesting case is where the\n> English text plays with the command name having a meaning as word\n> itself. Here the translation will have to diverge to differentiate\n> between both (or sacrifice one of them, where it is not important)).\n>\n> [1] Unlike you want to introduce a translated command line interface,\n> like \"Depp anfordere Herkunft Original\" instead of \"git fetch origin master\"\n>\n>> >> diff = Differenz\n>> >> delta = Differenz (or Delta)\n>> >> patch = Patch\n>> >> apply = anwenden\n>> >> diffstat = (leave it as it is)\n>> >> hunk = Bereich\n>> >\n>> > IMHO \"Kontext\" is better if you use a German word. Technically the context is\n>> > something else, but in a German text IMHO it fits nicer when explaining to the\n>> > user where he/she can select the n-th hunk.\n>> >\n>>\n>> Not sure if German users would know what \"hunk\" means, in case we\n>> leave it untranslated. And I'm not sure if I would understand \"Kontext\".\n>> I tend to leave it untranslated.\n>\n> Anyone found a German translation of the Patch manpage? Translating the\n> English word-play here, I'd suggest \"Block\" or \"Patch-Block\".\n>\n>> >> paths = Pfade\n>> >>\n>> >> symbolic link = symbolische Verknüfung\n>> >> path = Pfad\n>> >> link = Verknüpfung\n>\n> In the filesystem a \"Link\" is a \"Verweis\" in Unix, not a \"Verknüpfung\"\n> (that are usually the pseudo-links Windows supports).\n>\n> Bernhard R. Link\n\nThanks.\n"},{"id":"218394","messageId":"CAN0XMOKwwDmq9WqrJDzknMCxT0AxkBKLYDwKeEN4vg+vzBwmTA@mail.gmail.com","threadId":"33807","inReplyTo":"CAN0XMOKCppZVwwvowzrSDuAKRo-DMeD7GpryjA2deE5mYuSb4Q@mail.gmail.com","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-05-24T16:51:13Z","receivedAt":"2013-05-24T16:51:13Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Hi all,\n\nthanks for all your comments. Here's an updated version of the glossary\nincluding (hopefully) all the changes you've suggested.\n\nBasic repository objects:\n\n blob = Blob\n tree = Baum-Objekt (bevorzugt), \"Tree\"-Objekt\n submodule = Submodul\n pack(noun) = Pack-Datei\n pack(verb) = Pack-Datei erstellen\n ancestor = Vorgänger-Commit\n\nContent in a repository:\n\n file(s) = Datei(en)\n tracked file = beobachtete Datei\n track file = beobachte Datei\n untracked file = unbeobachtete Datei\n directory = Verzeichnis\n\nRepositories / tracking concepts:\n\n clone (verb) = klonen\n clone (noun) = der Klon\n repository = Repository\n bare repository = Bare Repository\n working directory = Arbeitsverzeichnis\n working tree = -||-\n\n remote branch = Remote-Branch\n remote-tracking branch = Remote-Tracking-Branch\n upstream branch = Upstream-Branch\n\n remote repository = Remote-Repository\n remote(noun) = -||-\n remote(adj) = extern, entfernt liegend\n\nAuthorship:\n\n author = Autor\n committer = Commit-Ersteller\n tagger = Tag-Ersteller\n\nCommits, tags and other references:\n\n HEAD = HEAD\nKonzept aus der Git-Welt, daher nicht zu übersetzen.\n detached HEAD = losgelöster HEAD\n\n commit(noun) = Commit\n commit(verb) = committen\n commit the result = das Ergebnis committen\n parent commit = Eltern-Commit\n child commit = Kind-Commit\n commit message = Commit-Beschreibung\n\n stash(noun) = der Stash\n stash(verb) = \"stash\" benutzen\n unstash(verb) = aus Stash zurückladen\n\n reference = Referenz\n refspec = (die) Refspec\n revision = Commit\n branch = Branch\n tag(noun) = Tag\n tag(verb) = taggen, Tag erstellen\n annotated tag = annotierter Tag\n tag message = Tag-Beschreibung\n\n orphan commit =\n orphan reference =\n\n boundary commit = Grenz-Commit\n root commit = Ursprungs-Commit, Wurzel-Commit\n\n stage/index (noun) = Staging-Area\n stage/index (verb) = (für einen | zum) Commit vormerken\n unstage (verb) = aus Staging Area entfernen\n\nThe DAG:\n\n commit graph = Commit-Graph\n merge = Merge\n\nReferences in relation to other references:\n\n branches that have diverged = Branches sind divergiert\n diverging references = divergierte Referenzen\n your branch is ahead = Ihr Branch ist voraus\n your branch is behind = Ihr Branch ist hinterher\n\nMoving data around:\n\n fetch = anfordern\n pull = zusammenführen\n push = versenden\n\n fast-forward = vorspulen\n non-fast-forward = nicht vorspulen\n\nCommands:\n\nWhen a message is referering to the command, e.g. in\nerror messages, we do not translate the term.\nFor example: \"revert\" ist fehlgeschlagen\nWhen a message is referering to the thing the command\nis doing, e.g. in help messages, we translate the term.\nFor example: \"fordert von allen externen Projektarchiven an\"\nFor some commands we currently don't have a sane translation\n(e.g. \"cherry-pick\") so we don't translate it in any case.\n\n add(verb) = hinzufügen\n log = Log\n interactive commit = interaktiver Commit\n cherry-pick = \"cherry-pick\" benutzen\n rebase(verb) = \"rebase\" benutzen\n rebase(noun) = \"rebase\"\n archive = archivieren\n revert = zurücknehmen\n clean(verb) = säubern/aufräumen\n clean(noun) = Säuberung\n merge(verb) = zusammenführen\n merge(noun) = Zusammenführung\n reset(verb) = umsetzen\n reset(noun) = der \"reset\"\n(\"Umsetzung\" would be too confusing.)\n apply = anwenden\n\n bundle(noun) = Paket\n bundle(verb) = Paket erstellen\n unbundle(verb) = Paket entpacken\n\n bisect = binäre Suche\n bisecting = bei einer binären Suche sein, binäre Suche durchführen\n\nDiff/patch related:\n\n diff = Differenz\n delta = Differenz (or Delta)\n patch = Patch\n diffstat = Diffstat\n hunk = Block (maybe \"Patch-Block\")\n whitespace = Whitespace\n\nStill being worked out:\n\n prune = veraltete(n) Branch(es) entfernen\n checkout(verb) = auschecken\n\n git add = hinzufügen\n\n merge conflict = Merge-Konflikt\n 3-way merge = 3-Wege-Merge\n paths = Pfade\n\n symbolic link = symbolischer Verweis\n path = Pfad\n link = Verweis\n\n reflog = Referenzprotokoll\n partial commit (verb) = teilweise committen\n partial commit (noun) = Teil-Commit\n\n register = in die Konfiguration eintragen\n unregister = aus der Konfiguration austragen\n"},{"id":"221020","messageId":"alpine.LSU.2.10.9.1306162320560.30428@nerf07.vanv.qr","threadId":"33807","inReplyTo":"20130523181615.GB3270@client.brlink.eu","subject":"Re: English/German terminology, git.git's de.po, and pro-git","fromName":"Jan Engelhardt","fromEmail":"jengelh@inai.de","sentAt":"2013-06-16T21:22:29Z","receivedAt":"2013-06-16T21:22:29Z","isPatch":false,"sender":{"key":"jengelh@inai.de","avatar":"https://avatars.githubusercontent.com/u/8861948?v=4"},"body":"\nOn Thursday 2013-05-23 20:16, Bernhard R. Link wrote:\n>>\n>> Not sure if German users would know what \"hunk\" means, in case we\n>> leave it untranslated. And I'm not sure if I would understand \"Kontext\".\n>> I tend to leave it untranslated.\n>\n>Anyone found a German translation of the Patch manpage? Translating the\n>English word-play here, I'd suggest \"Block\" or \"Patch-Block\".\n\nHunk is like a chunk, and the dictionary offers some fun too:\n\ndickes Stück; Brocken {m} :: chunk\n(Holz)klotz {m} :: chunk (of wood)\n\nand that is what many patches feel like indeed, especially\nwhen they generate rejects :)\n"}]}