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

On Monday 2013-05-13 14:54, Thomas Rast wrote:

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)

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.

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.)

Am 13.05.2013 15:57, schrieb Jan Engelhardt:

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.

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

On Monday 2013-05-13 20:57, Ralph Haußmann wrote:

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.)

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 <jengelh@inai.de>:

Am 14.05.2013 19:51, schrieb Ralf Thielow:

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.

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 ;-)

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.

Am 15.05.2013 12:23, schrieb Holger Hellmuth (IKS):

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.

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.

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.

On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:

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).

While it's spoken Packdatei, the way to actually write it is .pack-Datei or ".pack"-Datei.

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.

Not so strange. We have other words with -tet. bitten -> erbittete -> habe erbittet.

Am 15.05.2013 13:56, schrieb Jan Engelhardt:

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.

Go ahead: http://www.duden.de/rechtschreibung/Zipdatei ;-)

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.

On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:

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.

(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. ;-)

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.

Am 15.05.2013 15:14, schrieb Jan Engelhardt:

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)

On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote:

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) = (/^[^\.]+(\..+)?/)

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
--

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

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.

Use upstream as it is used as parameter to commands

fetch = fetch

pull = pull

push = push

established vocabulary used in stack programming as well as in vcs. Should not be translated.

clean(verb) = säubern/aufräumen

clean(noun) = Säuberung

"aufräumen" is the better verb but there is no noun for it.

whitespace = whitespace

There is no german word for whitespace

"mittels "git add" hinzufügen" if you want to emphasize that you add something with the command

As a noun, "Teil-Commit"

"zurücksetzen"

2013/5/16 Holger Hellmuth (IKS) <hellmuth@ira.uka.de>:

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.

I'll send a new version to the list later.

Thanks

2013/5/16 Holger Hellmuth (IKS) <hellmuth@ira.uka.de>:

[...]

"reset" can be used with every existing commit. "zurücksetzen" would imply that it have to be a recent commit, no?

Am 19.05.2013 18:56, schrieb Ralf Thielow:

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".

2013/5/20 Holger Hellmuth <holger@gspranz.de>:

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

Ralf Thielow <ralf.thielow@gmail.com> writes:

[...]

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.

2013/5/16 Thomas Rast <trast@inf.ethz.ch>:

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

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

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:

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...

Yes.

Yes. After some evaluation of the git-gui translation I think using "Repository" there as well is probably the better choice.

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.

Yes.

Yes, for the G+E approach.

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.

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".

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.

IMHO yes, and the German terms make me even understand what is going on. (On the English side it took me ages to memorize the difference between fetch and pull, as the words don't offer any difference in meaning. But that's a different story.) However, you probably get a hard time here when explaining how to keep consistency with the command names: It isn't clear for the user why "fetch" should be the command name related to "anfordern" but "pull" is not. This unfortunately probably means you have to introduce the words "pull" and "fetch" somewhere in the German text.

Yes. (I'd hope to see some German word for "cherry-pick" and "rebase" ("pflücken" and "neu aufbauen"), but then again, in G+E you probably keep that words.)

Yes

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.

Yes. Indeed I haven't heard a good German word that transports the same meaning.

Yes, and it makes me even understand what the command is about to do.

If merge was "zusammenführen" above, it should be "Zusammenführungs-Konflikt" here, and "3-Wege-Zusammenführung".

Teilweise committen. (No partial derivatives here...)

Best Regards,

Christian

2013/5/20 Christian Stimming <stimming@tuhh.de>:

Thanks for your comments.

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.

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.

Yes.

Yes.

Unfortunately, I don't know a place where we could introduce something. After looking through git's de.po, I didn't found a message where "pull" is translated. But I've found msgid "Pull is not possible ... msgstr "\"pull\" ist nicht möglich :) But, for example, "fetch" is used in help messages for options, e.g. msgid "fetch from all remotes" msgstr "fordert von allen externen Projektarchiven an" (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".

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.

Yes.

Yes.

Am 22.05.2013 17:16, schrieb Ralf Thielow:

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

On Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote:

hunk is chunk without a c, but otherwise with pretty much the same meaning. Especially when it rejects :)

* Ralf Thielow <ralf.thielow@gmail.com> [130522 17:17]:

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.

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"

Anyone found a German translation of the Patch manpage? Translating the English word-play here, I'd suggest "Block" or "Patch-Block".

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

2013/5/23 Bernhard R. Link <brl+git@mail.brlink.eu>:

Thanks.

On Thursday 2013-05-23 20:16, Bernhard R. Link wrote:

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 :)

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

2013/5/13 Thomas Rast <trast@inf.ethz.ch>:

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.

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:

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 this case there is room for useful German words instead of taking all difficult terms directly as English ones.

By the way, I'm puzzled why this sort of discussion appears only for German language translations and not others. Don't other languages have the same conflict of the English terms and potential translated words which are then unknown to the geeks on this list? Just curious.

Best Regards,

Christian

[1] http://git-scm.com/book/de/Los-geht%27s-Git-Grundlagen [2] http://git-scm.com/book/de/Git-Grundlagen-Mit-externen-Repositorys- arbeiten [3] http://git-scm.com/book/de/Git-Branching-Basic-Branching-and-Merging