2013/5/20 Christian Stimming <stimm...@tuhh.de>:
> Thanks for the update. I would like to add some comments on this G+E glossary
> and I hope you are interested in reading those, even though it is known that I
> prefer a "pure Ger" translation. However, as I wrote in my other message I
> agree that for the command line tool the criteria for choosing the translation
> approach are different from those for a GUI tool. So I can very well envision
> a good G+E translation for git core and subsequently all related books.
>
Thanks for your comments.
> Am Sonntag, 19. Mai 2013, 18:53:18 schrieb Ralf Thielow:
>> Basic repository objects:
>>
>> blob = Blob
>> tree = Baum, Baum-Objekt (bevorzugt), "Tree"-Objekt
>> submodule = Submodul
>> pack(noun) = Pack-Datei
>> pack(verb) = packen (ggf. Pack-Datei erstellen)
>> ancestor = Vorfahre, Vorgänger, Vorgänger-Commit (bevorzugt)
>
> Yes. Does the "Pack-Datei" appear anywhere in the book? I wouldn't understand
> the term, but then again, this is probably because I don't understand the
> semantic of this thingy as a repository object regardless of the language...
>
The book has this word in it's index ("9.4 Pack-Dateien")
http://git-scm.com/book/de
so we're fine here.
While at there, I just read "Die Refspec" in the index. The current glossary
doesn't contain "refspec" and we translate is as "Referenzspezifikation".
So if we want to match the book, we should add "refspec = Refspec" to
the glossary.
>> Content in a repository:
>>
>> file(s) = Datei(en)
>> tracked file = beobachtete Datei
>> track file = beobachte Datei
>> untracked file = unbeobachtete Datei
>> directory = Verzeichnis
>
> Yes.
>
>> Repositories / tracking concepts:
>>
>> clone (verb) = klonen
>> clone (noun) = der Klon
>> repository = Repository
>> bare repository = Bare Repository
>
> Yes. After some evaluation of the git-gui translation I think using
> "Repository" there as well is probably the better choice.
>
>> working directory = Arbeitsverzeichnis
>> working tree = -||-
>>
>> remote branch = Remote-Branch
>> remote-tracking branch = Remote-Tracking-Branch
>> upstream branch = Upstream-Branch
>
> Yes. What's the main reason for using "Branch" in the German text? Consistency
> with the commands, or assumed familiarity of the term within the target
> audience? "Zweig" is available.
>
I think it's at the same level as "Commit" and a well known SCM-term. Users
(even beginners) who know "Commit" and "Tag" do also know "Branch". And
I think it sounds better in combination with "Remote-", "Remote-Tracking-" and
"Upstream-" which are english words.
>> remote repository = Remote-Repository
>> remote(noun) = -||-
>> remote(adj) = extern, entfernt liegend
>>
>> Authorship:
>>
>> author = Autor
>> committer = Commit-Ersteller
>> tagger = Tag-Ersteller
>
> Yes.
>
>> Commits, tags and other references:
>>
>> HEAD = HEAD
>> Konzept aus der Git-Welt, daher nicht zu übersetzen.
>> detached HEAD = losgelöster HEAD
>>
>> commit(noun) = Commit
>> commit(verb) = committen
>> commit the result = das Ergebnis committen
>> parent commit = Eltern-Commit
>> child commit = Kind-Commit
>> commit message = Commit-Beschreibung
>
> Yes, for the G+E approach.
>
>> stash(noun) = der Stash
>> stash(verb) = "stashen", "stash" benutzen (bevorzugt)
>> unstash(verb) = "unstashen", "zurückladen", "aus 'stash'
>> zurückladen" (bevorzugt)
>
> Using "Stash" in G+E is quite ugly, but the noun is probably unavoidable
> because the feature is pretty much unique to git. I'd suggest to use only the
> noun and use the verbs as "stash benutzen" and "aus stash zurückladen" as
> proposed.
>
Yes.
>> reference = Referenz
>> revision = Commit
>> branch = Branch
>> tag(noun) = Tag
>> tag(verb) = taggen, Tag erstellen
>> annotated tag = annotierter Tag
>> tag message = Tag-Beschreibung
>
> I've commented on "Branch" above. As for "Tag": Yes, the term is familiar
> among the target audience. However, do you really want this noun which is the
> same word as "Tag wie in Datum"? Some more disambiguation between the tag and
> the date would be helpful, wouldn't it?
> The derived forms are fine, and also here I'd suggest to use only the G+E noun
> but construct the verbs with other German words: "Tag erstellen".
>
>> stage/index (noun) = Staging-Area, Index
>> stage/index (verb) = (für einen | zum) Commit vormerken
>> (bevorzugt), zur Staging Area hinzufügen, dem Index hinzufügen
>> unstage (verb) = aus Staging Area entfernen, aus Index entfernen
>
> I'd strongly suggest not to use "Index". I've never understood why this term
> showed up in the English wording to begin with. It took me years until I got
> the point that from the user's point of view, this thingy has nothing to do
> with a book's index or a database's index, which is where I go to look up more
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
