From: Christian Stimming <hidden> Date: 2016-06-15 22:44:33
Attached to avoid whitespace problems. This patch is against master of
gitk.git at git.kernel.org.
By the way, the following two keybinding explanations seem ambiguous to me:
<Home> Move to first commit
<End> Move to last commit
What happens is that <home> jumps to the newest commit and <end> jumps to the
oldest commit. Whether the "first" commit should be the newest or the oldest
is, well, somewhat ambiguous. I'd propose to talk about the newest or topmost
commit, but rather not about the "first".
Regards,
Christian
From: Stephan Beyer <hidden> Date: 2016-06-15 22:44:33
I'd propose to talk about the newest or topmost commit,
but rather not about the "first".
I agree, but s/newest/latest/ :)
Well.
Although your patch does not cover the translations itself (and although
I neither use the German translation of gitk and use gitk very seldom at
all), I've taken a look at the given translations and want to drop some
comments/corrections.
Is "Version" really the German translation for "commit" throughout the
whole git suite?
(Ehh, is git translated at all?)
I'd recommend "Commit" or "Eintragung"...
"Version" is so CVS/SVN-like.
-#: gitk:264
+#: gitk:275
msgid "Can't parse git log output:"
msgstr "Git log Ausgabe kann nicht erkannt werden:"
Hm, the button lists branches and tags.
Is then "Zweige" (= branches) only correct?
What about "Referenzen auflisten" or "Zweige/Markierungen auflisten"
(or however "tags" is translated).
"Versionierender" ... No, just a bad joke ;-)
The translation is good.
-#: gitk:1026
+#: gitk:1061
msgid "Cherry-pick this commit"
msgstr "Diese Version pfl??cken"
If I didn't knew that it means "cherry-pick", I'd have no idea
what the function behind that German words does. ;-)
(That's why I don't have locales set to my mother tongue. Just because I
only have to understand the programmer and not the translator first.)
"Diesen Commit übernehmen"
"Diesen Commit kopieren"
"Diese Eintragung übernehmen"
+#: gitk:1354
+msgid "<Left>, z, j\tGo back in history list"
+msgstr "<Links>, z, j\tEine Version zur??ck gehen"
I think it's still "zurückgehen" and not "zurück gehen" in the latest
German spelling.
+#: gitk:1355
+msgid "<Right>, x, l\tGo forward in history list"
+msgstr "<Rechts>, x, l\tEine Version nach vorne gehen"
"nach vorne gehen" sounds so colloquial.
Better, perhaps: "weitergehen"?
From: Paul Mackerras <hidden> Date: 2016-06-15 22:44:33
Christian Stimming writes:
Attached to avoid whitespace problems. This patch is against master of
gitk.git at git.kernel.org.
Thanks.
By the way, the following two keybinding explanations seem ambiguous to me:
quoted
<Home> Move to first commit
<End> Move to last commit
What happens is that <home> jumps to the newest commit and <end> jumps to the
oldest commit. Whether the "first" commit should be the newest or the oldest
is, well, somewhat ambiguous. I'd propose to talk about the newest or topmost
commit, but rather not about the "first".
Well, the commits aren't in date order, strictly speaking, and the
last commit isn't necessarily the oldest (though the first commit will
in fact be the newest). How about:
<Home> Move to head of list
<End> Move to tail of list
Would that be any clearer?
Paul.
From: Christian Stimming <hidden> Date: 2016-06-15 22:44:33
Am Freitag, 2. Mai 2008 13:49 schrieb Paul Mackerras:
quoted
By the way, the following two keybinding explanations seem ambiguous to
me:
quoted
quoted
<Home> Move to first commit
<End> Move to last commit
What happens is that <home> jumps to the newest commit and <end> jumps to
the oldest commit. Whether the "first" commit should be the newest or the
oldest is, well, somewhat ambiguous. I'd propose to talk about the newest
or topmost commit, but rather not about the "first".
Well, the commits aren't in date order, strictly speaking, and the
last commit isn't necessarily the oldest (though the first commit will
in fact be the newest). How about:
<Home> Move to head of list
<End> Move to tail of list
Would that be any clearer?
I think "head of list" and "tail of list" are more the terms about the
implementation detail and not so much an explanation that is easily
understood for the user. I think some combination using the word "top" should
rather be used to make it really clear we're talking about the upper end of
the window.
Christian
From: Christian Stimming <hidden> Date: 2016-06-15 22:44:33
Am Donnerstag, 1. Mai 2008 23:10 schrieb Stephan Beyer:
quoted
I'd propose to talk about the newest or topmost commit,
but rather not about the "first".
I agree, but s/newest/latest/ :)
Both is possible, and a third alternative is "most recent". I couldn't care
less, as long as we get away from the ambiguous "first".
Well.
Although your patch does not cover the translations itself (and although
I neither use the German translation of gitk and use gitk very seldom at
all), I've taken a look at the given translations and want to drop some
comments/corrections.
Thanks for the feedback about the German translation. Indeed there is no git
translation into German, at least none that I know of so far. What exists is
the translation of git-gui which includes a glossary of terms that are used
throughout git-gui (and git). That glossary and the git-gui translation was
created by myself as well. At the time when the glossary was created, it was
also discussed here in the list quite a lot, see
http://article.gmane.org/gmane.comp.version-control.git/53181 and more
importantly this whole thread
http://kerneltrap.org/mailarchive/git/2007/9/16/269956 (somehow gmane.org
doesn't have this thread available?!?)
Hence, translations for terms like "commit" have indeed been discussed quite a
bit, and I'm quite satisfied with the current wording. You're welcome to
propose alternatives, but please be prepared to give really good reasons as
for why an alternative is really better than the current version.
Nevertheless thanks a lot for the typos you spotted. I'll list those that are
easy and I agree upon first, and I'll comment on the other and more difficult
words later.
+++ The easy ones:
quoted
-#: gitk:264
+#: gitk:275
msgid "Can't parse git log output:"
msgstr "Git log Ausgabe kann nicht erkannt werden:"
Hm, the button lists branches and tags.
Is then "Zweige" (= branches) only correct?
What about "Referenzen auflisten" or "Zweige/Markierungen auflisten"
(or however "tags" is translated).
+#: gitk:1354
+msgid "<Left>, z, j\tGo back in history list"
+msgstr "<Links>, z, j\tEine Version zur??ck gehen"
I think it's still "zurückgehen" and not "zurück gehen" in the latest
German spelling.
Ok.
quoted
+#: gitk:1355
+msgid "<Right>, x, l\tGo forward in history list"
+msgstr "<Rechts>, x, l\tEine Version nach vorne gehen"
"nach vorne gehen" sounds so colloquial.
Better, perhaps: "weitergehen"?
Ok. "weitergehen" IMHO has a similar problem as the first/last issue - the
user doesn't know which direction is meant. But your proposal is better than
the colloquial term.
Is "Version" really the German translation for "commit" throughout the
whole git suite?
(Ehh, is git translated at all?)
I'd recommend "Commit" or "Eintragung"...
"Version" is so CVS/SVN-like.
"Version" is what came out as most convincing from last September's
discussion. "Commit" is only for those who want the English version anyway,
hence that's not the target audience of this translation. "Eintragung" would
indeed be one possibility, but when I explain how git works to other Germans,
I would always talk about the "Versionen" that you can browse and merge and
add. The word works quite nicely, which is another argument for it. On the
other hand I don't understand how "is so CVS-like" would be any argument in
favor or against this particular German word.
No. Please have a look at the place where this is used. In fact this word is
used as the part of a full sentence (which in itself is very bad i18n style,
but that's another discussion), and the sentence reads "Suche nächste/vorige
Version enthaltend:". The sentence is already quite "holprig" and I'm sorry
for that, but at least it is still gramatically correct. Using "enthält"
would make it gramatically wrong. Same for the other following strings that
you mentioned.
The translation is rather ambiguous. Or is it just me? ;)
"Ignoriere Groß-/Kleinschreibung" or
"Groß-/Kleinschreibung ignorieren"
In principle yes, but again please have a look at where this string actually
appears in the program. The multichoice box there really must not be very
wide. That's why I came up with this weird short form
of "Groß-/Kleinschreibung ignorieren", but the original string is just as
well already a weird abbreviation.
quoted
-#: gitk:1026
+#: gitk:1061
msgid "Cherry-pick this commit"
msgstr "Diese Version pfl??cken"
If I didn't knew that it means "cherry-pick", I'd have no idea
what the function behind that German words does. ;-)
(That's why I don't have locales set to my mother tongue. Just because I
only have to understand the programmer and not the translator first.)
No, you're missing the point again. If you didn't knew what "cherry-pick"
means, you would have no idea what the function behind it does. In other
words: Git invented a new word here anyway. Hence, a new word will appear in
the translation, too, and it isn't an argument that you didn't recognize it
as your familiar english word at first. It *is* an argument if the actual
action can be described in a better and more understandable way by a
different German word, though.
"Diese Version kopieren" would be one possibility - but this bears the
question why git itself doesn't call this action "to copy a commit". To
me, "Version kopieren" rather sounds like the familiar "copy to clipboard"
action in the Edit menu, but it misses the part that this commit will
immediately be committed (heh) to the currently checked out branch.
I agree the original string is sub-optimal, but "Erzeugung"? Also not a nice
word. Anything better?
Thank you very much for your feedback!
Regards,
Christian
From: Christian Stimming <hidden> Date: 2016-06-15 22:44:33
This includes the fixed typos and proposals by Stephan Beyer that were easy to
agree upon.
This patch is to be committed on top of yesterday's German translation patch.
Regards,
Christian
(Attached because of whitespace yadda yadda)
Is "Version" really the German translation for "commit" throughout the
whole git suite?
(Ehh, is git translated at all?)
I'd recommend "Commit" or "Eintragung"...
"Version" is what came out as most convincing from last September's
discussion. "Commit" is only for those who want the English version
anyway, hence that's not the target audience of this translation.
I understand the point for using "Version" as the German translation for
the noun "commit" (seems to be the best choice), but I think I have a
different view on the target audience of the translation. :-)
I think, most of the users of a translated git-gui or gitk are not people
who do not understand an English word at all. I think, they just like to
act in a localized environment.
But SCM tool users of any nationality usually know what a "commit" is,
so I see nothing bad in using "Commit" in the German translation.
And the German word "Version" is a broader term that can lead to some
misunderstanding; the English word "commit" used in German sentences
is a clear technical term for SCM tool users.
It's the typical problem in German technical literature. There is the one
type where every technical term is translated to a German word in the hope
that it will be easier to understand but could also leave the reader in
some confusion because she has another understanding of the known word.
And there is the other type, where technical terms are kept untranslated
to let the readers easily understand original English literature
but also resulting in a lot of "denglisch" sentences.
So a really good translation of technical literature and its technical
terms is pretty hard.
The most German translations in the free software world are translated
using the first, the "translate every term" paradigm. So it seems good
to me that gitk/git-gui follows that way. Nevertheless, just because of
this paradigm I switched back to the original/English versions. ;)
quoted
"nach vorne gehen" sounds so colloquial.
Better, perhaps: "weitergehen"?
Ok. "weitergehen" IMHO has a similar problem as the first/last issue - the
user doesn't know which direction is meant.
Mh, I thought that "nach vorne" and "weiter" have the same meaning here.
But perhaps I'm wrong.
But your proposal is better than the colloquial term.
I don't know if colloquial terms are really bad in software.
Perhaps it depends on the software. E.g. in games or fun tools it can be nice.
I agree the original string is sub-optimal, but "Erzeugung"? Also not a
nice word. Anything better?
Sorry, I meant "Fehler beim Erzeugen des Patches"
as in
> > > msgid "Error writing commit:"
> > > msgstr "Fehler beim Version eintragen:"
> > [...]
> "Fehler beim Schreiben der Version" it is, thanks.
(which also could be "Fehler beim Eintragen der Version")
The reason for my correction is that "beim Version eintragen"
is wrong according to my last look at the German grammar rules,
but note that I'm not up-to-date ;-)
A correct choice could be something like "beim Versionseintragen"
or "beim Version-Eintragen" (or Version-eintragen?) Not sure.
So I thought using the Genitive case is a good choice.
Btw, I'm convinced that every German will also understand your
original translation.
quoted
quoted
msgid "containing:"
msgstr "enthaltend:"
"enthält:"
No. Please have a look at the place where this is used.
I did. But you are right that my proposal is wrong.
In fact this word is used as the part of a full sentence
(which in itself is very bad i18n style, but that's another discussion),
and the sentence reads "Suche nächste/vorige Version enthaltend:".
My mistake was that I began reading at "Version"... ;)
The sentence is already quite "holprig"
The original
"Find next/prev commit _containing:_ [insert]"
should be translated to
"Suche nächste/vorige Version, die [insert] enthält."
But this is beyond the used techniques for software translation ;-)
Looking at the other two cases:
"Find next/prev commit _touching paths:_ [insert]"
and
"Find next/prev commit _adding/removing String:_ [insert]"
and looking what they are actually doing,
I come to another solution that should make it clear:
1. "Suche nächste/vorige Version _nach Beschreibung:_ [insert]"
2. "Suche nächste/vorige Version _nach Pfaden:_ [insert]"
(or maybe "nach Dateien:", if it's commonly accepted that
directories are files, too.)
3. "Suche nächste/vorige Version _nach Änderungen:_ [insert]"
(This is btw a very cool feature and a reason to use gitk more often.)
quoted
quoted
msgid "IgnCase"
msgstr "Kein Gro??/Klein"
The translation is rather ambiguous. Or is it just me? ;)
"Ignoriere Groß-/Kleinschreibung" or
"Groß-/Kleinschreibung ignorieren"
In principle yes, but again please have a look at where this string
actually appears in the program. The multichoice box there really must
not be very wide.
Ah ok. I got in a hurry when writing the last mail, but I wondered
why there's "IgnCase" and not "Ignore case".
Hmmm, so I'd possibly take "Groß/klein egal" which has the same length
as yours but yours is also good, since it's not ambiguous to me anymore,
because another choice of the multichoice box is "exakt" ;-)
quoted
quoted
msgid "Cherry-pick this commit"
msgstr "Diese Version pfl??cken"
If I didn't knew that it means "cherry-pick", I'd have no idea
what the function behind that German words does. ;-)
No, you're missing the point again. If you didn't knew what "cherry-pick"
means, you would have no idea what the function behind it does.
Right, but if I know what "cherry-pick" means, I could still have no idea
what the function behind "Version pflücken" does.
A word-by-word translation like "Kirsche pflücken" would also result in a
grinning me (as a user), but I'd recognize it as the 'git-cherry-pick'
that I know.
In other words: Git invented a new word here anyway.
No, "cherry picking" is a commonly used term.
I wonder what a commonly used German phrase with a similar meaning is...
Something like "sich die Rosine(n) herauspicken"? (Is this a common phrase?)
But a translation to "Diese Rosine herauspicken" is also confusing.
("Warum ist dieser Commit eine Rosine?
Was passiert, wenn ich sie herauspicke?
Ist er dann weg?")
It *is* an argument if the actual action can be described in a better
and more understandable way by a different German word, though.
Yes.
A user of the English version might also need to know what
git-cherry-pick does before clicking on "Cherry-pick this commit".
Or does this come by intuition?
(Hard to see for me, as I'm no native English speaker.)
"Diese Version kopieren" would be one possibility - but this bears the
question why git itself doesn't call this action "to copy a commit".
To confuse the translation issue. ;-)
"Version kopieren" rather sounds like the familiar "copy to clipboard"
action in the Edit menu,
Good point.
Btw, 'man git-cherry-pick' says
"Apply the change introduced by an existing commit".
So why not take this and use
"Durch diese Version eingeführte Änderungen übernehmen" or
"Durch diese Version eingeführte Änderungen anwenden"?
Regards,
Stephan
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx
From: Paul Mackerras <hidden> Date: 2016-06-15 22:44:33
Christian Stimming writes:
quoted
Well, the commits aren't in date order, strictly speaking, and the
last commit isn't necessarily the oldest (though the first commit will
in fact be the newest). How about:
<Home> Move to head of list
<End> Move to tail of list
Would that be any clearer?
I think "head of list" and "tail of list" are more the terms about the
implementation detail and not so much an explanation that is easily
understood for the user. I think some combination using the word "top" should
rather be used to make it really clear we're talking about the upper end of
the window.
The list isn't just a detail, it's what the user sees in the top pane:
the commits, listed in some order.
How about "top of list" and "bottom of list"? Or "start of list" and
"end of list"?
Paul.
From: Christian Stimming <hidden> Date: 2016-06-15 22:44:34
Am Samstag, 3. Mai 2008 09:53 schrieb Paul Mackerras:
Christian Stimming writes:
quoted
quoted
Well, the commits aren't in date order, strictly speaking, and the
last commit isn't necessarily the oldest (though the first commit will
in fact be the newest). How about:
<Home> Move to head of list
<End> Move to tail of list
Would that be any clearer?
I think "head of list" and "tail of list" are more the terms about the
implementation detail and not so much an explanation that is easily
understood for the user. I think some combination using the word "top"
should rather be used to make it really clear we're talking about the
upper end of the window.
The list isn't just a detail, it's what the user sees in the top pane:
the commits, listed in some order.
How about "top of list" and "bottom of list"? Or "start of list" and
"end of list"?
I think "top of list" and "bottom of list" would work quite well.
Regards,
Christian
From: Christian Stimming <hidden> Date: 2016-06-15 22:44:35
Hi Stephan,
thanks for your feedback. I won't have time to answer this in detail until end
of next week. I'll just highlight a few things:
* Translation "commit" - "Version": Indeed this depends on the target
audience. Those who prefer the english terms IMHO are by definition no longer
the target audience. That's why I prefer this German word in the translation.
By the way, I strongly suggest reading the German TortoiseSVN documentation -
IMHO they've created a really good translation.
Am Samstag, 3. Mai 2008 03:24 schrieb Stephan Beyer:
quoted
In fact this word is used as the part of a full sentence
(which in itself is very bad i18n style, but that's another discussion),
and the sentence reads "Suche nächste/vorige Version enthaltend:".
My mistake was that I began reading at "Version"... ;)
quoted
The sentence is already quite "holprig"
The original
"Find next/prev commit _containing:_ [insert]"
should be translated to
"Suche nächste/vorige Version, die [insert] enthält."
But this is beyond the used techniques for software translation ;-)
Yes. But maybe even without GUI modifications this can be translated in a
better way. Eventually, I would expect something like this:
Suchen: Nächste / vorige Fundstelle mit Kriterium 'Enthält Zeichenkette':
[insert]
IMHO this shouldn't be one single sentence which is what the current english
GUI tries to mimic. Instead, this should be something with a heading and a
choicebox for the criteria and appropriate labels for those. Maybe we can
come up with a translation that already does this - the above sentence was a
quick thought but there are surely better ways to do this.
quoted
quoted
quoted
msgid "Cherry-pick this commit"
msgstr "Diese Version pflücken"
quoted
In other words: Git invented a new word here anyway.
No, "cherry picking" is a commonly used term.
I wonder what a commonly used German phrase with a similar meaning is...
Something like "sich die Rosine(n) herauspicken"? (Is this a common
phrase?) But a translation to "Diese Rosine herauspicken" is also
confusing. ("Warum ist dieser Commit eine Rosine?
Was passiert, wenn ich sie herauspicke?
Ist er dann weg?")
Good point. We shouldn't come up with "Rosinen" here. Maybe "herauspicken",
but then "pflücken" can work as well. Branches are called "Zweige", so it's
not too far-fetched to have an action for "etwas von einem Zweig pflücken".
Btw, 'man git-cherry-pick' says
"Apply the change introduced by an existing commit".
So why not take this and use
"Durch diese Version eingeführte Änderungen übernehmen" or
"Durch diese Version eingeführte Änderungen anwenden"?
This is indeed a case where a better translation can still be found. However,
all of "kopieren, übernehmen, anwenden" IMHO sound too similar to actions
that already appear here or there in the version control GUI. Cherry-picking
is a specialized action and should thus get a specialized German word.
Regards,
Christian
From: Stephan Beyer <hidden> Date: 2016-06-15 22:44:37
Hi Christian,
quoted
The original
"Find next/prev commit _containing:_ [insert]"
should be translated to
"Suche nächste/vorige Version, die [insert] enthält."
But this is beyond the used techniques for software translation ;-)
Yes. But maybe even without GUI modifications this can be translated in a
better way. Eventually, I would expect something like this:
Suchen: Nächste / vorige Fundstelle mit Kriterium 'Enthält Zeichenkette': [insert]
This can be a choice, but it's very long. ;-)
I want to repeat my suggestions from the last mail:
1. "Suche nächste/vorige Version nach _Beschreibung:_ [insert]"
2. "Suche nächste/vorige Version nach _Pfaden:_ [insert]"
(or maybe "nach _Dateien:_", if it's commonly accepted that
directories are files, too.)
3. "Suche nächste/vorige Version nach _Änderungen:_ [insert]"
which makes it much more clearer than the English original, imho.
IMHO this shouldn't be one single sentence which is what the current english
GUI tries to mimic. Instead, this should be something with a heading and a
choicebox for the criteria and appropriate labels for those.
Yes, if one single sentence does not work in another language, why keep
it? But, one single sentence works here ;-)
quoted
Btw, 'man git-cherry-pick' says
"Apply the change introduced by an existing commit".
So why not take this and use
"Durch diese Version eingeführte Änderungen übernehmen" or
"Durch diese Version eingeführte Änderungen anwenden"?
This is indeed a case where a better translation can still be found. However,
all of "kopieren, übernehmen, anwenden" IMHO sound too similar to actions
that already appear here or there in the version control GUI.
You are right with "kopieren" and "anwenden", but where is "übernehmen"?
Ok, it is used in the glossary for "pull", but nowhere in code that is
actually used. And I think a better translation for "pull" is
something that stresses the fact that "pull" = "fetch" + "merge",
something like "Holen und Zusammenführen".
Cherry-picking is a specialized action and should thus get a specialized
German word.
I'm still unsure about this. But it's your choice. ;-)
Kind regards,
Stephan
--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F
From: Christian Stimming <hidden> Date: 2016-06-15 22:44:38
Hi Stephan,
Am Donnerstag, 15. Mai 2008 18:20 schrieb Stephan Beyer:
quoted
quoted
The original
"Find next/prev commit _containing:_ [insert]"
should be translated to
"Suche nächste/vorige Version, die [insert] enthält."
But this is beyond the used techniques for software translation ;-)
I want to repeat my suggestions from the last mail:
1. "Suche nächste/vorige Version nach _Beschreibung:_ [insert]"
2. "Suche nächste/vorige Version nach _Pfaden:_ [insert]"
(or maybe "nach _Dateien:_", if it's commonly accepted that
directories are files, too.)
3. "Suche nächste/vorige Version nach _Änderungen:_ [insert]"
which makes it much more clearer than the English original, imho.
Okay, I've inserted your suggestions in my translation update. I'm not too
sure about any translation of this part, but your proposal is maybe better
than the existing one.
quoted
quoted
Btw, 'man git-cherry-pick' says
"Apply the change introduced by an existing commit".
So why not take this and use
"Durch diese Version eingeführte Änderungen übernehmen" or
"Durch diese Version eingeführte Änderungen anwenden"?
This is indeed a case where a better translation can still be found.
However, all of "kopieren, übernehmen, anwenden" IMHO sound too similar
to actions that already appear here or there in the version control GUI.
You are right with "kopieren" and "anwenden", but where is "übernehmen"?
Ok, it is used in the glossary for "pull", but nowhere in code that is
actually used.
The glossary is for git-gui, which has GUI items for "git pull" but not "git
cherry-pick", currently. OTOH gitk has GUI items only for "git cherry-pick"
but not "git pull", currently.
And I think a better translation for "pull" is
something that stresses the fact that "pull" = "fetch" + "merge",
something like "Holen und Zusammenführen".
That's indeed an interesting suggestion. (Which bears the question why it is
being called "pull" in English in the first place, when it should rather be
described by "fetch and merge". Heh.)
quoted
Cherry-picking is a specialized action and should thus get a specialized
German word.
I'm still unsure about this. But it's your choice. ;-)
Yeah. I'm also not completely sure, but for now I'd still prefer "pflücken"
over the other possibilities we've discussed so far.
Regards,
Christian
From: Stephan Beyer <hidden> Date: 2016-06-15 22:44:38
Hi Christian,
quoted
I want to repeat my suggestions from the last mail:
1. "Suche nächste/vorige Version nach _Beschreibung:_ [insert]"
2. "Suche nächste/vorige Version nach _Pfaden:_ [insert]"
(or maybe "nach _Dateien:_", if it's commonly accepted that
directories are files, too.)
3. "Suche nächste/vorige Version nach _Änderungen:_ [insert]"
which makes it much more clearer than the English original, imho.
Okay, I've inserted your suggestions in my translation update. I'm not too
sure about any translation of this part, but your proposal is maybe better
than the existing one.
You can make yourself sure by trying the features or by reading the
source code. ;-)
Since I've translated them in that way, I know what they do and I use them
more often. So I'm pretty sure.
quoted
And I think a better translation for "pull" is
something that stresses the fact that "pull" = "fetch" + "merge",
something like "Holen und Zusammenführen".
That's indeed an interesting suggestion. (Which bears the question why it is
being called "pull" in English in the first place,
Well, this seems not to be clear to some users, since there is often
uncertainty about "pull" ;)
Regards,
Stephan
--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F