English/German terminology, git.git's de.po, and pro-git

English/German terminology, git.git's de.po, and pro-git

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

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

Re: English/German terminology, git.git's de.po, and pro-git

[Jan Engelhardt]

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

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

2013/5/13 Thomas Rast <trast@inf.ethz.ch>:
> Hi
>
> I hope I got together a Cc list that pretty much represents everyone
> involved in git core and pro-git book translation into German.
>
> As I am sure you are all aware, there are two main religions as to how
> one can translate technical material into German: leave the technical
> terms mostly in English, or translate them to an appropriate
> corresponding word.  I'll denote them G+E and Ger, respectively.  I
> would really like to avoid rehashing that entire discussion in this
> thread, if at all possible; we've flogged that horse enough.  See
> e.g. [1] for previous threads on the git list about the transation.
>
> However, an unfortunate and unsatisfactory situation has developed:
> Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
> Thielow built core git's de.po on top of it, so it's also Ger.
>
> Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
> translation of pro-git (which is also quite mature at this point, having
> apparently begun in 2009), and as you probably guessed by now, it's G+E.
>
> So that leaves us at a point where "the" libre Git book (and also the
> one that happens to be hosted on git-scm.com, the official site) does
> not match the terminology used by German git.
>
> Like, at all.  They're not even remotely near each other.
>
> Therefore, a total newbie would find at least one of those two totally
> useless.  I haven't done a comprehensive survey yet, but it is my
> impression that the commercial git books are also G+E, so the
> hypothetical newbie would be stuck learning the English terms in one of
> the two regardless.
>
> So where to go from this mess?
>
> Obviously -- unless the agreement is that the status quo should persist
> -- we'd first have to sort out what the preferable translation should
> be.  And I'm a bit scared of trying, except that a straw poll on IRC
> gave me some hope that a simple majority vote could help settle it.
>
> My vote is G+E.
>

My vote is G+E, too. IMO the users should read the same terms in Git
messages as they read in the majority of German Git-books/blogs/etc.
(I don't know one of them where Git terms are translated.) I think that
would make users life easier and less confusing.

> After that, we should create a unified glossary.  Even in the G+E case,
> a few terms would presumably be translated fully and some others might
> have partial translations (checkout -> auschecken?).  The current
> glossary for git's de.po is [2].  I have no idea what Sven and Ralph do.
> Perhaps a github wiki page would be fine for everyone?
>
> Finally, converting the existing translation will require some manpower.
> I'll help review things, as I have previously done for translation
> updates of core git de.po; perhaps with a few more volunteers it can be
> done pretty quickly.
>
> Thanks for your time.
>
> - Thomas
>
>
>
> [1]  http://thread.gmane.org/gmane.comp.version-control.git/58315
>      http://thread.gmane.org/gmane.comp.version-control.git/156226/focus=156373
>      http://thread.gmane.org/gmane.comp.version-control.git/196779/focus=196792
>
> [2]  https://github.com/ralfth/git-po-de/wiki/Glossary
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch

Re: English/German terminology, git.git's de.po, and pro-git

[Jens Lehmann]

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.

AW: English/German terminology, git.git's de.po, and pro-git

[Ralph Haußmann]

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

Re: AW: English/German terminology, git.git's de.po, and pro-git

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

Re: AW: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

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

Re: English/German terminology, git.git's de.po, and pro-git

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

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

Re: English/German terminology, git.git's de.po, and pro-git

[Jens Lehmann]

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.

Re: English/German terminology, git.git's de.po, and pro-git

[Jan Engelhardt]

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.

Re: English/German terminology, git.git's de.po, and pro-git

[Jens Lehmann]

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.

Re: English/German terminology, git.git's de.po, and pro-git

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

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

Re: English/German terminology, git.git's de.po, and pro-git

[Holger Hellmuth (IKS)]

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)

Re: English/German terminology, git.git's de.po, and pro-git

[Jan Engelhardt]

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

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

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

Re: English/German terminology, git.git's de.po, and pro-git

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

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

Re: English/German terminology, git.git's de.po, and pro-git

[Thomas Rast]

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

> Hi,
>
> I think the discussion might work better via ML than GitHub.
> This is the full glossary of git's de.po as it would look
> like with (hopefully) all the changes included that have been
> discussed here. Still without any reasoning for decisions
> (except HEAD).
[...]
> +    remote branch          = externer Zweig
> +    remote tracking branch = externer Übernahmezweig

Hrm, before we (erm, you) do any extensive work on redoing the glossary,
I think we should step back and agree on a direction.

Remember what this thread started with:

} However, an unfortunate and unsatisfactory situation has developed:
} Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
} Thielow built core git's de.po on top of it, so it's also Ger.
} 
} Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
} translation of pro-git (which is also quite mature at this point, having
} apparently begun in 2009), and as you probably guessed by now, it's G+E.
} 
} So that leaves us at a point where "the" libre Git book (and also the
} one that happens to be hosted on git-scm.com, the official site) does
} not match the terminology used by German git.
} 
} Like, at all.  They're not even remotely near each other.

My thinly veiled opinion in the thread starter was that we should redo
git's de.po from scratch using a translation similar to pro-git.

I can accept that discussion takes a different turn, and thus the
translation does something else.  But my impression in the thread so far
was that:

* Everyone voted for G+E.

* The thread went of on a tangent, bikeshedding on some Ger
  translations.

Please tell me I'm wrong...

Otherwise, assuming any agreement can be reached, IMHO the first step
must be to write/complete a glossary that matches *current usage* in
pro-git.  We can perhaps bikeshed about some glaring issues in the
result, but remember that -- again assuming G+E is the conclusion -- any
such change again either means a divergence between book and git (bad!)
or a lot of work for the book translators.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: English/German terminology, git.git's de.po, and pro-git

[Christian Stimming]

Dear translators,

Here's the main point in this discussion: The translation is not for us! The 
translation is for those who don't speak much English and who don't know the 
English git terminology very well. By definition, this target audience is not 
present here on this mailing list and in this discussion. Hence, arguments 
such as "I like word x better" are rather weak. Instead, stating "Word x gives 
the intended target audience a better picture of what is going on" is probably 
a better argument.

Am Montag, 13. Mai 2013, 14:54:51 schrieb Thomas Rast:
> However, an unfortunate and unsatisfactory situation has developed:
> Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
> Thielow built core git's de.po on top of it, so it's also Ger.
> 
> Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
> translation of pro-git (which is also quite mature at this point, having
> apparently begun in 2009), and as you probably guessed by now, it's G+E.

Thanks, Thomas, for spotting the conflicting translations in those excellent 
book projects vs. the git core and git gui. I think it's rather obvious why 
the pro-git translators chose the G+E approach for their work: Their goal is 
to explain the command line usage of git, which means they inevitably have to 
use the git command names, which happen to be in English (and will surely stay 
so). Hence, any translation approach will have to deal with the English 
command names as useful words in the normal translated text. That's probably a 
constraint that is true for any translation of a command-line tool to stay 
useful.

I noticed with some amusement, though, that even in the pro-git book with the 
described constraint there are places where a "pure Ger" translation is almost 
shining through... Such as in [1]: "Jedes Mal, wenn Du committest (d.h. den 
gegenwärtigen Status deines Projektes als eine Version in Git speicherst)..." 
Can you notice how the translators identified "Version" as translation for 
"commit (noun)" and "speichern" as translation for "commit (verb)" :-) ? Of 
course this is just the explanation and not the actual translation later 
during the text. 

However, I take this spot as an example that there exist meaningful pure-Ger 
translations even for the most important git terminology. In fact, to find 
useful Ger translations, I wonder how I would talk to someone from the target 
audience a sentence such as "Finde mal den richtigen Commit, also die Version, 
..." When I find myself saying such an " - also das xy -" appendix often 
enough, I take this as an indication that the latter word can just as well be 
used as the main translation.

Back to the original question: I think the book shows quite nicely that for 
working with the git command line, a G+E translation is more useful as long as 
the command names also appear unchangedly in the translation. However, 
everything else that does not appear as a command name can be translated 
either in G+E or in Ger. The argument can go on to state that someone who is 
geek enough to use the command line is probably more proficient in English 
language anyway. Hence, using more English terms in the translation is 
probably fine as well and a full G+E translation is probably a good approach. 

The pro-git book has some places where the translated word is not always used 
consistently (e.g. in [2] "Externes Repository" vs. "Remote Repository"), and 
some G+E suggestions from this mailing list have been translated Ger in the 
book (they use "zusammenführen" in [2] and [3] instead of "merge" with only a 
few exceptions). It is also a good point to make the pro-git and git core 
translation consistent, once the approach is decided on.

*However*: This argument is completely different when we talk about the GUI 
tools. The target audience of the git gui etc. are those developers who write 
great code, but #1 do not know the English language well enough, and #2 are so 
far away from the geek corner that they use a development workflow purely in 
GUI tools. The question is: What GUI button labels helps those people the most 
to get a good picture of what is going on? And in this case I still believe a 
pure Ger translation is the better choice! I wonder how feedback on this claim 
can be collected from developers of the target audience. When I started on the 
git-gui translation, I asked some coworkers that fall into this category for 
feedback on the wordings, and their response indicated agreement to my 
approach. What feedback have others here heard from people who fall into 
described category? At the end of the day that sort of feedback has to be the 
ground for a decision on the approach in the GUI translation. 

In the meantime I think a different translation approach between git core and 
git gui is not a problem at all. For git gui I propose to stick to a Ger 
translation. For git core and the books that describe the command line 
interface, a G+E translation is probably a good choice but even in 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

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

2013/5/16 Holger Hellmuth (IKS) <hellmuth@ira.uka.de>:
>
>> +    bare repository        = bloßes Repository
>
>
> Since "bloßes Rep." does not convey any sensible meaning to a german reader
> (at least it doesn't to me) it might as well be "bare". Also bare is used as
> parameter to commands
>
>
>> +    remote tracking branch = externer Übernahmezweig
>
>
> Anyone used to the english client will switch as soon as he has to read
> this. No idea how to improve that though except to just use the english
> terms like the pro git translation does.
>
>
>> +    upstream branch        = -||-
>
>
> Use upstream as it is used as parameter to commands
>
>> +    fetch = anfordern
>
> fetch = fetch
>>
>> +    pull  = zusammenführen
>
> pull = pull
>>
>> +    push  = versenden
>
> push = push
>
> established vocabulary used in stack programming as well as in vcs. Should
> not be translated.
>

I think the messages would become a bit too G+E when we'd say something
like "Das Fetchen in den Branch...", "Fetche von %s". Some for merge as
a verb.

>> +    clean(verb)        =
>
> clean(verb) = säubern/aufräumen
>>
>> +    clean(noun)        =
>
> clean(noun) = Säuberung
>
> "aufräumen" is the better verb but there is no noun for it.
>
>
>> +    whitespace         = Leerzeichen (FIXME?) (maybe "Leerraum")
>
> whitespace = whitespace
>
> There is no german word for whitespace
>
>
>> +Still being worked out:
>> +
>> +    prune              = veraltete(n) Zweig(e) entfernen
>> +    checkout(verb)     = auschecken
>> +
>> +    git add      = hinzufügen
>
>
> "mittels "git add" hinzufügen" if you want to emphasize that you add
> something with the command
>
>
>> +
>> +    merge conflict = Merge-Konflikt
>> +    3-way merge    = 3-Wege-Merge
>> +    paths          = Pfade
>> +
>> +    symbolic link = symbolische Verknüfung
>> +    path = Pfad
>> +    link = Verknüpfung
>> +
>> +    reflog = Referenzprotokoll
>> +    partial commit = teilweise committen, partiell committen
>
>
> As a noun, "Teil-Commit"
>
>
>> +
>> +    reset = neu setzen (maybe "umsetzen"?)
>
>
> "zurücksetzen"
>
>

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

Thanks

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

2013/5/16 Thomas Rast <trast@inf.ethz.ch>:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
>> Hi,
>>
>> I think the discussion might work better via ML than GitHub.
>> This is the full glossary of git's de.po as it would look
>> like with (hopefully) all the changes included that have been
>> discussed here. Still without any reasoning for decisions
>> (except HEAD).
> [...]
>> +    remote branch          = externer Zweig
>> +    remote tracking branch = externer Übernahmezweig
>
> Hrm, before we (erm, you) do any extensive work on redoing the glossary,
> I think we should step back and agree on a direction.
>
> Remember what this thread started with:
>
> } However, an unfortunate and unsatisfactory situation has developed:
> } Christian Stimming's git-gui de.po uses a Ger translation, and Ralf
> } Thielow built core git's de.po on top of it, so it's also Ger.
> }
> } Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a
> } translation of pro-git (which is also quite mature at this point, having
> } apparently begun in 2009), and as you probably guessed by now, it's G+E.
> }
> } So that leaves us at a point where "the" libre Git book (and also the
> } one that happens to be hosted on git-scm.com, the official site) does
> } not match the terminology used by German git.
> }
> } Like, at all.  They're not even remotely near each other.
>
> My thinly veiled opinion in the thread starter was that we should redo
> git's de.po from scratch using a translation similar to pro-git.
>
> I can accept that discussion takes a different turn, and thus the
> translation does something else.  But my impression in the thread so far
> was that:
>
> * Everyone voted for G+E.
>
> * The thread went of on a tangent, bikeshedding on some Ger
>   translations.
>
> Please tell me I'm wrong...
>
> Otherwise, assuming any agreement can be reached, IMHO the first step
> must be to write/complete a glossary that matches *current usage* in
> pro-git.  We can perhaps bikeshed about some glaring issues in the
> result, but remember that -- again assuming G+E is the conclusion -- any
> such change again either means a divergence between book and git (bad!)
> or a lot of work for the book translators.
>

Well, that's what I'm trying to do, writing a new glossary. But I took
the current git's de.po glossay as the base, because it's the biggest one
and easier to apply to de.po instead of using a complete new one.
I tried to merge [1] (link is dead) to match ProGit-Book where it's possible.
IMO it's OK if we don't match the ProGit-book in all terms (I didn't do it with
intention), but it's not OK if the translations are so far away from each other
that it becomes a problem to the users because they're using totally different
"languages".
What I'm doing now is collecting objections and suggestions from others (ML, GH)
and apply them to the glossary in order to get a version where everybody
more or less agree with.

[1] https://github.com/progit/progit/blob/master/de/NOTES

> --
> Thomas Rast
> trast@{inf,student}.ethz.ch

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

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

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

2013/5/16 Holger Hellmuth (IKS) <hellmuth@ira.uka.de>:
>
[...]
>> +    reset = neu setzen (maybe "umsetzen"?)
>
>
> "zurücksetzen"
>

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

Re: English/German terminology, git.git's de.po, and pro-git

[Holger Hellmuth]

Am 19.05.2013 18:56, schrieb Ralf Thielow:
> 2013/5/16 Holger Hellmuth (IKS) <hellmuth@ira.uka.de>:
>>
> [...]
>>> +    reset = neu setzen (maybe "umsetzen"?)
>>
>>
>> "zurücksetzen"
>>
>
> "reset" can be used with every existing commit. "zurücksetzen"
> would imply that it have to be a recent commit, no?

It implies that it sets to something that already existed or came before.
So it even fits in a case where you reset to an older commit and reset 
back to HEAD because the HEAD commit existed already.

If you still don't like it, I would prefer "umsetzen" to "neu setzen".

Re: English/German terminology, git.git's de.po, and pro-git

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

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

> 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

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

>     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

Yes

> Diff/patch related:
> 
>     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.

>     whitespace         = Whitespace

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


> Still being worked out:
> 
>     prune              = veraltete(n) Branch(es) entfernen

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

>     checkout(verb)     = auschecken
> 
>     git add      = hinzufügen
> 
>     merge conflict = Merge-Konflikt
>     3-way merge    = 3-Wege-Merge

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

>     paths          = Pfade
> 
>     symbolic link = symbolische Verknüfung
>     path = Pfad
>     link = Verknüpfung
> 
>     reflog = Referenzprotokoll
>     partial commit (verb) = teilweise committen, partiell committen

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

>     partial commit (noun) = Teil-Commit
> 
>     reset = neu setzen (maybe "umsetzen"?)
> 
>     register   = in die Konfiguration eintragen
>     unregister = aus der Konfiguration austragen

Best Regards,

Christian

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

2013/5/20 Holger Hellmuth <holger@gspranz.de>:
> Am 19.05.2013 18:56, schrieb Ralf Thielow:
>
>> 2013/5/16 Holger Hellmuth (IKS) <hellmuth@ira.uka.de>:
>>>
>>>
>> [...]
>>>>
>>>> +    reset = neu setzen (maybe "umsetzen"?)
>>>
>>>
>>>
>>> "zurücksetzen"
>>>
>>
>> "reset" can be used with every existing commit. "zurücksetzen"
>> would imply that it have to be a recent commit, no?
>
>
> It implies that it sets to something that already existed or came before.
> So it even fits in a case where you reset to an older commit and reset back
> to HEAD because the HEAD commit existed already.
>
> If you still don't like it, I would prefer "umsetzen" to "neu setzen".
>

I'd still understand "zurücksetzen" as "set something *back* to" but this
"back" can also be something that was made after HEAD perhaps on
another branch and HEAD (or the current ref) was never at this point before,
so "zurücksetzen" is not true in this case.

I prefer "umsetzen" to "neu setzen", too. I'll change the glossary to this.

Thanks

> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@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]

2013/5/20 Christian Stimming <stimming@tuhh.de>:
> Thanks for the update. I would like to add some comments on this G+E glossary
> and I hope you are interested in reading those, even though it is known that I
> prefer a "pure Ger" translation. However, as I wrote in my other message I
> agree that for the command line tool the criteria for choosing the translation
> approach are different from those for a GUI tool. So I can very well envision
> a good G+E translation for git core and subsequently all related books.
>

Thanks for your comments.

> Am Sonntag, 19. Mai 2013, 18:53:18 schrieb Ralf Thielow:
>> Basic repository objects:
>>
>>     blob           = Blob
>>     tree           = Baum, Baum-Objekt (bevorzugt), "Tree"-Objekt
>>     submodule      = Submodul
>>     pack(noun)     = Pack-Datei
>>     pack(verb)     = packen (ggf. Pack-Datei erstellen)
>>     ancestor       = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt)
>
> Yes. Does the "Pack-Datei" appear anywhere in the book? I wouldn't understand
> the term, but then again, this is probably because I don't understand the
> semantic of this thingy as a repository object regardless of the language...
>

The book has this word in it's index ("9.4 Pack-Dateien")
http://git-scm.com/book/de
so we're fine here.

While at there, I just read "Die Refspec" in the index. The current glossary
doesn't contain "refspec" and we translate is as "Referenzspezifikation".
So if we want to match the book, we should add "refspec = Refspec" to
the glossary.

>> Content in a repository:
>>
>>     file(s)        = Datei(en)
>>     tracked file   = beobachtete Datei
>>     track file     = beobachte Datei
>>     untracked file = unbeobachtete Datei
>>     directory      = Verzeichnis
>
> Yes.
>
>> Repositories / tracking concepts:
>>
>>     clone (verb)           = klonen
>>     clone (noun)           = der Klon
>>     repository             = Repository
>>     bare repository        = Bare Repository
>
> Yes. After some evaluation of the git-gui translation I think using
> "Repository" there as well is probably the better choice.
>
>>     working directory      = Arbeitsverzeichnis
>>     working tree           = -||-
>>
>>     remote branch          = Remote-Branch
>>     remote-tracking branch = Remote-Tracking-Branch
>>     upstream branch        = Upstream-Branch
>
> Yes. What's the main reason for using "Branch" in the German text? Consistency
> with the commands, or assumed familiarity of the term within the target
> audience? "Zweig" is available.
>

I think it's at the same level as "Commit" and a well known SCM-term. Users
(even beginners) who know "Commit" and "Tag" do also know "Branch". And
I think it sounds better in combination with "Remote-", "Remote-Tracking-" and
"Upstream-" which are english words.

>>     remote repository      = Remote-Repository
>>     remote(noun)           = -||-
>>     remote(adj)            = extern, entfernt liegend
>>
>> Authorship:
>>
>>     author    = Autor
>>     committer = Commit-Ersteller
>>     tagger    = Tag-Ersteller
>
> Yes.
>
>> Commits, tags and other references:
>>
>>     HEAD           = HEAD
>> Konzept aus der Git-Welt, daher nicht zu übersetzen.
>>     detached HEAD  = losgelöster HEAD
>>
>>     commit(noun)      = Commit
>>     commit(verb)      = committen
>>     commit the result = das Ergebnis committen
>>     parent commit     = Eltern-Commit
>>     child commit      = Kind-Commit
>>     commit message    = Commit-Beschreibung
>
> Yes, for the G+E approach.
>
>>     stash(noun)       = der Stash
>>     stash(verb)       = "stashen", "stash" benutzen (bevorzugt)
>>     unstash(verb)     = "unstashen", "zurückladen", "aus 'stash'
>> zurückladen" (bevorzugt)
>
> Using "Stash" in G+E is quite ugly, but the noun is probably unavoidable
> because the feature is pretty much unique to git. I'd suggest to use only the
> noun and use the verbs as "stash benutzen" and "aus stash zurückladen" as
> proposed.
>

Yes.

>>     reference      = Referenz
>>     revision       = Commit
>>     branch         = Branch
>>     tag(noun)      = Tag
>>     tag(verb)      = taggen, Tag erstellen
>>     annotated tag  = annotierter Tag
>>     tag message    = Tag-Beschreibung
>
> I've commented on "Branch" above. As for "Tag": Yes, the term is familiar
> among the target audience. However, do you really want this noun which is the
> same word as "Tag wie in Datum"? Some more disambiguation between the tag and
> the date would be helpful, wouldn't it?
> The derived forms are fine, and also here I'd suggest to use only the G+E noun
> but construct the verbs with other German words: "Tag erstellen".
>
>>     stage/index (noun) = Staging-Area, Index
>>     stage/index (verb) = (für einen | zum) Commit vormerken
>> (bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen
>>     unstage (verb)     = aus Staging Area entfernen, aus Index entfernen
>
> I'd strongly suggest not to use "Index". I've never understood why this term
> showed up in the English wording to begin with. It took me years until I got
> the point that from the user's point of view, this thingy has nothing to do
> with a book's index or a database's index, which is where I go to look up more
> 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.
>

Yes.

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

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

>> 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
>
> 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.)
>
>>     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
>
> Yes
>
>> Diff/patch related:
>>
>>     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.

>>     whitespace         = Whitespace
>
> Yes. Indeed I haven't heard a good German word that transports the same
> meaning.
>
>
>> Still being worked out:
>>
>>     prune              = veraltete(n) Branch(es) entfernen
>
> Yes, and it makes me even understand what the command is about to do.
>
>>     checkout(verb)     = auschecken
>>
>>     git add      = hinzufügen
>>
>>     merge conflict = Merge-Konflikt
>>     3-way merge    = 3-Wege-Merge
>
> If merge was "zusammenführen" above, it should be "Zusammenführungs-Konflikt"
> here, and "3-Wege-Zusammenführung".
>

Yes.

>>     paths          = Pfade
>>
>>     symbolic link = symbolische Verknüfung
>>     path = Pfad
>>     link = Verknüpfung
>>
>>     reflog = Referenzprotokoll
>>     partial commit (verb) = teilweise committen, partiell committen
>
> Teilweise committen. (No partial derivatives here...)
>

Yes.

>>     partial commit (noun) = Teil-Commit
>>
>>     reset = neu setzen (maybe "umsetzen"?)
>>
>>     register   = in die Konfiguration eintragen
>>     unregister = aus der Konfiguration austragen
>
> Best Regards,
>
> Christian

Re: English/German terminology, git.git's de.po, and pro-git

[Holger Hellmuth (IKS)]

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

Re: English/German terminology, git.git's de.po, and pro-git

[Jan Engelhardt]

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

Re: English/German terminology, git.git's de.po, and pro-git

[Bernhard R. Link]

* Ralf Thielow <ralf.thielow@gmail.com> [130522 17:17]:
> >>     remote branch          = Remote-Branch
> >>     remote-tracking branch = Remote-Tracking-Branch
> >>     upstream branch        = Upstream-Branch
> >
> > Yes. What's the main reason for using "Branch" in the German text? Consistency
> > with the commands, or assumed familiarity of the term within the target
> > audience? "Zweig" is available.
> >
> 
> I think it's at the same level as "Commit" and a well known SCM-term. Users
> (even beginners) who know "Commit" and "Tag" do also know "Branch". And
> I think it sounds better in combination with "Remote-", "Remote-Tracking-" and
> "Upstream-" which are english words.

Additionally "Zweig" might be a bit misleading. A branch is not part of
the "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

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

2013/5/23 Bernhard R. Link <brl+git@mail.brlink.eu>:
> * Ralf Thielow <ralf.thielow@gmail.com> [130522 17:17]:
>> >>     remote branch          = Remote-Branch
>> >>     remote-tracking branch = Remote-Tracking-Branch
>> >>     upstream branch        = Upstream-Branch
>> >
>> > Yes. What's the main reason for using "Branch" in the German text? Consistency
>> > with the commands, or assumed familiarity of the term within the target
>> > audience? "Zweig" is available.
>> >
>>
>> I think it's at the same level as "Commit" and a well known SCM-term. Users
>> (even beginners) who know "Commit" and "Tag" do also know "Branch". And
>> I think it sounds better in combination with "Remote-", "Remote-Tracking-" and
>> "Upstream-" which are english words.
>
> Additionally "Zweig" might be a bit misleading. A branch is not part of
> the "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.

Re: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

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

Re: English/German terminology, git.git's de.po, and pro-git

[Jan Engelhardt]

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