English/German terminology, git.git's de.po, and pro-git
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.
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
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
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 :
> 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
AW: English/German terminology, git.git's de.po, and pro-git
Hi,
My vote is G+E, too.
lb1a, Florian Breisch and I are working on the german translation of the
pro-git book (hosted on git-scm.com). We use the repository [1] to share
our work. If someone wants to help us, JOIN US!
The current translation of pro-git is mixed, Ger and G+E. For example,
the translation of "annotated tag" is "Annotated Tag", "kommentierter Tag"
and also "kommentierte Markierung". I agree with the opinion of Jan
Engelhardt that german terms should be used if they are commonly
used in technical context ("tree"=> "Baum" but "tag" should be "Tag"
in german, too).
There is a glossary for the pro-git book (see [2]) but it is not up-to-date
and it is also mixed. Therefor I would like to avoid using this glossary.
I like the idea of a shared wiki (git de.po and pro-git).
I suggest a single page as overview and single pages for
complicated terms. Maybe we can use our GitHub wiki (see also [3]).
So long
Ralph
[1] https://github.com/progit-de/progit
[2] https://github.com/progit/progit/blob/master/de/NOTES
[3] https://github.com/progit-de/progit/wiki/Glossar
--
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 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
+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 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 pro
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/16 Holger Hellmuth (IKS) : > >> +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 :
> Ralf Thielow 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) : > [...] >> +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
Am 19.05.2013 18:56, schrieb Ralf Thielow: 2013/5/16 Holger Hellmuth (IKS) : [...] +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". -- 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
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. 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... > 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. > 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. > 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 information about a keyword. It is a big improvement to use "staging area" on the English side. If it has to be an English word due to consistency with the commands, I'd suggest "Staging-Area" or "Staging-Bereich". For the verb I'd agree to keep only the noun in English but construct the verb with German verbs, like already proposed here. > Moving data around: > > fetch = anfordern > pull = zusammenführen > push = versenden > > fast-forward = vorspulen > non-fast-forward = nicht vorspulen IMHO yes, and the German terms make me even u
Re: English/German terminology, git.git's de.po, and pro-git
2013/5/20 Holger Hellmuth : > Am 19.05.2013 18:56, schrieb Ralf Thielow: > >> 2013/5/16 Holger Hellmuth (IKS) : >>> >>> >> [...] +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 :
> 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 E
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
* Ralf Thielow [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 "tree"s. 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/23 Bernhard R. Link : > * Ralf Thielow [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 "tree"s. 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
Re: AW: English/German terminology, git.git's de.po, and pro-git
On Monday 2013-05-13 20:57, Ralph Haußmann wrote: > >There is a glossary for the pro-git book (see [2]) but it is not up-to-date >and it is also mixed. Therefor I would like to avoid using this glossary. >I like the idea of a shared wiki (git de.po and pro-git). >I suggest a single page as overview and single pages for >complicated terms. Maybe we can use our GitHub wiki (see also [3]). > >[2] https://github.com/progit/progit/blob/master/de/NOTES >[3] https://github.com/progit-de/progit/wiki/Glossar This is how I envision a good glossary http://inai.de/files/git-glossary.txt Maybe the "Benevolent Dictator" model might be better suited instead of a wiki? (Think of the edit wars.) -- 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: AW: English/German terminology, git.git's de.po, and pro-git
Hi all, I tried to merge these different glossaries together (based on git de.po) as a new wiki page [1]. You can see the diff against the current git de.po glossary at [2]. I've also created a branch in my repository which only contains the wiki page as a text file. This allows comments on each line of a commit, which perhaps can be used for discussions (see [3]) and/or pull-requests?! If we really want to use one glossary, I'm also happy with other solutions or repositories. The new wiki page is in WIP state and it turns out that there aren't so many changes to the current one as I expected. I want to give a few comments on the most important changes: - tree = Baum + tree = Baum, Baum-Objekt, "Tree"-Objekt "Baum" is already fine. Depending on the message context we could use "Baum-Objekt", but not necessarily. - submodule = Unterprojekt + submodule = Submodul (suggested by JL) (before it was "Unterprojekt") I'm fine with that. - ancestor = Vorfahre + ancestor = Vorfahre, Vorgänger, Vorgänger-Commit "Vorgänger" sounds a bit better for me. - repository = Projektarchiv - bare repository = bloßes Projektarchiv + repository = Projektarchiv, (or just Repository?) + bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository) 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]... This goes to the question if we should translate "Commit" and "Tag". I think we shouldn't since everyone who uses/learn Git or come from other SCMs know what it means. + revision = Revision (use Commit instead (see dfb4410 (glossary: a revision is just a commit)) So just "Commit". + branch = Zweig (or Branch) I think "Zweig" is already fine. + stage/index (noun) = Bereitstellung (Staging-Area, Index) + stage/index (verb) = stagen, für einen Commit vormerken, zur Staging Area hinzufügen, dem Index hinzufügen + unstage (verb) = unstagen, aus Staging Area entfernen/nehmen, aus Index entfernen/nehmen I think we should replace "Bereitstellung" and "bereitstellen". "für einen/den Commit vormerken" is nice when "stage" is used as a verb. When "stage" is used as a noun, we have to decide between "Index" and "Staging Area" (and "Cache"?) I'd prefer "Index". + merge = Zusammenführung (Merge) We currently translate the noun of "merge" as "Zusammenführung" and the verb as "zusammenführen". I'd change it so "der Merge" and "mergen". The diff in [2] shows a couple of more changes but they're all based on the things I've mentioned here. [1] https://github.com/ralfth/git-po-de/wiki/Glossary-new-WIP [2] https://github.com/ralfth/git-po-de/wiki/_compare/25baaa323929949283a0b920c1ef66dc16288d0b...12f08b8973bd4b7ea55779f6eb5ad3a86bac13d8 [3] https://github.com/ralfth/git-po-de/commit/28852f8ea33ac6a9dbf7e3b17dfa00ddd4e7ecb5 Thanks, Ralf 2013/5/13 Jan Engelhardt : > > On Monday 2013-05-13 20:57, Ralph Haußmann wrote: >> >>There is a glossary for the pro-git book (see [2]) but it is not up-to-date >>and it is also mixed. Therefor I would like to avoid using this glossary. >>I like the idea of a shared wiki (git de.po and pro-git). >>I suggest a single page as overview and single pages for >>complicated terms. Maybe we can use our GitHub wiki (see also [3]). >> >>[2] https://github.com/progit/progit/blob/master/de/NOTES >>[3] https://github.com/progit-de/progit/wiki/Glossar > > This is how I envision a good glossary > > http://inai.de/files/git-glossary.txt > > Maybe the "Benevolent Dictator" model might be better suited > instead of a wiki? (Think of the edit wars.) -- 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
