Re: English/German terminology, git.git's de.po, and pro-git
On Thursday 2013-05-23 20:16, Bernhard R. Link wrote:
Not sure if German users would know what hunk means, in case we
leave it untranslated. And I'm not sure if I would understand Kontext.
I tend to leave it untranslated.
Anyone found a German translation of the Patch manpage? Translating the
English word-play here, I'd suggest Block or Patch-Block.
Hunk is like a chunk, and the dictionary offers some fun too:
dickes Stück; Brocken {m} :: chunk
(Holz)klotz {m} :: chunk (of wood)
and that is what many patches feel like indeed, especially
when they generate rejects :)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/23 Bernhard R. Link brl+...@mail.brlink.eu: * Ralf Thielow ralf.thie...@gmail.com [130522 17:17]: remote branch = Remote-Branch remote-tracking branch = Remote-Tracking-Branch upstream branch= Upstream-Branch Yes. What's the main reason for using Branch in the German text? Consistency with the commands, or assumed familiarity of the term within the target audience? Zweig is available. I think it's at the same level as Commit and a well known SCM-term. Users (even beginners) who know Commit and Tag do also know Branch. And I think it sounds better in combination with Remote-, Remote-Tracking- and Upstream- which are english words. Additionally Zweig might be a bit misleading. A branch is not part of the trees. It is called branch because in other VCSes the commits build a tree and a any commit outside of the main branch of that tree is part of exactly one different branch (so the head of that branch and the branch are synonymns). With git the commits are no longer a tree, so a git-branch is no branch and does not describe the whole branch of the tree of commits but is just a names pointer into the graph of commits. As it lost all meanings of the original word branch, translating it with a translation of the original English word might more confusion than helping anyone. (same for push). In other messages, the translation is in the same message as the command itself. I think it's OK when we just use fetch and push when the command is meant (as it's done for pull, e.g. in error messages), and the translation when the messages tell what the command is doing (e.g. help messages). So it would depends on the message whether we translate the word or not. This would apply to other terms that are commands, too, like clean or revert. I'd not call it OK. It's the only sane possibility. If you speak about the magic keyword you have to give the command line, you won't translate it, of course[1]. (The obvious interesting case is where the English text plays with the command name having a meaning as word itself. Here the translation will have to diverge to differentiate between both (or sacrifice one of them, where it is not important)). [1] Unlike you want to introduce a translated command line interface, like Depp anfordere Herkunft Original instead of git fetch origin master diff = Differenz delta = Differenz (or Delta) patch = Patch apply = anwenden diffstat = (leave it as it is) hunk = Bereich IMHO Kontext is better if you use a German word. Technically the context is something else, but in a German text IMHO it fits nicer when explaining to the user where he/she can select the n-th hunk. Not sure if German users would know what hunk means, in case we leave it untranslated. And I'm not sure if I would understand Kontext. I tend to leave it untranslated. Anyone found a German translation of the Patch manpage? Translating the English word-play here, I'd suggest Block or Patch-Block. paths = Pfade symbolic link = symbolische Verknüfung path = Pfad link = Verknüpfung In the filesystem a Link is a Verweis in Unix, not a Verknüpfung (that are usually the pseudo-links Windows supports). Bernhard R. Link Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Hi all, thanks for all your comments. Here's an updated version of the glossary including (hopefully) all the changes you've suggested. Basic repository objects: blob = Blob tree = Baum-Objekt (bevorzugt), Tree-Objekt submodule = Submodul pack(noun) = Pack-Datei pack(verb) = Pack-Datei erstellen ancestor = Vorgänger-Commit Content in a repository: file(s)= Datei(en) tracked file = beobachtete Datei track file = beobachte Datei untracked file = unbeobachtete Datei directory = Verzeichnis Repositories / tracking concepts: clone (verb) = klonen clone (noun) = der Klon repository = Repository bare repository= Bare Repository working directory = Arbeitsverzeichnis working tree = -||- remote branch = Remote-Branch remote-tracking branch = Remote-Tracking-Branch upstream branch= Upstream-Branch remote repository = Remote-Repository remote(noun) = -||- remote(adj)= extern, entfernt liegend Authorship: author= Autor committer = Commit-Ersteller tagger= Tag-Ersteller Commits, tags and other references: HEAD = HEAD Konzept aus der Git-Welt, daher nicht zu übersetzen. detached HEAD = losgelöster HEAD commit(noun) = Commit commit(verb) = committen commit the result = das Ergebnis committen parent commit = Eltern-Commit child commit = Kind-Commit commit message= Commit-Beschreibung stash(noun) = der Stash stash(verb) = stash benutzen unstash(verb) = aus Stash zurückladen reference = Referenz refspec= (die) Refspec revision = Commit branch = Branch tag(noun) = Tag tag(verb) = taggen, Tag erstellen annotated tag = annotierter Tag tag message= Tag-Beschreibung orphan commit= orphan reference = boundary commit = Grenz-Commit root commit = Ursprungs-Commit, Wurzel-Commit stage/index (noun) = Staging-Area stage/index (verb) = (für einen | zum) Commit vormerken unstage (verb) = aus Staging Area entfernen The DAG: commit graph = Commit-Graph merge = Merge References in relation to other references: branches that have diverged = Branches sind divergiert diverging references= divergierte Referenzen your branch is ahead= Ihr Branch ist voraus your branch is behind = Ihr Branch ist hinterher Moving data around: fetch = anfordern pull = zusammenführen push = versenden fast-forward = vorspulen non-fast-forward = nicht vorspulen Commands: When a message is referering to the command, e.g. in error messages, we do not translate the term. For example: revert ist fehlgeschlagen When a message is referering to the thing the command is doing, e.g. in help messages, we translate the term. For example: fordert von allen externen Projektarchiven an For some commands we currently don't have a sane translation (e.g. cherry-pick) so we don't translate it in any case. add(verb) = hinzufügen log= Log interactive commit = interaktiver Commit cherry-pick= cherry-pick benutzen rebase(verb) = rebase benutzen rebase(noun) = rebase archive= archivieren revert = zurücknehmen clean(verb)= säubern/aufräumen clean(noun)= Säuberung merge(verb)= zusammenführen merge(noun)= Zusammenführung reset(verb)= umsetzen reset(noun)= der reset (Umsetzung would be too confusing.) apply = anwenden bundle(noun) = Paket bundle(verb) = Paket erstellen unbundle(verb) = Paket entpacken bisect = binäre Suche bisecting = bei einer binären Suche sein, binäre Suche durchführen Diff/patch related: diff = Differenz delta = Differenz (or Delta) patch = Patch diffstat = Diffstat hunk = Block (maybe Patch-Block) whitespace = Whitespace Still being worked out: prune = veraltete(n) Branch(es) entfernen checkout(verb) = auschecken git add= hinzufügen merge conflict = Merge-Konflikt 3-way merge= 3-Wege-Merge paths = Pfade symbolic link = symbolischer Verweis path = Pfad link = Verweis reflog = Referenzprotokoll partial commit (verb) = teilweise committen partial commit (noun) = Teil-Commit register = in die Konfiguration eintragen unregister = aus der Konfiguration austragen -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to
Re: English/German terminology, git.git's de.po, and pro-git
* Ralf Thielow ralf.thie...@gmail.com [130522 17:17]: remote branch = Remote-Branch remote-tracking branch = Remote-Tracking-Branch upstream branch= Upstream-Branch Yes. What's the main reason for using Branch in the German text? Consistency with the commands, or assumed familiarity of the term within the target audience? Zweig is available. I think it's at the same level as Commit and a well known SCM-term. Users (even beginners) who know Commit and Tag do also know Branch. And I think it sounds better in combination with Remote-, Remote-Tracking- and Upstream- which are english words. Additionally Zweig might be a bit misleading. A branch is not part of the trees. It is called branch because in other VCSes the commits build a tree and a any commit outside of the main branch of that tree is part of exactly one different branch (so the head of that branch and the branch are synonymns). With git the commits are no longer a tree, so a git-branch is no branch and does not describe the whole branch of the tree of commits but is just a names pointer into the graph of commits. As it lost all meanings of the original word branch, translating it with a translation of the original English word might more confusion than helping anyone. (same for push). In other messages, the translation is in the same message as the command itself. I think it's OK when we just use fetch and push when the command is meant (as it's done for pull, e.g. in error messages), and the translation when the messages tell what the command is doing (e.g. help messages). So it would depends on the message whether we translate the word or not. This would apply to other terms that are commands, too, like clean or revert. I'd not call it OK. It's the only sane possibility. If you speak about the magic keyword you have to give the command line, you won't translate it, of course[1]. (The obvious interesting case is where the English text plays with the command name having a meaning as word itself. Here the translation will have to diverge to differentiate between both (or sacrifice one of them, where it is not important)). [1] Unlike you want to introduce a translated command line interface, like Depp anfordere Herkunft Original instead of git fetch origin master diff = Differenz delta = Differenz (or Delta) patch = Patch apply = anwenden diffstat = (leave it as it is) hunk = Bereich IMHO Kontext is better if you use a German word. Technically the context is something else, but in a German text IMHO it fits nicer when explaining to the user where he/she can select the n-th hunk. Not sure if German users would know what hunk means, in case we leave it untranslated. And I'm not sure if I would understand Kontext. I tend to leave it untranslated. Anyone found a German translation of the Patch manpage? Translating the English word-play here, I'd suggest Block or Patch-Block. paths = Pfade symbolic link = symbolische Verknüfung path = Pfad link = Verknüpfung In the filesystem a Link is a Verweis in Unix, not a Verknüpfung (that are usually the pseudo-links Windows supports). Bernhard R. Link -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/20 Holger Hellmuth hol...@gspranz.de: Am 19.05.2013 18:56, schrieb Ralf Thielow: 2013/5/16 Holger Hellmuth (IKS) hellm...@ira.uka.de: [...] +reset = neu setzen (maybe umsetzen?) zurücksetzen reset can be used with every existing commit. zurücksetzen would imply that it have to be a recent commit, no? It implies that it sets to something that already existed or came before. So it even fits in a case where you reset to an older commit and reset back to HEAD because the HEAD commit existed already. If you still don't like it, I would prefer umsetzen to neu setzen. I'd still understand zurücksetzen as set something *back* to but this back can also be something that was made after HEAD perhaps on another branch and HEAD (or the current ref) was never at this point before, so zurücksetzen is not true in this case. I prefer umsetzen to neu setzen, too. I'll change the glossary to this. Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/20 Christian Stimming stimm...@tuhh.de: Thanks for the update. I would like to add some comments on this G+E glossary and I hope you are interested in reading those, even though it is known that I prefer a pure Ger translation. However, as I wrote in my other message I agree that for the command line tool the criteria for choosing the translation approach are different from those for a GUI tool. So I can very well envision a good G+E translation for git core and subsequently all related books. Thanks for your comments. Am Sonntag, 19. Mai 2013, 18:53:18 schrieb Ralf Thielow: Basic repository objects: blob = Blob tree = Baum, Baum-Objekt (bevorzugt), Tree-Objekt submodule = Submodul pack(noun) = Pack-Datei pack(verb) = packen (ggf. Pack-Datei erstellen) ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt) Yes. Does the Pack-Datei appear anywhere in the book? I wouldn't understand the term, but then again, this is probably because I don't understand the semantic of this thingy as a repository object regardless of the language... The book has this word in it's index (9.4 Pack-Dateien) http://git-scm.com/book/de so we're fine here. While at there, I just read Die Refspec in the index. The current glossary doesn't contain refspec and we translate is as Referenzspezifikation. So if we want to match the book, we should add refspec = Refspec to the glossary. Content in a repository: file(s)= Datei(en) tracked file = beobachtete Datei track file = beobachte Datei untracked file = unbeobachtete Datei directory = Verzeichnis Yes. Repositories / tracking concepts: clone (verb) = klonen clone (noun) = der Klon repository = Repository bare repository= Bare Repository Yes. After some evaluation of the git-gui translation I think using Repository there as well is probably the better choice. working directory = Arbeitsverzeichnis working tree = -||- remote branch = Remote-Branch remote-tracking branch = Remote-Tracking-Branch upstream branch= Upstream-Branch Yes. What's the main reason for using Branch in the German text? Consistency with the commands, or assumed familiarity of the term within the target audience? Zweig is available. I think it's at the same level as Commit and a well known SCM-term. Users (even beginners) who know Commit and Tag do also know Branch. And I think it sounds better in combination with Remote-, Remote-Tracking- and Upstream- which are english words. remote repository = Remote-Repository remote(noun) = -||- remote(adj)= extern, entfernt liegend Authorship: author= Autor committer = Commit-Ersteller tagger= Tag-Ersteller Yes. Commits, tags and other references: HEAD = HEAD Konzept aus der Git-Welt, daher nicht zu übersetzen. detached HEAD = losgelöster HEAD commit(noun) = Commit commit(verb) = committen commit the result = das Ergebnis committen parent commit = Eltern-Commit child commit = Kind-Commit commit message= Commit-Beschreibung Yes, for the G+E approach. stash(noun) = der Stash stash(verb) = stashen, stash benutzen (bevorzugt) unstash(verb) = unstashen, zurückladen, aus 'stash' zurückladen (bevorzugt) Using Stash in G+E is quite ugly, but the noun is probably unavoidable because the feature is pretty much unique to git. I'd suggest to use only the noun and use the verbs as stash benutzen and aus stash zurückladen as proposed. Yes. reference = Referenz revision = Commit branch = Branch tag(noun) = Tag tag(verb) = taggen, Tag erstellen annotated tag = annotierter Tag tag message= Tag-Beschreibung I've commented on Branch above. As for Tag: Yes, the term is familiar among the target audience. However, do you really want this noun which is the same word as Tag wie in Datum? Some more disambiguation between the tag and the date would be helpful, wouldn't it? The derived forms are fine, and also here I'd suggest to use only the G+E noun but construct the verbs with other German words: Tag erstellen. stage/index (noun) = Staging-Area, Index stage/index (verb) = (für einen | zum) Commit vormerken (bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen unstage (verb) = aus Staging Area entfernen, aus Index entfernen I'd strongly suggest not to use Index. I've never understood why this term showed up in the English wording to begin with. It took me years until I got the point that from the user's point of view, this thingy has nothing to do with a book's index or a database's index, which is where I go to look up more
Re: English/German terminology, git.git's de.po, and pro-git
Am 22.05.2013 17:16, schrieb Ralf Thielow: hunk = Bereich IMHO Kontext is better if you use a German word. Technically the context is something else, but in a German text IMHO it fits nicer when explaining to the user where he/she can select the n-th hunk. Not sure if German users would know what hunk means, in case we leave it untranslated. And I'm not sure if I would understand Kontext. I tend to leave it untranslated. I don't think Bereich is a bad choice. As hunk is not a word with special meaning in cvs and not used in any commands I don't see a lot of reasons to keep it in english. Alternative translations might be Teilbereich, Dateibereich. Kontext would be very confusing IMHO -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote: Not sure if German users would know what hunk means, in case we leave it untranslated. And I'm not sure if I would understand Kontext. I tend to leave it untranslated. I don't think Bereich is a bad choice. As hunk is not a word with special meaning in cvs and not used in any commands I don't see a lot of reasons to keep it in english. hunk is chunk without a c, but otherwise with pretty much the same meaning. Especially when it rejects :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/16 Holger Hellmuth (IKS) hellm...@ira.uka.de: +bare repository= bloßes Repository Since bloßes Rep. does not convey any sensible meaning to a german reader (at least it doesn't to me) it might as well be bare. Also bare is used as parameter to commands +remote tracking branch = externer Übernahmezweig Anyone used to the english client will switch as soon as he has to read this. No idea how to improve that though except to just use the english terms like the pro git translation does. +upstream branch= -||- Use upstream as it is used as parameter to commands +fetch = anfordern fetch = fetch +pull = zusammenführen pull = pull +push = versenden push = push established vocabulary used in stack programming as well as in vcs. Should not be translated. I think the messages would become a bit too G+E when we'd say something like Das Fetchen in den Branch..., Fetche von %s. Some for merge as a verb. +clean(verb)= clean(verb) = säubern/aufräumen +clean(noun)= clean(noun) = Säuberung aufräumen is the better verb but there is no noun for it. +whitespace = Leerzeichen (FIXME?) (maybe Leerraum) whitespace = whitespace There is no german word for whitespace +Still being worked out: + +prune = veraltete(n) Zweig(e) entfernen +checkout(verb) = auschecken + +git add = hinzufügen mittels git add hinzufügen if you want to emphasize that you add something with the command + +merge conflict = Merge-Konflikt +3-way merge= 3-Wege-Merge +paths = Pfade + +symbolic link = symbolische Verknüfung +path = Pfad +link = Verknüpfung + +reflog = Referenzprotokoll +partial commit = teilweise committen, partiell committen As a noun, Teil-Commit + +reset = neu setzen (maybe umsetzen?) zurücksetzen I'll send a new version to the list later. Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/16 Thomas Rast tr...@inf.ethz.ch:
Ralf Thielow ralf.thie...@gmail.com writes:
Hi,
I think the discussion might work better via ML than GitHub.
This is the full glossary of git's de.po as it would look
like with (hopefully) all the changes included that have been
discussed here. Still without any reasoning for decisions
(except HEAD).
[...]
+remote branch = externer Zweig
+remote tracking branch = externer Übernahmezweig
Hrm, before we (erm, you) do any extensive work on redoing the glossary,
I think we should step back and agree on a direction.
Remember what this thread started with:
} However, an unfortunate and unsatisfactory situation has developed:
} Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
} Thielow built core git's de.po on top of it, so it's also Ger.
}
} Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
} translation of pro-git (which is also quite mature at this point, having
} apparently begun in 2009), and as you probably guessed by now, it's G+E.
}
} So that leaves us at a point where the libre Git book (and also the
} one that happens to be hosted on git-scm.com, the official site) does
} not match the terminology used by German git.
}
} Like, at all. They're not even remotely near each other.
My thinly veiled opinion in the thread starter was that we should redo
git's de.po from scratch using a translation similar to pro-git.
I can accept that discussion takes a different turn, and thus the
translation does something else. But my impression in the thread so far
was that:
* Everyone voted for G+E.
* The thread went of on a tangent, bikeshedding on some Ger
translations.
Please tell me I'm wrong...
Otherwise, assuming any agreement can be reached, IMHO the first step
must be to write/complete a glossary that matches *current usage* in
pro-git. We can perhaps bikeshed about some glaring issues in the
result, but remember that -- again assuming G+E is the conclusion -- any
such change again either means a divergence between book and git (bad!)
or a lot of work for the book translators.
Well, that's what I'm trying to do, writing a new glossary. But I took
the current git's de.po glossay as the base, because it's the biggest one
and easier to apply to de.po instead of using a complete new one.
I tried to merge [1] (link is dead) to match ProGit-Book where it's possible.
IMO it's OK if we don't match the ProGit-book in all terms (I didn't do it with
intention), but it's not OK if the translations are so far away from each other
that it becomes a problem to the users because they're using totally different
languages.
What I'm doing now is collecting objections and suggestions from others (ML, GH)
and apply them to the glossary in order to get a version where everybody
more or less agree with.
[1] https://github.com/progit/progit/blob/master/de/NOTES
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Hi, here's an updated version of the glossary. Comments are appreciated. Basic repository objects: blob = Blob tree = Baum, Baum-Objekt (bevorzugt), Tree-Objekt submodule = Submodul pack(noun) = Pack-Datei pack(verb) = packen (ggf. Pack-Datei erstellen) ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt) Content in a repository: file(s)= Datei(en) tracked file = beobachtete Datei track file = beobachte Datei untracked file = unbeobachtete Datei directory = Verzeichnis Repositories / tracking concepts: clone (verb) = klonen clone (noun) = der Klon repository = Repository bare repository= Bare Repository working directory = Arbeitsverzeichnis working tree = -||- remote branch = Remote-Branch remote-tracking branch = Remote-Tracking-Branch upstream branch= Upstream-Branch remote repository = Remote-Repository remote(noun) = -||- remote(adj)= extern, entfernt liegend Authorship: author= Autor committer = Commit-Ersteller tagger= Tag-Ersteller Commits, tags and other references: HEAD = HEAD Konzept aus der Git-Welt, daher nicht zu übersetzen. detached HEAD = losgelöster HEAD commit(noun) = Commit commit(verb) = committen commit the result = das Ergebnis committen parent commit = Eltern-Commit child commit = Kind-Commit commit message= Commit-Beschreibung stash(noun) = der Stash stash(verb) = stashen, stash benutzen (bevorzugt) unstash(verb) = unstashen, zurückladen, aus 'stash' zurückladen (bevorzugt) reference = Referenz revision = Commit branch = Branch tag(noun) = Tag tag(verb) = taggen, Tag erstellen annotated tag = annotierter Tag tag message= Tag-Beschreibung orphan commit= orphan reference = boundary commit = Grenz-Commit root commit = Ursprungs-Commit, Wurzel-Commit stage/index (noun) = Staging-Area, Index stage/index (verb) = (für einen | zum) Commit vormerken (bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen unstage (verb) = aus Staging Area entfernen, aus Index entfernen The DAG: commit graph = Commit-Graph merge = Merge References in relation to other references: branches that have diverged = Branches sind divergiert diverging references= divergierte Referenzen your branch is ahead= Ihr Branch ist voraus your branch is behind = Ihr Branch ist hinterher Moving data around: fetch = anfordern pull = zusammenführen push = versenden fast-forward = vorspulen non-fast-forward = nicht vorspulen Commands: log= Log interactive commit = interaktiver Commit cherry-pick= cherry-pick benutzen rebase(verb) = rebase benutzen rebase(noun) = rebase archive= archivieren revert = zurücknehmen clean(verb)= säubern/aufräumen clean(noun)= Säuberung merge = zusammenführen bundle(noun) = Paket bundle(verb) = Paket erstellen unbundle(verb) = Paket entpacken bisect = binäre Suche bisecting = bei einer binären Suche sein, binäre Suche durchführen Diff/patch related: diff = Differenz delta = Differenz (or Delta) patch = Patch apply = anwenden diffstat = (leave it as it is) hunk = Bereich whitespace = Whitespace Still being worked out: prune = veraltete(n) Branch(es) entfernen checkout(verb) = auschecken git add = hinzufügen merge conflict = Merge-Konflikt 3-way merge= 3-Wege-Merge paths = Pfade symbolic link = symbolische Verknüfung path = Pfad link = Verknüpfung reflog = Referenzprotokoll partial commit (verb) = teilweise committen, partiell committen partial commit (noun) = Teil-Commit reset = neu setzen (maybe umsetzen?) register = in die Konfiguration eintragen unregister = aus der Konfiguration austragen -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/16 Holger Hellmuth (IKS) hellm...@ira.uka.de: [...] +reset = neu setzen (maybe umsetzen?) zurücksetzen reset can be used with every existing commit. zurücksetzen would imply that it have to be a recent commit, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
+bare repository= bloßes Repository Since bloßes Rep. does not convey any sensible meaning to a german reader (at least it doesn't to me) it might as well be bare. Also bare is used as parameter to commands +remote tracking branch = externer Übernahmezweig Anyone used to the english client will switch as soon as he has to read this. No idea how to improve that though except to just use the english terms like the pro git translation does. +upstream branch= -||- Use upstream as it is used as parameter to commands +fetch = anfordern fetch = fetch +pull = zusammenführen pull = pull +push = versenden push = push established vocabulary used in stack programming as well as in vcs. Should not be translated. +clean(verb)= clean(verb) = säubern/aufräumen +clean(noun)= clean(noun) = Säuberung aufräumen is the better verb but there is no noun for it. +whitespace = Leerzeichen (FIXME?) (maybe Leerraum) whitespace = whitespace There is no german word for whitespace +Still being worked out: + +prune = veraltete(n) Zweig(e) entfernen +checkout(verb) = auschecken + +git add = hinzufügen mittels git add hinzufügen if you want to emphasize that you add something with the command + +merge conflict = Merge-Konflikt +3-way merge= 3-Wege-Merge +paths = Pfade + +symbolic link = symbolische Verknüfung +path = Pfad +link = Verknüpfung + +reflog = Referenzprotokoll +partial commit = teilweise committen, partiell committen As a noun, Teil-Commit + +reset = neu setzen (maybe umsetzen?) zurücksetzen -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Ralf Thielow ralf.thie...@gmail.com writes:
Hi,
I think the discussion might work better via ML than GitHub.
This is the full glossary of git's de.po as it would look
like with (hopefully) all the changes included that have been
discussed here. Still without any reasoning for decisions
(except HEAD).
[...]
+remote branch = externer Zweig
+remote tracking branch = externer Übernahmezweig
Hrm, before we (erm, you) do any extensive work on redoing the glossary,
I think we should step back and agree on a direction.
Remember what this thread started with:
} However, an unfortunate and unsatisfactory situation has developed:
} Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
} Thielow built core git's de.po on top of it, so it's also Ger.
}
} Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
} translation of pro-git (which is also quite mature at this point, having
} apparently begun in 2009), and as you probably guessed by now, it's G+E.
}
} So that leaves us at a point where the libre Git book (and also the
} one that happens to be hosted on git-scm.com, the official site) does
} not match the terminology used by German git.
}
} Like, at all. They're not even remotely near each other.
My thinly veiled opinion in the thread starter was that we should redo
git's de.po from scratch using a translation similar to pro-git.
I can accept that discussion takes a different turn, and thus the
translation does something else. But my impression in the thread so far
was that:
* Everyone voted for G+E.
* The thread went of on a tangent, bikeshedding on some Ger
translations.
Please tell me I'm wrong...
Otherwise, assuming any agreement can be reached, IMHO the first step
must be to write/complete a glossary that matches *current usage* in
pro-git. We can perhaps bikeshed about some glaring issues in the
result, but remember that -- again assuming G+E is the conclusion -- any
such change again either means a divergence between book and git (bad!)
or a lot of work for the book translators.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Dear translators, Here's the main point in this discussion: The translation is not for us! The translation is for those who don't speak much English and who don't know the English git terminology very well. By definition, this target audience is not present here on this mailing list and in this discussion. Hence, arguments such as I like word x better are rather weak. Instead, stating Word x gives the intended target audience a better picture of what is going on is probably a better argument. Am Montag, 13. Mai 2013, 14:54:51 schrieb Thomas Rast: However, an unfortunate and unsatisfactory situation has developed: Christian Stimming's git-gui de.po uses a Ger translation, and Ralf Thielow built core git's de.po on top of it, so it's also Ger. Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a translation of pro-git (which is also quite mature at this point, having apparently begun in 2009), and as you probably guessed by now, it's G+E. Thanks, Thomas, for spotting the conflicting translations in those excellent book projects vs. the git core and git gui. I think it's rather obvious why the pro-git translators chose the G+E approach for their work: Their goal is to explain the command line usage of git, which means they inevitably have to use the git command names, which happen to be in English (and will surely stay so). Hence, any translation approach will have to deal with the English command names as useful words in the normal translated text. That's probably a constraint that is true for any translation of a command-line tool to stay useful. I noticed with some amusement, though, that even in the pro-git book with the described constraint there are places where a pure Ger translation is almost shining through... Such as in [1]: Jedes Mal, wenn Du committest (d.h. den gegenwärtigen Status deines Projektes als eine Version in Git speicherst)... Can you notice how the translators identified Version as translation for commit (noun) and speichern as translation for commit (verb) :-) ? Of course this is just the explanation and not the actual translation later during the text. However, I take this spot as an example that there exist meaningful pure-Ger translations even for the most important git terminology. In fact, to find useful Ger translations, I wonder how I would talk to someone from the target audience a sentence such as Finde mal den richtigen Commit, also die Version, ... When I find myself saying such an - also das xy - appendix often enough, I take this as an indication that the latter word can just as well be used as the main translation. Back to the original question: I think the book shows quite nicely that for working with the git command line, a G+E translation is more useful as long as the command names also appear unchangedly in the translation. However, everything else that does not appear as a command name can be translated either in G+E or in Ger. The argument can go on to state that someone who is geek enough to use the command line is probably more proficient in English language anyway. Hence, using more English terms in the translation is probably fine as well and a full G+E translation is probably a good approach. The pro-git book has some places where the translated word is not always used consistently (e.g. in [2] Externes Repository vs. Remote Repository), and some G+E suggestions from this mailing list have been translated Ger in the book (they use zusammenführen in [2] and [3] instead of merge with only a few exceptions). It is also a good point to make the pro-git and git core translation consistent, once the approach is decided on. *However*: This argument is completely different when we talk about the GUI tools. The target audience of the git gui etc. are those developers who write great code, but #1 do not know the English language well enough, and #2 are so far away from the geek corner that they use a development workflow purely in GUI tools. The question is: What GUI button labels helps those people the most to get a good picture of what is going on? And in this case I still believe a pure Ger translation is the better choice! I wonder how feedback on this claim can be collected from developers of the target audience. When I started on the git-gui translation, I asked some coworkers that fall into this category for feedback on the wordings, and their response indicated agreement to my approach. What feedback have others here heard from people who fall into described category? At the end of the day that sort of feedback has to be the ground for a decision on the approach in the GUI translation. In the meantime I think a different translation approach between git core and git gui is not a problem at all. For git gui I propose to stick to a Ger translation. For git core and the books that describe the command line interface, a G+E translation is probably a good choice but even in
Re: English/German terminology, git.git's de.po, and pro-git
Am 14.05.2013 19:51, schrieb Ralf Thielow: - repository = Projektarchiv - bare repository = bloßes Projektarchiv + repository = Projektarchiv, (or just Repository?) + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository) 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. I'm not sure about using Repository. I think Projektarchiv is actually good enough. - committer = Eintragender - tagger = Markierer + committer = Eintragender (or Committer, Commit-Ersteller) + tagger = Markierer (or Tagger, Tag-Ersteller) ...[each usage of commit and tag]... 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 ;-) + branch = Zweig (or Branch) I think Zweig is already fine. 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 15.05.2013 12:23, schrieb Holger Hellmuth (IKS): Am 14.05.2013 19:51, schrieb Ralf Thielow: - repository = Projektarchiv - bare repository = bloßes Projektarchiv + repository = Projektarchiv, (or just Repository?) + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository) 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. Hmm, I rather tend towards using Repository instead of Archiv too, as Archiv can mean anything from a tar-file to a git repository, while we are talking about something very specific here (and a German might be surprised what the command git archive is about if we use Archiv here ;-). So if it has to be translated, I like Projektarchiv better than Archiv for those reasons. We can also think about using Repo as an abbreviated form, we often use that when talking about repositories in German. That would be a new term without ambiguity and will be pronounced pretty much correctly by all Germans too. But this remains one of the tougher questions. And then pack is currently translated as Archiv: pack(noun) = Archiv but I believe Packdatei would be a much better translation (especially as the translation of pack(verb) is packen). I find it natural that a file with the extension .pack is named Packdatei, just like a file with the extension .zip is a Zipdatei (known by the Duden) in German. And the Duden already knows Pack as an assembly of smaller parts, so we should be safe here. I'm not sure about using Repository. I think Projektarchiv is actually good enough. - committer = Eintragender - tagger = Markierer + committer = Eintragender (or Committer, Commit-Ersteller) + tagger = Markierer (or Tagger, Tag-Ersteller) ...[each usage of commit and tag]... 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 ;-) Yup, im my experience committen (to commit), einchecken (to check in), auschecken (to check out) und taggen (to tag) made it into our daily German language use. To avoid e.g. having past tenses look strange (like committet) the combined Form (Commit erstellt) could solve that problem. + branch = Zweig (or Branch) I think Zweig is already fine. 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. Yes, Baum, Wurzel and Zweig are obviously equivalent to tree, root and branch, so I don't care much if we translate that or not. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Wednesday 2013-05-15 13:26, Jens Lehmann wrote: Hmm, I rather tend towards using Repository instead of Archiv too, as Archiv can mean anything from a tar-file to a git repository It's exactly the reasoning I made in my git-glossary.txt sample (of which the reasoning apparently has not made it into ralfth's latest wiki, but that's the most essential part of a glossary IMHO). but I believe Packdatei would be a much better translation (especially as the translation of pack(verb) is packen). I find it natural that a file with the extension .pack is named Packdatei While it's spoken Packdatei, the way to actually write it is .pack-Datei or .pack-Datei. extension .zip is a Zipdatei (known by the Duden) If that's how Duden specifies it, it's time to call wrong upon Duden. It's ZIP-Datei, of course, and follows the same origin (.zip-Datei). The history of ZIP-Datei can be explained by way of MSDOS showing the filename in the DIR command without the dot - which is also why we do not pronounce the dot in .zip- or .pack-Datei. Yup, im my experience committen (to commit), einchecken (to check in), auschecken (to check out) und taggen (to tag) made it into our daily German language use. To avoid e.g. having past tenses look strange (like committet) Not so strange. We have other words with -tet. bitten - erbittete - habe erbittet. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 15.05.2013 13:56, schrieb Jan Engelhardt: On Wednesday 2013-05-15 13:26, Jens Lehmann wrote: but I believe Packdatei would be a much better translation (especially as the translation of pack(verb) is packen). I find it natural that a file with the extension .pack is named Packdatei While it's spoken Packdatei, the way to actually write it is .pack-Datei or .pack-Datei. I actually had the '-' in there too until I tried to look up Zip-Datei in the Duden. While I don't get the leading '.' (I cannot remember having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. extension .zip is a Zipdatei (known by the Duden) If that's how Duden specifies it, it's time to call wrong upon Duden. Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-) Yup, im my experience committen (to commit), einchecken (to check in), auschecken (to check out) und taggen (to tag) made it into our daily German language use. To avoid e.g. having past tenses look strange (like committet) Not so strange. We have other words with -tet. bitten - erbittete - habe erbittet. That example was not the best, what about wenn Du das mergest(?) (if you merge that), I cannot really say how to write that correctly (as in German we would want to drop the last 'e', right?). All that goes away when we use Merge as a noun: wenn Du den Merge machst. But again, somebody else might come up with a grammatically correct solution for that I'm missing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote: While it's spoken Packdatei, the way to actually write it is .pack-Datei or .pack-Datei. I actually had the '-' in there too until I tried to look up Zip-Datei in the Duden. While I don't get the leading '.' (I cannot remember having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. extension .zip is a Zipdatei (known by the Duden) If that's how Duden specifies it, it's time to call wrong upon Duden. Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-) (There seems to be no way to send corrections. Sucks not to be a wiki.) Ah well that explains their cluelessness: nach englisch zip file, zu: to zip = (mit dem Reißverschluss) schließen und file = Datei ZIP-Datei kommt daher, weil die Erweiterung ZIP/.zip ist, nicht weil da ein symbolischer Reißverschluss zugezogen wird oder ein Programmicon selbiges suggerieren will. Wir haben ja schließlich auch RAR-Dateien, die deswegen so heißen, weil sie eben .rar als Endung tragen und nicht, weil sie wertvolle Mangelware sind. ;-) Not so strange. We have other words with -tet. bitten - erbittete - habe erbittet. That example was not the best, what about wenn Du das mergest(?) (if Konjugation wie merken, nur Aussprache mit [dʒ] statt [k]-Laut. merge/mergst/mergt/mergen/mergt/mergen/mergte/(habe,hatte) (ge)mergt. Ich sehe da keine Komplikationen. you merge that), I cannot really say how to write that correctly (as in German we would want to drop the last 'e', right?) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 15.05.2013 15:14, schrieb Jan Engelhardt: On Wednesday 2013-05-15 14:27, Jens Lehmann wrote: While it's spoken Packdatei, the way to actually write it is .pack-Datei or .pack-Datei. I actually had the '-' in there too until I tried to look up Zip-Datei in the Duden. While I don't get the leading '.' (I cannot remember having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. Even in unix-land no one adds a dot because usually the extension is named after the data format, only that the file extension is used as the common abbreviation (at least that is my interpretation). Compare with jpeg. You often write jpeg-Datei instead of jpg-Datei because the data format is called jpeg. This is why I don't think the dot has any reason to be there. I can't remember ever seeing anyone writing .jpg-Datei (or .doc-Datei, .rar-Datei) except to ask what a .xyz Datei contains (i.e. when he doesn't know what the data format is) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote: I actually had the '-' in there too until I tried to look up Zip-Datei in the Duden. While I don't get the leading '.' (I cannot remember having seen that anywhere, AFAIK the file extensions are always used without the dot), I'm not a grammar expert and will be fine either way. In UNIX-land, extension seemed to always include the dot. In DOS-land, it's without (inherited from VMS too, perhaps?) As such, either way to write it is acceptable. Even in unix-land no one adds a dot because usually the extension is named after the data format, only that the file extension is used as the common abbreviation (at least that is my interpretation). Compare with jpeg. You often write jpeg-Datei instead of jpg-Datei because the data format is called jpeg. That too is correct, and actually a third way of describing files. For example, .doc/.xls-Datei in speech is very seldom, if at all; MS Office output has had generally been called Word-Datei, Excel-Tabelle/-Datei and so on. What I meant however is that the extension is .jpg (or .jpeg) from a programming aspect (like, when naïvely trying to figure out the filetype) as in ($name, $ext) = (/^[^\.]+(\..+)?/) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Hi, I think the discussion might work better via ML than GitHub. This is the full glossary of git's de.po as it would look like with (hopefully) all the changes included that have been discussed here. Still without any reasoning for decisions (except HEAD). Thanks for reading. +Basic repository objects: + +blob = Blob +tree = Baum, Baum-Objekt (bevorzugt), Tree-Objekt +submodule = Submodul +pack(noun) = Pack-Datei +pack(verb) = packen (ggf. Pack-Datei erstellen) +ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt) + +Content in a repository: + +file(s)= Datei(en) +tracked file = beobachtete Datei +track file = beobachte Datei +untracked file = unbeobachtete Datei +directory = Verzeichnis + +Repositories / tracking concepts: + +clone (verb) = klonen +clone (noun) = der Klon +repository = Repository + +bare repository= bloßes Repository +working directory = Arbeitsverzeichnis + +remote branch = externer Zweig +remote tracking branch = externer Übernahmezweig +upstream branch= -||- +tracking branch= Übernahmezweig + +remote repository = externes Repository +remote(noun) = -||- +remote(adj)= extern + +Authorship: + +author= Autor +committer = Commit-Ersteller +tagger= Tag-Ersteller + +Commits, tags and other references: + +HEAD = HEAD + Konzept aus der Git-Welt, daher nicht zu übersetzen. +detached HEAD = losgelöster HEAD + +commit(noun) = Commit +commit(verb) = committen +commit the result = das Ergebnis committen +parent commit = Eltern-Commit +child commit = Kind-Commit +commit message= Commit-Beschreibung + +stash(noun) = der Stash +stash(verb) = stashen, stash benutzen (bevorzugt) +unstash(verb) = unstashen, zurückladen, aus 'stash' zurückladen (bevorzugt) + +reference = Referenz +revision = Commit +branch = Zweig (or Branch) +tag(noun) = Tag +tag(verb) = taggen, Tag erstellen +annotated tag = annotierter Tag +tag message= Tag-Beschreibung + +orphan commit= +orphan reference = + +boundary commit = Grenz-Commit +root commit = Ursprungs-Commit, Wurzel-Commit + +stage/index (noun) = Staging-Area, Index +stage/index (verb) = (für einen | zum) Commit vormerken, zur Staging Area hinzufügen, dem Index hinzufügen +unstage (verb) = aus Staging Area entfernen/nehmen, aus Index entfernen/nehmen + +The DAG: + +commit graph = Commit-Graph +merge = Merge + +References in relation to other references: + +branches that have diverged = Zweige sind divergiert +diverging references= divergierte Referenzen +your branch is ahead= dein Zweig ist voraus +your branch is behind = dein Zweig ist hinterher + +Moving data around: + +fetch = anfordern +pull = zusammenführen +push = versenden + +fast-forward = vorspulen +non-fast-forward = nicht vorspulen + +Commands: + +log= Log +interactive commit = interaktiver Commit +cherry-pick= cherry-pick benutzen +rebase(verb) = rebase benutzen +rebase(noun) = rebase +archive= archivieren +revert = zurücknehmen +clean(verb)= +clean(noun)= +merge = mergen + +bundle(noun) = Paket +bundle(verb) = Paket erstellen +unbundle(verb) = Paket entpacken + +bisect = binäre Suche +bisecting = bei einer binären Suche sein, binäre Suche durchführen + +Diff/patch related: + +diff = Differenz +delta = Differenz (or Delta) +patch = Patch +apply = anwenden +diffstat = (leave it as it is) +hunk = Bereich +whitespace = Leerzeichen (FIXME?) (maybe Leerraum) + +Still being worked out: + +prune = veraltete(n) Zweig(e) entfernen +checkout(verb) = auschecken + +git add = hinzufügen + +merge conflict = Merge-Konflikt +3-way merge= 3-Wege-Merge +paths = Pfade + +symbolic link = symbolische Verknüfung +path = Pfad +link = Verknüpfung + +reflog = Referenzprotokoll +partial commit = teilweise committen, partiell committen + +reset = neu setzen (maybe umsetzen?) + +register = in die Konfiguration eintragen +unregister = aus der Konfiguration austragen -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
On Monday 2013-05-13 14:54, Thomas Rast wrote: As I am sure you are all aware, there are two main religions as to how one can translate technical material into German: leave the technical terms mostly in English, or translate them to an appropriate corresponding word. I'll denote them G+E and Ger, respectively. The problem is that there are often no technical equivalent terms in Ger, leaving you only with Eng which are paraphrased (in more or less detail) in the German-language manpages. treeish is one of those. The literal translation would be baumig, bäumlich. This is strange in German and at best only used by kids. In the SYNOPSIS section of e.g. git-ls-tree(1), you can get away with baumähnlich, but in flowtext (prose), the sane choices are, for example: git-ls-tree erfordert als ersten nicht-Options-Parameter... ~... einen tree-ish, d.h. eine Referenz, aus der sich ein Baum-Objekt ableiten lässt. ~... eine zu einem Baum-Objekt führende Refernz ~... eine Baum-Objekt-Referenz (dies kann auch ein Commit sein, da jedem Commit genau ein Baum-Objekt zugeordnet ist) My vote is G+E. Essentially, so is mine. German terms will be used where such have been used in prior computing (Bäume have been used in the 90s too, so that term is fine, for example). Stash however is something that could be seen as something that has had its first appearence in Git, with no corresponding native German term, in which case we should do it roughly like Wikipedia, that is, provide a German equivalent, but only for the introductory sake: Der Stash (dt: Versteck) bezeichnet einen Bereich ... afterwards which the meaning of stash is at most re-recognizable in the verb: ... mit `git stash` wird der aktuelle Zustand im Stash weggespeichert. That's my common-world use. glossary for git's de.po is [2]. I have no idea what Sven and Ralph do. Perhaps a github wiki page would be fine for everyone? A single wiki page might not suffice; we may need as much as one wiki page per term, so that there is ample visual space to record each person's comments and justification for choosing a particular German translation. (Just look at my go at treeish above, for example.) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/13 Thomas Rast tr...@inf.ethz.ch:
Hi
I hope I got together a Cc list that pretty much represents everyone
involved in git core and pro-git book translation into German.
As I am sure you are all aware, there are two main religions as to how
one can translate technical material into German: leave the technical
terms mostly in English, or translate them to an appropriate
corresponding word. I'll denote them G+E and Ger, respectively. I
would really like to avoid rehashing that entire discussion in this
thread, if at all possible; we've flogged that horse enough. See
e.g. [1] for previous threads on the git list about the transation.
However, an unfortunate and unsatisfactory situation has developed:
Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
Thielow built core git's de.po on top of it, so it's also Ger.
Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
translation of pro-git (which is also quite mature at this point, having
apparently begun in 2009), and as you probably guessed by now, it's G+E.
So that leaves us at a point where the libre Git book (and also the
one that happens to be hosted on git-scm.com, the official site) does
not match the terminology used by German git.
Like, at all. They're not even remotely near each other.
Therefore, a total newbie would find at least one of those two totally
useless. I haven't done a comprehensive survey yet, but it is my
impression that the commercial git books are also G+E, so the
hypothetical newbie would be stuck learning the English terms in one of
the two regardless.
So where to go from this mess?
Obviously -- unless the agreement is that the status quo should persist
-- we'd first have to sort out what the preferable translation should
be. And I'm a bit scared of trying, except that a straw poll on IRC
gave me some hope that a simple majority vote could help settle it.
My vote is G+E.
My vote is G+E, too. IMO the users should read the same terms in Git
messages as they read in the majority of German Git-books/blogs/etc.
(I don't know one of them where Git terms are translated.) I think that
would make users life easier and less confusing.
After that, we should create a unified glossary. Even in the G+E case,
a few terms would presumably be translated fully and some others might
have partial translations (checkout - auschecken?). The current
glossary for git's de.po is [2]. I have no idea what Sven and Ralph do.
Perhaps a github wiki page would be fine for everyone?
Finally, converting the existing translation will require some manpower.
I'll help review things, as I have previously done for translation
updates of core git de.po; perhaps with a few more volunteers it can be
done pretty quickly.
Thanks for your time.
- Thomas
[1] http://thread.gmane.org/gmane.comp.version-control.git/58315
http://thread.gmane.org/gmane.comp.version-control.git/156226/focus=156373
http://thread.gmane.org/gmane.comp.version-control.git/196779/focus=196792
[2] https://github.com/ralfth/git-po-de/wiki/Glossary
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Am 13.05.2013 15:57, schrieb Jan Engelhardt: On Monday 2013-05-13 14:54, Thomas Rast wrote: My vote is G+E. Essentially, so is mine. ... Same here. I frequently get asked to switch Git back to English when the LANG=C gets lost, because my coworkers and myself - almost all of which are native German speakers - are terribly confused by the current git gui translations. Having said that, no matter how this vote turns out the term submodule should be translated as Submodul and not Unterprojekt. The former is a perfectly valid German word and I see no reason to arbitrarily use a different one here. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
