Please pull git-po master branch

Please pull git-po master branch

[Jiang Xin]

The following changes since commit 62bc83349d52be49b037d2c800a7f4064cfbc5b5:

  The sixth batch of topics graduated to 'master' (2012-04-27 14:12:56 -0700)

are available in the git repository at:

  https://github.com/git-l10n/git-po/ master

for you to fetch changes up to 839f7f8eed3bbb757dbbb6c2ef1a838974aa4bc8:

  l10n: Update German translation (2012-05-02 07:46:35 +0800)

----------------------------------------------------------------
Byrial Jensen (2):
      l10n: New da.po file with 0 translations
      l10n: Add Danish team (da) to list of teams

Jiang Xin (8):
      Merge master branch for tracking l10n updates of next release
      l10n: Update git.pot (33 new, 24 deleted messages)
      Merge maint branch for tracking l10n updates of git stable version
      l10n: Update git.pot (2 new messages)
      l10n: Update Simplified Chinese translation
      Merge branch 'maint'
      l10n: Update Simplified Chinese translation
      Merge l10n updates from branch 'maint' into master

Marco Sousa (1):
      l10n: Updated pt_PT language

Ralf Thielow (3):
      l10n: Add the German translation team and initialize de.po
      l10n: Initial German translation
      l10n: Update German translation

 po/TEAMS    |    8 +
 po/da.po    | 3503 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 po/de.po    | 3825 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 po/git.pot  |  720 +++++------
 po/pt_PT.po |  242 ++--
 po/zh_CN.po |  783 ++++++------
 6 files changed, 8271 insertions(+), 810 deletions(-)
 create mode 100644 po/da.po
 create mode 100644 po/de.po

Re: Please pull git-po master branch

[Junio C Hamano]

Both branches pulled; I found it somewhat iffy to *add* new language support
on the maintenance track, but decided to let it pass this time.

A new lang.po file is very unlikely to introduce regression to anybody
else, so it probably is OK.

Thanks.

Re: Please pull git-po master branch

[Thomas Rast]

Hi Xin (is that how you are properly addressed?)
Hi Ralf

Jiang Xin <worldhello.net@gmail.com> writes:
> Ralf Thielow (3):
>       l10n: Add the German translation team and initialize de.po
>       l10n: Initial German translation
>       l10n: Update German translation

Junio C Hamano <gitster@pobox.com> writes:
> Both branches pulled; I found it somewhat iffy to *add* new language support
> on the maintenance track, but decided to let it pass this time.
> 
> A new lang.po file is very unlikely to introduce regression to anybody
> else, so it probably is OK.

Objection.

Jan "jast" Krüger and me had most of the following "in the works", and
couldn't get it shaped up before the pull request went out.  Any
translation mistakes are mine, we drafted it in German.

Consider this addressed to Ralf w.r.t. the content, but I think it
constitutes a general argument as to why a new translation should *not*
be merged and immediately released, much less in the maintenance track.


We (Jan and me) looked at your translation while it was WIP at [1].  We
have both toyed with translating Git to German, and got stuck with some
pitfalls.

To put it bluntly, we have significant concerns with your translation so
far.  That's usually not a problem in OSS -- release early and release
and release often -- but the maint release would require you to get it
Right(tm) the first time.

The basic issues correlate with those found in many translations of
non-professionals.  (We wrote the list while looking at the WIP version
5c98748a2.  I have briefly checked that the points mentioned here are
still in the released version, but may have missed many other changes.)

* One tends to stick too closely to the English text, frequently missing
  an opportunity to completely restructure sentences.  In some cases the
  translation may be outright wrong, even though the words are correctly
  translated.

  Example, if a bit harmless:
    Original: "If you are sure you want to delete it, [...]"
    Your translation: "Wenn du sicher bist diesen Zweig zu entfernen, [...]"
    Alternative: "Wenn du ihn wirklich entfernen willst, [...]"

* Frequently there is an ambiguity, or overloading of terms, in one or
  both languages.  The context (of the original message) will make clear
  *for the translator* what the meaning is, but it may be lost on the
  user.

  A related issue is when a single word splits into several in German.

  Examples:

  "commit" -> "Eintrag/Version/eintragen"
  "committer" -> "Einreicher/Eintragender"
  "remote" -> "entfernt" (weg? Aber ich hab's doch gar nicht gelöscht...?)
  "tracked/untracked" -> "verfolgt/unverfolgt" (Paranoia? "Unverfolgt" ist
      zudem nicht unbedingt ein Wort aus dem Sprachgebrauch)

* Translating technical terms may turn them into something that is
  completely unknown to anybody in German.

  Examples:

  "commit" -> usually translated simply as "Commit", e.g. in the SVN Red
              Book

  "staging area/index/stage" -> "Bereitstellung/bereitstellen" is
      correct (e.g. in military usage), but gives the user little
      intuition.  "Index" isn't good either (same issue as in the
      original).  We don't have a really good idea either, and haven't
      heard of one.  However, this is one of the most important
      translations: the index is very central to git, but few users know
      it already.  You can try finding a good term (perhaps taking some
      liberties) but otherwise "Index" may be the lesser evil.

      On a related note, an earlier unfinished translation translated
      "to stage" as "vormerken".  We think that captures the essence
      very nicely.  It then tried to completely avoid referring to the
      index as a noun.

* The translator may not be sufficiently familiar with the context
  and the tool to correctly translate.

  Example:
  Original: Cloning into bare repository '%s'...
  Translation: Klone in leeres Projektarchiv '%s'...
  [for non German speakers: "leer" means "empty"]
  "bare" denotes a repository that does not have a worktree associated
  with it.  It is *not* usually empty.


Please don't take this personal.  We are happy that you picked up the
effort of translating it, since all previous efforts have stalled.
It's also a bit too late now for the German translation, since it has
already been released.

However, we do feel that git is so complex and has so much confusing
(not your fault really) terminology associated with it that translations
should not go straight from translator to release.

Some ideas on how we can do better in the next language, and proceed
from here:

* Make a glossary of the relevant terminology first.  Sadly
  gitglossary(7) has gotten somewhat stale, and perhaps can also benefit
  from an overhaul.  Ævar Arnfjörð Bjarmason recently made a list[4] of
  the most important terms, which is a good start.

* If you are interested in collaboration, IRC may be a good choice for
  the many little questions that probably arise?  We hang out in
  #git-devel on Freenode[3].  Email is of course also an option, but
  more time-consuming.

Note that in the context of Git, a major problem is that the
documentation and books are only available in English.  There isn't even
a glossary.  For example, you translated "detached" as "losgelöst".
From our experience the detached HEAD is something that users stumble
into, rather than learn about beforehand.  They usually come crying for
help when they've already lost their work in the "void" of unreachable
commits.  Now put yourself into the position of a user.  Where can he
look up what the root of his problem is?  At least for "detached HEAD"
there is a wealth of blog posts that rescue the poor user.

We think -- pardon the strong words -- that your current draft
translation makes things harder, not easier, for German users.  The
issues mentioned above, especially when it comes to ambiguities, splits
into several terms and mistakes, add up to considerable bad weather, and
the lack of reference material leaves the user out in the rain.

Of course now that it has been released, we'll also have to file patches
in the true open source spirit.  Sigh.

Regards / Liebe Grüsse
Thomas

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

Re: Please pull git-po master branch

[Ralf Thielow]

Well, basically I've tried to unify the translation with the git-gui one.
So i took over some of the translations from them (e.g. "commit").

>  A related issue is when a single word splits into several in German.
>
>  Examples:
>
>  "commit" -> "Eintrag/Version/eintragen"

I think we have to make a difference between "commit" as a noun and
"commit" as a verb here.

>
>  "commit" -> usually translated simply as "Commit", e.g. in the SVN Red
>              Book
>

As I said I've tried to unify with the git-gui translation. Actually, I was
wondered why they translate terms like "Tag" or "Commit" because
I think they should be known by a Git user.
I know German books about Git using many other terms like
"Staging" or "Index" as it is.

> * Make a glossary of the relevant terminology first.  Sadly
>  gitglossary(7) has gotten somewhat stale, and perhaps can also benefit
>  from an overhaul.  Ævar Arnfjörð Bjarmason recently made a list[4] of
>  the most important terms, which is a good start.
>
> * If you are interested in collaboration, IRC may be a good choice for
>  the many little questions that probably arise?  We hang out in
>  #git-devel on Freenode[3].  Email is of course also an option, but
>  more time-consuming.

I would be happy to work together with you on these things.
Tiny changes in the translation of basic terms can make
a big difference.

> Note that in the context of Git, a major problem is that the
> documentation and books are only available in English.  There isn't even
> a glossary.  For example, you translated "detached" as "losgelöst".
> From our experience the detached HEAD is something that users stumble
> into, rather than learn about beforehand.  They usually come crying for
> help when they've already lost their work in the "void" of unreachable
> commits.  Now put yourself into the position of a user.  Where can he
> look up what the root of his problem is?  At least for "detached HEAD"
> there is a wealth of blog posts that rescue the poor user.

That's a basic problem when messages are translated.

> We think -- pardon the strong words -- that your current draft
> translation makes things harder, not easier, for German users.  The
> issues mentioned above, especially when it comes to ambiguities, splits
> into several terms and mistakes, add up to considerable bad weather, and
> the lack of reference material leaves the user out in the rain.
>
> Of course now that it has been released, we'll also have to file patches
> in the true open source spirit.  Sigh.

I don't think that it's sooo bad that it needs to get reverted.
In the end it's an initial version. I'll join the IRC channel to
work with you (and others) together to make the translation
better.

Thanks

Re: Please pull git-po master branch

[Thomas Rast]

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

> As I said I've tried to unify with the git-gui translation. Actually, I was
> wondered why they translate terms like "Tag" or "Commit" because
> I think they should be known by a Git user.
> 
> I know German books about Git using many other terms like
> "Staging" or "Index" as it is.

Well, this is getting into the eternal "German vs. Denglish"
bikeshedding war.  If you can actually cite books, that would probably
constitute a good argument in favour of changing it to the English terms
for these.  (I'd be all for it, and AFAIK so would Jan, but as I said
this has been going on for a while.)

>> * Make a glossary of the relevant terminology first.  Sadly
>>  gitglossary(7) has gotten somewhat stale, and perhaps can also benefit
>>  from an overhaul.  Ævar Arnfjörð Bjarmason recently made a list[4] of
>>  the most important terms, which is a good start.
>
> I would be happy to work together with you on these things.
> Tiny changes in the translation of basic terms can make
> a big difference.

Perhaps you could use the Github wiki feature to import Ævar's list into
a wiki in your git-de-po repository, which we could then edit?

> I don't think that it's sooo bad that it needs to get reverted.

Probably not, since that would be pointless without another minor
release.  But I am saying it should not have been fast-tracked to maint
in the first place.

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

Re: Please pull git-po master branch

[Ralf Thielow]

> Perhaps you could use the Github wiki feature to import Ævar's list into
> a wiki in your git-de-po repository, which we could then edit?

I just created a wiki page on github contains a glossary based on Ævar's list.

https://github.com/ralfth/git-po-de/wiki/Glossary

Re: Please pull git-po master branch

[Christian Stimming]

Am Mittwoch, 2. Mai 2012, 21:14:05 schrieb Ralf Thielow:
> > Perhaps you could use the Github wiki feature to import Ævar's list into
> > a wiki in your git-de-po repository, which we could then edit?
> 
> I just created a wiki page on github contains a glossary based on Ævar's
> list.
> 
> https://github.com/ralfth/git-po-de/wiki/Glossary

I hope you noticed the content of the directory git-gui/po/glossary/, didn't 
you? On the other hand I see you copied most of the de.po terms into the wiki 
page already. Thanks!

Regards,

Christian

[PATCH 0/5] de.po suggested updates

[Thomas Rast]

I wrote:
> Of course now that it has been released, we'll also have to file patches
> in the true open source spirit.  Sigh.

So here goes.

[1/5] is actually intended for Junio to pick up, and makes a message
      translatable that somehow got away last time.

The rest are for Ralf.

[2/5] does away with the "bare"->"leer" issue that I used as an
      example earlier.  There's precedent in git-gui :-( This does
      raise the question if it's kosher to patch both git and git-gui
      at the same time, but if we want to keep the translations in
      sync it probably won't be the last such patch.

[3/5] collects all the "obvious" stuff

[4/5] and [5/5] gather the less-obvious stuff -- keep what you like.

Cheers,
Thomas

Thomas Rast (5):
  stash: make "saved" message translatable
  de.po: translate "bare" as "bloß"
  de.po: hopefully uncontroversial fixes
  de.po: translate "bad" as "ungültig" ("invalid")
  de.po: collection of suggestions

 git-gui/po/de.po |    4 +-
 git-stash.sh     |    2 +-
 po/de.po         |  153 +++++++++++++++++++++++++-----------------------------
 3 files changed, 74 insertions(+), 85 deletions(-)

-- 
1.7.10.625.g300dcf

[PATCH 1/5] stash: make "saved" message translatable

[Thomas Rast]

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 git-stash.sh |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-stash.sh b/git-stash.sh
index 4e2c7f8..e614eb7 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -233,7 +233,7 @@ save_stash () {
 
 	git update-ref -m "$stash_msg" $ref_stash $w_commit ||
 		die "$(gettext "Cannot save the current status")"
-	say Saved working directory and index state "$stash_msg"
+	say "$(eval_gettext "Saved working directory and index state \"\$stash_msg\"")"
 
 	if test -z "$patch_mode"
 	then
-- 
1.7.10.625.g300dcf

Re: [PATCH 1/5] stash: make "saved" message translatable

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>  git-stash.sh |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-stash.sh b/git-stash.sh
> index 4e2c7f8..e614eb7 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -233,7 +233,7 @@ save_stash () {
>  
>  	git update-ref -m "$stash_msg" $ref_stash $w_commit ||
>  		die "$(gettext "Cannot save the current status")"
> -	say Saved working directory and index state "$stash_msg"
> +	say "$(eval_gettext "Saved working directory and index state \"\$stash_msg\"")"

Do you need backslashes before double quotes here?

[PATCH de.po 2/5] de.po: translate "bare" as "bloß"

[Thomas Rast]

git-gui has had precedent for "leer" since ab2d3b0 (git-gui: Update
German translation (12 new or changed strings)., 2010-01-26).
However, that would be "empty".

Change it both in git-gui and git itself.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 git-gui/po/de.po |    4 ++--
 po/de.po         |    6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/git-gui/po/de.po b/git-gui/po/de.po
index 44c5ddc..9458f6e 100644
--- a/git-gui/po/de.po
+++ b/git-gui/po/de.po
@@ -8,7 +8,7 @@ msgstr ""
 "Project-Id-Version: git-gui\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2010-01-26 22:22+0100\n"
-"PO-Revision-Date: 2010-01-26 22:25+0100\n"
+"PO-Revision-Date: 2012-05-02 11:54+0200\n"
 "Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
 "Language-Team: German\n"
 "MIME-Version: 1.0\n"
@@ -72,7 +72,7 @@ msgstr ""
 
 #: git-gui.sh:1154
 msgid "Cannot use bare repository:"
-msgstr "Leeres Projektarchiv kann nicht benutzt werden:"
+msgstr "Bloßes Projektarchiv kann nicht benutzt werden:"
 
 #: git-gui.sh:1162
 msgid "No working directory"
diff --git a/po/de.po b/po/de.po
index a43f646..a7a39ed 100644
--- a/po/de.po
+++ b/po/de.po
@@ -8,7 +8,7 @@ msgstr ""
 "Project-Id-Version: git 1.7.10\n"
 "Report-Msgid-Bugs-To: Git Mailing List <git@vger.kernel.org>\n"
 "POT-Creation-Date: 2012-04-28 20:17+0800\n"
-"PO-Revision-Date: 2012-03-28 18:46+0200\n"
+"PO-Revision-Date: 2012-05-02 15:10+0200\n"
 "Last-Translator: Ralf Thielow <ralf.thielow@googlemail.com>\n"
 "Language-Team: German\n"
 "Language: de\n"
@@ -1376,7 +1376,7 @@ msgstr "Konnte Arbeitsverzeichnis '%s' nicht erstellen."
 #: builtin/clone.c:728
 #, c-format
 msgid "Cloning into bare repository '%s'...\n"
-msgstr "Klone in leeres Projektarchiv '%s'...\n"
+msgstr "Klone in bloßes Projektarchiv '%s'...\n"
 
 #: builtin/clone.c:730
 #, c-format
@@ -3133,7 +3133,7 @@ msgstr "Kann keine %s Zurücksetzung mit Pfaden machen."
 #: builtin/reset.c:325
 #, c-format
 msgid "%s reset is not allowed in a bare repository"
-msgstr "%s Zurücksetzung ist in einem leeren Projektarchiv nicht erlaubt"
+msgstr "'%s' Zurücksetzung ist in einem bloßen Projektarchiv nicht erlaubt"
 
 #: builtin/reset.c:341
 #, c-format
-- 
1.7.10.625.g300dcf

[PATCH de.po 3/5] de.po: hopefully uncontroversial fixes

[Thomas Rast]

These are all obviously wrong, such as typos or messages where the
current translation is based on a misunderstanding of the original
message.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 po/de.po |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/po/de.po b/po/de.po
index a7a39ed..d391632 100644
--- a/po/de.po
+++ b/po/de.po
@@ -145,7 +145,7 @@ msgstr "'%s': %s"
 #: grep.c:1308
 #, c-format
 msgid "'%s': short read %s"
-msgstr "'%s': kurz gelesen %s"
+msgstr "'%s': read() zu kurz %s"
 
 #: help.c:287
 #, c-format
@@ -779,7 +779,7 @@ msgstr "Nichts spezifiziert, nichts hinzugefügt.\n"
 #: builtin/add.c:414
 #, c-format
 msgid "Maybe you wanted to say 'git add .'?\n"
-msgstr "Wolltest du vieleicht 'git add .' sagen?\n"
+msgstr "Wolltest du vielleicht 'git add .' sagen?\n"
 
 #: builtin/add.c:420 builtin/clean.c:95 builtin/commit.c:358 builtin/mv.c:82
 #: builtin/rm.c:162
@@ -815,7 +815,7 @@ msgstr "git archive: NACK %s"
 #: builtin/archive.c:65
 #, c-format
 msgid "remote error: %s"
-msgstr "Versandfehler: %s"
+msgstr "Fehler am anderen Ende: %s"
 
 #: builtin/archive.c:66
 msgid "git archive: protocol error"
@@ -2234,11 +2234,11 @@ msgstr "Initialisierte leeres"
 
 #: builtin/init-db.c:421
 msgid " shared"
-msgstr " geteilt"
+msgstr " geteiltes"
 
 #: builtin/init-db.c:440
 msgid "cannot tell cwd"
-msgstr "kann nicht \"cwd\" sagen"
+msgstr "kann aktuelles Verzeichnis nicht bestimmen"
 
 #: builtin/init-db.c:521 builtin/init-db.c:528
 #, c-format
@@ -2978,7 +2978,7 @@ msgstr ""
 "Zweiges hinter seinem entfernten Gegenstück ist. Wenn du nicht beabsichtigt\n"
 "hast, diesen Zweig zu versenden, kannst du auch den zu versendenden Zweig\n"
 "spezifizieren oder die Konfigurationsvariable 'push.default' zu 'current'\n"
-"oder 'upstream' setze, um nur den aktuellen Zweig zu versenden."
+"oder 'upstream' setzen, um nur den aktuellen Zweig zu versenden."
 
 #: builtin/push.c:150
 msgid ""
@@ -3057,7 +3057,7 @@ msgstr "--delete ist inkompatibel mit --all, --mirror und --tags"
 
 #: builtin/push.c:344
 msgid "--delete doesn't make sense without any refs"
-msgstr "--delete macht ohne irgendeine Referenz ohne keinen Sinn"
+msgstr "--delete macht ohne irgendeine Referenz keinen Sinn"
 
 #: builtin/reset.c:33
 msgid "mixed"
@@ -3283,7 +3283,7 @@ msgstr "Die Markierungsbeschreibung wurde gelassen in %s\n"
 
 #: builtin/tag.c:421
 msgid "switch 'points-at' requires an object"
-msgstr "Wechseln von 'points-at' erfordert ein Objekt"
+msgstr "Option 'points-at' erfordert ein Objekt"
 
 #: builtin/tag.c:423
 #, c-format
@@ -3437,7 +3437,7 @@ msgstr "nicht erkannte Option: '$arg'"
 #: git-bisect.sh:99
 #, sh-format
 msgid "'$arg' does not appear to be a valid revision"
-msgstr "'$arg' scheint keine gültige Option zu sein"
+msgstr "'$arg' scheint keine gültige Version zu sein"
 
 #: git-bisect.sh:117
 msgid "Bad HEAD - I need a HEAD"
@@ -3471,7 +3471,7 @@ msgstr "Schlechte Referenz-Eingabe: $arg"
 
 #: git-bisect.sh:232
 msgid "Please call 'bisect_state' with at least one argument."
-msgstr "Bitte rufe 'bisect_state' mit mindestens einem Argument."
+msgstr "Bitte rufe 'bisect_state' mit mindestens einem Argument auf."
 
 #: git-bisect.sh:244
 #, sh-format
@@ -3610,7 +3610,7 @@ msgstr "$reference ist keine gültige Referenz"
 #: git-stash.sh:393
 #, sh-format
 msgid "'$args' is not a stash-like commit"
-msgstr "'$args' ist keine \"stash\"-artiger Version"
+msgstr "'$args' ist keine \"stash\"-artige Version"
 
 #: git-stash.sh:404
 #, sh-format
@@ -3809,7 +3809,7 @@ msgstr "  Warnung: $name beinhaltet nicht Version $sha1_dst"
 #: git-submodule.sh:776
 #, sh-format
 msgid "  Warn: $name doesn't contain commits $sha1_src and $sha1_dst"
-msgstr "  Warnung: $name beinhaltet nich die Versionen $sha1_src und $sha1_dst"
+msgstr "  Warnung: $name beinhaltet nicht die Versionen $sha1_src und $sha1_dst"
 
 #: git-submodule.sh:801
 msgid "blob"
-- 
1.7.10.625.g300dcf

[PATCH de.po 4/5] de.po: translate "bad" as "ungültig" ("invalid")

[Thomas Rast]

"schlecht" doesn't quite sound right to me, especially in messages
like "bad object" where the object doesn't even exist in the first
place.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 po/de.po |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/po/de.po b/po/de.po
index d391632..a1a765a 100644
--- a/po/de.po
+++ b/po/de.po
@@ -2101,7 +2101,7 @@ msgstr "keine Muster gegeben"
 #: builtin/grep.c:902
 #, c-format
 msgid "bad object %s"
-msgstr "schlechtes Objekt %s"
+msgstr "ungültiges Objekt %s"
 
 #: builtin/grep.c:943
 msgid "--open-files-in-pager only works on the worktree"
@@ -2444,7 +2444,7 @@ msgstr "'%s' zeigt auf keine Version"
 #: builtin/merge.c:536
 #, c-format
 msgid "Bad branch.%s.mergeoptions string: %s"
-msgstr "Schlechter branch.%s.mergeoptions String: %s"
+msgstr "Ungültiger branch.%s.mergeoptions String: %s"
 
 #: builtin/merge.c:629
 msgid "git write-tree failed to write a tree"
@@ -2659,7 +2659,7 @@ msgstr "Prüfe Umbenennen von '%s' nach '%s'\n"
 
 #: builtin/mv.c:112
 msgid "bad source"
-msgstr "schlechte Quelle"
+msgstr "ungültige Quelle"
 
 #: builtin/mv.c:115
 msgid "can not move directory into itself"
@@ -2786,7 +2786,7 @@ msgstr "Kann uninitialisierten/unreferenzierten Notiz-Baum nicht eintragen."
 #: builtin/notes.c:340
 #, c-format
 msgid "Bad notes.rewriteMode value: '%s'"
-msgstr "Schlechter notes.rewriteMode Wert: '%s'"
+msgstr "Ungültiger notes.rewriteMode Wert: '%s'"
 
 #: builtin/notes.c:350
 #, c-format
@@ -2799,7 +2799,7 @@ msgstr ""
 #: builtin/notes.c:377
 #, c-format
 msgid "Bad %s value: '%s'"
-msgstr "Schlechter %s Wert: '%s'"
+msgstr "Ungültiger %s Wert: '%s'"
 
 #: builtin/notes.c:441
 #, c-format
@@ -2881,7 +2881,7 @@ msgstr "Nicht unterstützte Bereitstellungsversion %s"
 #: builtin/pack-objects.c:2314
 #, c-format
 msgid "bad index version '%s'"
-msgstr "Schlechte Bereitstellungsversion '%s'"
+msgstr "Ungültige Bereitstellungsversion '%s'"
 
 #: builtin/pack-objects.c:2322
 #, c-format
@@ -3007,7 +3007,7 @@ msgstr "Fehler beim Versenden einiger Referenzen nach '%s'"
 #: builtin/push.c:226
 #, c-format
 msgid "bad repository '%s'"
-msgstr "schlechtes Projektarchiv '%s'"
+msgstr "ungültiges Projektarchiv '%s'"
 
 #: builtin/push.c:227
 msgid ""
@@ -3266,7 +3266,7 @@ msgstr "konnte Markierungsdatei nicht schreiben"
 
 #: builtin/tag.c:321
 msgid "bad object type."
-msgstr "schlechter Objekt-Typ"
+msgstr "ungültiger Objekt-Typ"
 
 #: builtin/tag.c:334
 msgid "tag header too big."
@@ -3441,7 +3441,7 @@ msgstr "'$arg' scheint keine gültige Version zu sein"
 
 #: git-bisect.sh:117
 msgid "Bad HEAD - I need a HEAD"
-msgstr "Schlechte Zweigspitze (HEAD) - Ich brauche eine Zweigspitze (HEAD)"
+msgstr "Ungültige Zweigspitze (HEAD) - Ich brauche eine Zweigspitze (HEAD)"
 
 #: git-bisect.sh:130
 #, sh-format
@@ -3457,17 +3457,17 @@ msgstr "werde nicht auf gesuchtem Baum halbieren"
 
 #: git-bisect.sh:144
 msgid "Bad HEAD - strange symbolic ref"
-msgstr "Schlechte Zweigspitze (HEAD) - merkwürdige symbolische Referenz"
+msgstr "Ungültige Zweigspitze (HEAD) - merkwürdige symbolische Referenz"
 
 #: git-bisect.sh:189
 #, sh-format
 msgid "Bad bisect_write argument: $state"
-msgstr "Schlechtes \"bisect_write\" Argument: $state"
+msgstr "Ungültiges \"bisect_write\" Argument: $state"
 
 #: git-bisect.sh:218
 #, sh-format
 msgid "Bad rev input: $arg"
-msgstr "Schlechte Referenz-Eingabe: $arg"
+msgstr "Ungültige Referenz-Eingabe: $arg"
 
 #: git-bisect.sh:232
 msgid "Please call 'bisect_state' with at least one argument."
@@ -3476,7 +3476,7 @@ msgstr "Bitte rufe 'bisect_state' mit mindestens einem Argument auf."
 #: git-bisect.sh:244
 #, sh-format
 msgid "Bad rev input: $rev"
-msgstr "Schlechte Referenz-Eingabe: $rev"
+msgstr "Ungültige Referenz-Eingabe: $rev"
 
 #: git-bisect.sh:250
 msgid "'git bisect bad' can take only one argument."
-- 
1.7.10.625.g300dcf

[PATCH de.po 5/5] de.po: collection of suggestions

[Thomas Rast]

A long list of suggested changes to the translation.  None of them are
clear-cut, though I of course think they are an improvement ;-)

Please do not apply this patch "blindly"; take them as suggestions,
and keep only the ones you like.  The S-O-B refers to the
opensourciness of it.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 po/de.po |   97 ++++++++++++++++++++++++++++----------------------------------
 1 file changed, 43 insertions(+), 54 deletions(-)

diff --git a/po/de.po b/po/de.po
index a1a765a..f6df558 100644
--- a/po/de.po
+++ b/po/de.po
@@ -34,8 +34,8 @@ msgid ""
 "or use 'git commit -a'."
 msgstr ""
 "Korrigiere dies im Arbeitsbaum,\n"
-"und benutze dann 'git add/rm <Datei>' wie\n"
-"vorgesehen, um die Auflösung zu markieren und dann einzutragen,\n"
+"und benutze dann 'git add/rm <Datei>' \n"
+"um die Auflösung entsprechend zu markieren und einzutragen,\n"
 "oder benutze 'git commit -a'."
 
 #: commit.c:48
@@ -360,7 +360,7 @@ msgstr "Fehlerhaftes Optionsblatt: %s"
 
 #: sequencer.c:666
 msgid "a cherry-pick or revert is already in progress"
-msgstr "\"cherry-pick\" oder \"revert\" wird bereits ausgeführt"
+msgstr "\"cherry-pick\" oder \"revert\" ist bereits im Gang"
 
 #: sequencer.c:667
 msgid "try \"git cherry-pick (--continue | --quit | --abort)\""
@@ -378,7 +378,7 @@ msgstr "Fehler beim Einpacken von %s."
 
 #: sequencer.c:706 sequencer.c:840
 msgid "no cherry-pick or revert in progress"
-msgstr "kein \"cherry-pick\" oder \"revert\" in Ausführung"
+msgstr "kein \"cherry-pick\" oder \"revert\" im Gang"
 
 #: sequencer.c:708
 msgid "cannot resolve HEAD"
@@ -386,7 +386,7 @@ msgstr "kann Zweigspitze (HEAD) nicht auflösen"
 
 #: sequencer.c:710
 msgid "cannot abort from a branch yet to be born"
-msgstr "kann nicht von einem Zweig abbrechen, der noch geboren wird"
+msgstr "kann nicht abbrechen: bin auf einem Zweig, der noch geboren wird"
 
 #: sequencer.c:732
 #, c-format
@@ -475,12 +475,11 @@ msgstr "Änderungen, die nicht zum Eintragen bereitgestellt sind:"
 
 #: wt-status.c:173
 msgid "  (use \"git add <file>...\" to update what will be committed)"
-msgstr "  (benutze \"git add <Datei>...\" zur Aktualisierung der Eintragung)"
+msgstr "  (benutze \"git add <Datei>...\" zum Bereitstellen)"
 
 #: wt-status.c:175
 msgid "  (use \"git add/rm <file>...\" to update what will be committed)"
-msgstr ""
-"  (benutze \"git add/rm <Datei>...\" zur Aktualisierung der Eintragung)"
+msgstr "  (benutze \"git add/rm <Datei>...\" zum Bereitstellen)"
 
 #: wt-status.c:176
 msgid ""
@@ -507,7 +506,7 @@ msgstr "  (benutze \"git %s <Datei>...\" zum Einfügen in die Eintragung)"
 
 #: wt-status.c:207
 msgid "bug"
-msgstr "Fehler"
+msgstr "Bug"
 
 #: wt-status.c:212
 msgid "both deleted:"
@@ -676,11 +675,11 @@ msgstr "hinter "
 
 #: wt-status.c:908 wt-status.c:911
 msgid "ahead "
-msgstr "über "
+msgstr "weiter: "
 
 #: wt-status.c:913
 msgid ", behind "
-msgstr ", hinter "
+msgstr ", zurückgefallen "
 
 #: builtin/add.c:62
 #, c-format
@@ -903,12 +902,12 @@ msgstr "Zweig '%s' zeigt auf keine Version"
 #: builtin/branch.c:396
 #, c-format
 msgid "behind %d] "
-msgstr "hinter %d] "
+msgstr "%d hinterher] "
 
 #: builtin/branch.c:398
 #, c-format
 msgid "ahead %d] "
-msgstr "vor %d] "
+msgstr "%d voraus] "
 
 #: builtin/branch.c:400
 #, c-format
@@ -1570,9 +1569,8 @@ msgid ""
 " Lines starting\n"
 "with '#' will be ignored, and an empty message aborts the commit.\n"
 msgstr ""
-" Zeilen beginnend\n"
-"mit '#' werden ignoriert, und eine leere Versionsbeschreibung bricht die "
-"Eintragung ab.\n"
+" Zeilen, die mit '#'\n"
+"beginnen, werden ignoriert, und eine leere Versionsbeschreibung bricht die Eintragung ab.\n"
 
 #: builtin/commit.c:820
 msgid ""
@@ -1580,8 +1578,8 @@ msgid ""
 "with '#' will be kept; you may remove them yourself if you want to.\n"
 "An empty message aborts the commit.\n"
 msgstr ""
-" Zeilen beginnend\n"
-"mit '#' werden beibehalten; wenn du möchtest, kannst du diese entfernen.\n"
+" Zeilen, die mit '#'\n"
+"beginnen, werden beibehalten; wenn du möchtest, kannst du diese entfernen.\n"
 "Eine leere Versionsbeschreibung bricht die Eintragung ab.\n"
 
 #: builtin/commit.c:832
@@ -1762,7 +1760,7 @@ msgstr "annotierte Markierung %s hat keinen eingebetteten Namen"
 #: builtin/describe.c:240
 #, c-format
 msgid "tag '%s' is really '%s' here"
-msgstr "Markierung '%s' ist wirklich '%s' hier"
+msgstr "Markierung '%s' ist eigentlich '%s' hier"
 
 #: builtin/describe.c:267
 #, c-format
@@ -1831,7 +1829,7 @@ msgstr "Keine Namen gefunden, kann nichts beschreiben."
 
 #: builtin/describe.c:482
 msgid "--dirty is incompatible with committishes"
-msgstr "--dirty ist inkompatibel mit \"committish\"-Werten"
+msgstr "--dirty ist inkompatibel mit Versionen"
 
 #: builtin/diff.c:77
 #, c-format
@@ -2001,8 +1999,8 @@ msgid ""
 "remote name from which new revisions should be fetched."
 msgstr ""
 "Kein entferntes Projektarchiv spezifiziert. Bitte spezifiziere entweder\n"
-"eine URL oder einen Entfernungsname, von welchem neue Revisionen angefordert "
-"werden sollen."
+"eine URL oder den Namen eines entfernten Archivs, von welchem neue\n"
+"Revisionen angefordert werden sollen."
 
 #: builtin/fetch.c:927
 msgid "You need to specify a tag name."
@@ -2034,7 +2032,7 @@ msgstr "Ungültiger %s: '%s'"
 
 #: builtin/gc.c:78
 msgid "Too many options specified"
-msgstr "Zu viele Optionen spezifiziert"
+msgstr "Zu viele Optionen angegeben"
 
 #: builtin/gc.c:103
 #, c-format
@@ -2044,7 +2042,7 @@ msgstr "wahnsinnig langes Objekt-Verzeichnis %.*s"
 #: builtin/gc.c:223
 #, c-format
 msgid "Auto packing the repository for optimum performance.\n"
-msgstr "Automatische Paketierung des Repositories für optimale Leitung.\n"
+msgstr "Automatisches packen des Projektarchivs für optimale Leistung.\n"
 
 #: builtin/gc.c:226
 #, c-format
@@ -2052,17 +2050,13 @@ msgid ""
 "Auto packing the repository for optimum performance. You may also\n"
 "run \"git gc\" manually. See \"git help gc\" for more information.\n"
 msgstr ""
-"Automatische Paketierung des Repositories für optimale Leitung. Du darfst "
-"auch\n"
-"\"git gc\" manuell ausführen. Siehe \"git help gc\" für weitere "
-"Informationen.\n"
+"Automatisches packen des Projektarchivs für optimale Leistung. Du kannst auch\n"
+"\"git gc\" manuell ausführen. Siehe \"git help gc\" für weitere Informationen.\n"
 
 #: builtin/gc.c:256
 msgid ""
 "There are too many unreachable loose objects; run 'git prune' to remove them."
-msgstr ""
-"Es gibt zu viele unerreichbare, verlorene Objekte; führe 'git prune' aus um "
-"diese zu entfernen."
+msgstr "Es gibt zu viele unerreichbare lose Objekte; führe 'git prune' aus um diese zu entfernen."
 
 #: builtin/grep.c:216
 #, c-format
@@ -2328,11 +2322,11 @@ msgstr "unechte Einreicher-Informationen %s"
 
 #: builtin/log.c:1224
 msgid "-n and -k are mutually exclusive."
-msgstr "-n und -k sind zueinander exklusiv"
+msgstr "-n und -k schliessen sich gegenseitig aus"
 
 #: builtin/log.c:1226
 msgid "--subject-prefix and -k are mutually exclusive."
-msgstr "--subject-prefix und -k sind zueinander exklusiv"
+msgstr "--subject-prefix und -k schliessen sich gegenseitig aus"
 
 #: builtin/log.c:1231 builtin/shortlog.c:284
 #, c-format
@@ -2594,12 +2588,11 @@ msgstr "Kann nur exakt eine Version in einem leeren Kopf zusammenführen."
 
 #: builtin/merge.c:1296
 msgid "Squash commit into empty head not supported yet"
-msgstr ""
-"Quetschen einer Version in einen leeren Kopf wird momentan nicht unterstützt."
+msgstr "Bin auf einem Zweig, der noch geboren wird; kann nicht quetschen."
 
 #: builtin/merge.c:1298
 msgid "Non-fast-forward commit does not make sense into an empty head"
-msgstr "nicht vorzuspulende Version macht in einem leeren Kopf keinen Sinn"
+msgstr "Bin auf einem Zweig, der noch geboren wird; --no-ff macht keinen Sinn."
 
 #: builtin/merge.c:1413
 #, c-format
@@ -2997,7 +2990,7 @@ msgstr ""
 #: builtin/push.c:190
 #, c-format
 msgid "Pushing to %s\n"
-msgstr "Schiebe zu %s\n"
+msgstr "Versende nach %s\n"
 
 #: builtin/push.c:194
 #, c-format
@@ -3061,19 +3054,19 @@ msgstr "--delete macht ohne irgendeine Referenz keinen Sinn"
 
 #: builtin/reset.c:33
 msgid "mixed"
-msgstr "gemischt"
+msgstr "mixed"
 
 #: builtin/reset.c:33
 msgid "soft"
-msgstr "weich"
+msgstr "soft"
 
 #: builtin/reset.c:33
 msgid "hard"
-msgstr "hart"
+msgstr "hard"
 
 #: builtin/reset.c:33
 msgid "keep"
-msgstr "halten"
+msgstr "keep"
 
 #: builtin/reset.c:77
 msgid "You do not have a valid HEAD."
@@ -3108,8 +3101,7 @@ msgstr "Nicht bereitgestellte Änderungen nach Zurücksetzung:"
 #: builtin/reset.c:223
 #, c-format
 msgid "Cannot do a %s reset in the middle of a merge."
-msgstr ""
-"Kann keine %s Zurücksetzung innerhalb einer Zusammenführung durchführen."
+msgstr "Kann keine '%s' Zurücksetzung innerhalb einer Zusammenführung durchführen."
 
 #: builtin/reset.c:297
 #, c-format
@@ -3128,7 +3120,7 @@ msgstr ""
 #: builtin/reset.c:313
 #, c-format
 msgid "Cannot do %s reset with paths."
-msgstr "Kann keine %s Zurücksetzung mit Pfaden machen."
+msgstr "Kann keine '%s' Zurücksetzung mit Pfaden machen."
 
 #: builtin/reset.c:325
 #, c-format
@@ -3237,7 +3229,7 @@ msgstr ""
 "\n"
 "#\n"
 "# Gebe eine Markierungsbeschreibung ein\n"
-"# Zeilen beginnend mit '#' werden ignoriert.\n"
+"# Zeilen, die mit '#' beginnen, werden ignoriert.\n"
 "#\n"
 
 #: builtin/tag.c:254
@@ -3252,8 +3244,8 @@ msgstr ""
 "\n"
 "#\n"
 "# Gebe eine Markierungsbeschreibung ein\n"
-"# Zeilen beginnend mit '#' werden behalten; du darfst diese selbst entfernen "
-"wenn du möchtest.\n"
+"# Zeilen, die mit '#' beginnen, werden behalten; du darfst diese\n"
+"# selbst entfernen wenn du möchtest.\n"
 "#\n"
 
 #: builtin/tag.c:294
@@ -3351,8 +3343,7 @@ msgid ""
 "It does not apply to blobs recorded in its index."
 msgstr ""
 "Hast du den Patch per Hand editiert?\n"
-"Er kann nicht auf aufgezeichnete Blobs in seiner Bereitstellung angewendet "
-"werden."
+"Er kann nicht auf die Blobs in seiner 'index' Zeile angewendet werden."
 
 #: git-am.sh:163
 msgid "Falling back to patching base and 3-way merge..."
@@ -3398,9 +3389,7 @@ msgstr ""
 
 #: git-am.sh:755
 msgid "cannot be interactive without stdin connected to a terminal."
-msgstr ""
-"Kann nicht interaktiv sein, ohne das die Standard-Eingabe mit einem Terminal "
-"verbunden ist."
+msgstr "Kann nicht interaktiv sein, ohne dass die Standard-Eingabe mit einem Terminal verbunden ist."
 
 #. TRANSLATORS: Make sure to include [y], [n], [e], [v] and [a]
 #. in your translation. The program will only accept English
@@ -3500,7 +3489,7 @@ msgid ""
 "Could not check out original HEAD '$branch'.\n"
 "Try 'git bisect reset <commit>'."
 msgstr ""
-"Konnte die originale Zweigspitze (HEAD) '$branch' nicht auschecken.\n"
+"Konnte die ursprüngliche Zweigspitze (HEAD) '$branch' nicht auschecken.\n"
 "Versuche 'git bisect reset <Version>'."
 
 #: git-bisect.sh:390
@@ -3543,7 +3532,7 @@ msgstr ""
 
 #: git-pull.sh:253
 msgid "Cannot merge multiple branches into empty head"
-msgstr "Kann nicht mehrere Zweige in einen leeren Kopf zusammenführen"
+msgstr "Kann nicht mehrere Zweige in einen ungeborenen Zweig zusammenführen"
 
 #: git-pull.sh:257
 msgid "Cannot rebase onto multiple branches"
-- 
1.7.10.625.g300dcf

Re: [PATCH de.po 5/5] de.po: collection of suggestions

[Ralf Thielow]

Looks good so far.
I amended (and applied) your patch but have changed the following parts.
If you don't agree with them, please let me know. Commonly I don't change
a patch but I want to get these changes in and I think you'll agree with my
changes.

> +"um die Auflösung entsprechend zu markieren und einzutragen,\n"
>  "oder benutze 'git commit -a'."

There are a couple of other parts in the file with the same pattern.
I've changed them in the same way.

>  #: wt-status.c:207
>  msgid "bug"
> -msgstr "Fehler"
> +msgstr "Bug"

I don't think that "Bug" is a better translation than "Fehler". It's not
really a German word. Most of the German people should
know what that means, but at least it's the same question
like the translation of terms like "commit". I removed it for now.

> +"und benutze dann 'git add/rm <Datei>' \n"

I removed the whitespace before the line break.

I also changed "..packen..." to "...Packen...".

Thanks

Re: [PATCH de.po 5/5] de.po: collection of suggestions

[Thomas Rast]

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

>>  #: wt-status.c:207
>>  msgid "bug"
>> -msgstr "Fehler"
>> +msgstr "Bug"
>
> I don't think that "Bug" is a better translation than "Fehler". It's not
> really a German word. Most of the German people should
> know what that means, but at least it's the same question
> like the translation of terms like "commit". I removed it for now.

Ok.  My rationale was that given "Bug", the user would be more likely to
send an email reporting it.  But it probably doesn't matter.

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

Re: [PATCH de.po 5/5] de.po: collection of suggestions

[Christian Stimming]

As one of the earlier translators: I agree with most of those as well. Thanks 
a lot. However, one small remark:

Am Mittwoch, 2. Mai 2012, 15:49:27 schrieb Thomas Rast:
> @@ -676,11 +675,11 @@ msgstr "hinter "
> 
>  #: wt-status.c:908 wt-status.c:911
>  msgid "ahead "
> -msgstr "über "
> +msgstr "weiter: "
> 
>  #: wt-status.c:913
>  msgid ", behind "
> -msgstr ", hinter "
> +msgstr ", zurückgefallen "
> 
>  #: builtin/add.c:62
>  #, c-format
> @@ -903,12 +902,12 @@ msgstr "Zweig '%s' zeigt auf keine Version"
>  #: builtin/branch.c:396
>  #, c-format
>  msgid "behind %d] "
> -msgstr "hinter %d] "
> +msgstr "%d hinterher] "
> 
>  #: builtin/branch.c:398
>  #, c-format
>  msgid "ahead %d] "
> -msgstr "vor %d] "
> +msgstr "%d voraus] "

In the above hunk, you said "ahead = weiter" and "behind = zurückgefallen", 
but now you say "ahead = voraus" and "behind = hinterher". Is it helpful to 
use two different translations, or shouldn't those rather be chosen 
identically? The second set sounds somewhat better to me, but the more 
important question is whether both hunks should use the same translations.

Best Regards,

Christian

Re: [PATCH de.po 5/5] de.po: collection of suggestions

[Thomas Rast]

Christian Stimming <stimming@tuhh.de> writes:

> As one of the earlier translators: I agree with most of those as well. Thanks 
> a lot. However, one small remark:
>
> Am Mittwoch, 2. Mai 2012, 15:49:27 schrieb Thomas Rast:
>> @@ -676,11 +675,11 @@ msgstr "hinter "
>> 
>>  #: wt-status.c:908 wt-status.c:911
>>  msgid "ahead "
>> -msgstr "über "
>> +msgstr "weiter: "
>> 
>>  #: wt-status.c:913
>>  msgid ", behind "
>> -msgstr ", hinter "
>> +msgstr ", zurückgefallen "
>> 
>>  #: builtin/add.c:62
>>  #, c-format
>> @@ -903,12 +902,12 @@ msgstr "Zweig '%s' zeigt auf keine Version"
>>  #: builtin/branch.c:396
>>  #, c-format
>>  msgid "behind %d] "
>> -msgstr "hinter %d] "
>> +msgstr "%d hinterher] "
>> 
>>  #: builtin/branch.c:398
>>  #, c-format
>>  msgid "ahead %d] "
>> -msgstr "vor %d] "
>> +msgstr "%d voraus] "
>
> In the above hunk, you said "ahead = weiter" and "behind = zurückgefallen", 
> but now you say "ahead = voraus" and "behind = hinterher". Is it helpful to 
> use two different translations, or shouldn't those rather be chosen 
> identically? The second set sounds somewhat better to me, but the more 
> important question is whether both hunks should use the same translations.

Yeah, sorry about that.  The whole thing is a mess because of the lego
going on.  It would probably be better to first patch the code into
shape so that it builds the displays in one step, and then translate
that.  As it stands, it's very hard to translate because wt-status.c
does not even let you reposition the number.

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

[PATCH on ab/i18n] branch: remove lego in i18n tracking info strings

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 On Thu, May 3, 2012 at 2:42 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
 > Christian Stimming <stimming@tuhh.de> writes:
 >
 >> As one of the earlier translators: I agree with most of those as well. Thanks
 >> a lot. However, one small remark:
 >>
 >> Am Mittwoch, 2. Mai 2012, 15:49:27 schrieb Thomas Rast:
 >>> @@ -676,11 +675,11 @@ msgstr "hinter "
 >>>
 >>>  #: wt-status.c:908 wt-status.c:911
 >>>  msgid "ahead "
 >>> -msgstr "über "
 >>> +msgstr "weiter: "
 >>>
 >>>  #: wt-status.c:913
 >>>  msgid ", behind "
 >>> -msgstr ", hinter "
 >>> +msgstr ", zurückgefallen "
 >>>
 >>>  #: builtin/add.c:62
 >>>  #, c-format
 >>> @@ -903,12 +902,12 @@ msgstr "Zweig '%s' zeigt auf keine Version"
 >>>  #: builtin/branch.c:396
 >>>  #, c-format
 >>>  msgid "behind %d] "
 >>> -msgstr "hinter %d] "
 >>> +msgstr "%d hinterher] "
 >>>
 >>>  #: builtin/branch.c:398
 >>>  #, c-format
 >>>  msgid "ahead %d] "
 >>> -msgstr "vor %d] "
 >>> +msgstr "%d voraus] "
 >>
 >> In the above hunk, you said "ahead = weiter" and "behind = zurückgefallen",
 >> but now you say "ahead = voraus" and "behind = hinterher". Is it helpful to
 >> use two different translations, or shouldn't those rather be chosen
 >> identically? The second set sounds somewhat better to me, but the more
 >> important question is whether both hunks should use the same translations.
 >
 > Yeah, sorry about that.  The whole thing is a mess because of the lego
 > going on.  It would probably be better to first patch the code into
 > shape so that it builds the displays in one step, and then translate
 > that.  As it stands, it's very hard to translate because wt-status.c
 > does not even let you reposition the number.

 The translator in me totally agrees with you. I'll look into
 wt-status legos, but we probably need better infrastructure to mix
 color and text. Pseudo html tags to to mark color, like
 "On branch <color1>%s</color1>" is probably not a bad idea.

 builtin/branch.c |   31 ++++++++++++++++++++++---------
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/builtin/branch.c b/builtin/branch.c
index 8813d2e..5011881 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -384,6 +384,7 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
 		int show_upstream_ref)
 {
 	int ours, theirs;
+	const char *ref = NULL;
 	struct branch *branch = branch_get(branch_name);
 
 	if (!stat_tracking_info(branch, &ours, &theirs)) {
@@ -394,16 +395,28 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
 		return;
 	}
 
-	strbuf_addch(stat, '[');
 	if (show_upstream_ref)
-		strbuf_addf(stat, "%s: ",
-			shorten_unambiguous_ref(branch->merge[0]->dst, 0));
-	if (!ours)
-		strbuf_addf(stat, _("behind %d] "), theirs);
-	else if (!theirs)
-		strbuf_addf(stat, _("ahead %d] "), ours);
-	else
-		strbuf_addf(stat, _("ahead %d, behind %d] "), ours, theirs);
+		ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);
+	if (!ours) {
+		if (ref)
+			strbuf_addf(stat, _("[%s: behind %d]"), ref, theirs);
+		else
+			strbuf_addf(stat, _("[behind %d]"), theirs);
+
+	} else if (!theirs) {
+		if (ref)
+			strbuf_addf(stat, _("[%s: ahead %d]"), ref, ours);
+		else
+			strbuf_addf(stat, _("[ahead %d]"), ours);
+	} else {
+		if (ref)
+			strbuf_addf(stat, _("[%s: ahead %d, behind %d]"),
+				    ref, ours, theirs);
+		else
+			strbuf_addf(stat, _("[ahead %d, behind %d]"),
+				    ours, theirs);
+	}
+	strbuf_addch(stat, ' ');
 }
 
 static int matches_merge_filter(struct commit *commit)
-- 
1.7.8.36.g69ee2

Re: [PATCH on ab/i18n] branch: remove lego in i18n tracking info strings

[Junio C Hamano]

Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:

> Pseudo html tags to to mark color, like
>  "On branch <color1>%s</color1>" is probably not a bad idea.

The output machinery needs to understand _some_ color mark-up if the
destination does not support ANSI colors natively, and there already is
such a code in compat/ for windows IIRC.  Adding yet another color mark-up
wouldn't help anybody.  I would suggest to just declare that internally we
use ANSI colors as the standard color mark-up and be done with it.

>  builtin/branch.c |   31 ++++++++++++++++++++++---------
>  1 files changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 8813d2e..5011881 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -384,6 +384,7 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
>  		int show_upstream_ref)
>  {
>  	int ours, theirs;
> +	const char *ref = NULL;
>  	struct branch *branch = branch_get(branch_name);
>  
>  	if (!stat_tracking_info(branch, &ours, &theirs)) {
> @@ -394,16 +395,28 @@ static void fill_tracking_info(struct strbuf *stat, const char *branch_name,
>  		return;
>  	}
>  
> -	strbuf_addch(stat, '[');
>  	if (show_upstream_ref)
> -		strbuf_addf(stat, "%s: ",
> -			shorten_unambiguous_ref(branch->merge[0]->dst, 0));
> -	if (!ours)
> -		strbuf_addf(stat, _("behind %d] "), theirs);
> -	else if (!theirs)
> -		strbuf_addf(stat, _("ahead %d] "), ours);
> -	else
> -		strbuf_addf(stat, _("ahead %d, behind %d] "), ours, theirs);
> +		ref = shorten_unambiguous_ref(branch->merge[0]->dst, 0);
> +	if (!ours) {
> +		if (ref)
> +			strbuf_addf(stat, _("[%s: behind %d]"), ref, theirs);
> +		else
> +			strbuf_addf(stat, _("[behind %d]"), theirs);
> +
> +	} else if (!theirs) {
> +		if (ref)
> +			strbuf_addf(stat, _("[%s: ahead %d]"), ref, ours);
> +		else
> +			strbuf_addf(stat, _("[ahead %d]"), ours);
> +	} else {
> +		if (ref)
> +			strbuf_addf(stat, _("[%s: ahead %d, behind %d]"),
> +				    ref, ours, theirs);
> +		else
> +			strbuf_addf(stat, _("[ahead %d, behind %d]"),
> +				    ours, theirs);
> +	}
> +	strbuf_addch(stat, ' ');

You should free "ref" here, as it is an allocated piece of memory you own.

Re: [PATCH on ab/i18n] branch: remove lego in i18n tracking info strings

[Nguyen Thai Ngoc Duy]

On Fri, May 4, 2012 at 11:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> Pseudo html tags to to mark color, like
>>  "On branch <color1>%s</color1>" is probably not a bad idea.
>
> The output machinery needs to understand _some_ color mark-up if the
> destination does not support ANSI colors natively, and there already is
> such a code in compat/ for windows IIRC.  Adding yet another color mark-up
> wouldn't help anybody.  I would suggest to just declare that internally we
> use ANSI colors as the standard color mark-up and be done with it.

Ævar started a new thread about this and I elaborated a little bit
there [1]. We cannot just put straight ANSI colors in the string
because they are customizable. We don't know what color to put in the
string at compile time. So we need an intermediate color
representation for translators anyway to avoid fragmented strings. The
problem is which way is better, "On branch %s%s%s", "On branch
<color>%s</color>" or some other ways

[1] http://thread.gmane.org/gmane.comp.version-control.git/196869/focus=196908
-- 
Duy

Re: [PATCH 0/5] de.po suggested updates

[Ralf Thielow]

> [2/5] does away with the "bare"->"leer" issue that I used as an
>      example earlier.  There's precedent in git-gui :-( This does
>      raise the question if it's kosher to patch both git and git-gui
>      at the same time, but if we want to keep the translations in
>      sync it probably won't be the last such patch.
>
> [3/5] collects all the "obvious" stuff
>
> [4/5] and [5/5] gather the less-obvious stuff -- keep what you like.

Looks good.

I applied 2-4 and most of the 5th (i'll comment it for itself)  on my
maint branch.

Thanks

Re: [PATCH 0/5] de.po suggested updates

[Christian Stimming]

Am Mittwoch, 2. Mai 2012, 15:49:22 schrieb Thomas Rast:
> The rest are for Ralf.
> 
> [2/5] does away with the "bare"->"leer" issue that I used as an
>       example earlier.  There's precedent in git-gui :-( This does
>       raise the question if it's kosher to patch both git and git-gui
>       at the same time, but if we want to keep the translations in
>       sync it probably won't be the last such patch.
> 
> [3/5] collects all the "obvious" stuff
> 
> [4/5] and 

As one of the earlier translators: I agree with all of those and I agree those 
are completely improvements. Thanks for improving the translation!

Regards,

Christian

> [5/5] gather the less-obvious stuff -- keep what you like.
> 
> Cheers,
> Thomas
> 
> Thomas Rast (5):
>   stash: make "saved" message translatable
>   de.po: translate "bare" as "bloß"
>   de.po: hopefully uncontroversial fixes
>   de.po: translate "bad" as "ungültig" ("invalid")
>   de.po: collection of suggestions
> 
>  git-gui/po/de.po |    4 +-
>  git-stash.sh     |    2 +-
>  po/de.po         |  153
> +++++++++++++++++++++++++----------------------------- 3 files changed, 74
> insertions(+), 85 deletions(-)

Re: Please pull git-po master branch

[Junio C Hamano]

Thomas Rast <trast@student.ethz.ch> writes:

> Hi Xin (is that how you are properly addressed?)
> Hi Ralf
>
> Jiang Xin <worldhello.net@gmail.com> writes:
>> Ralf Thielow (3):
>>       l10n: Add the German translation team and initialize de.po
>>       l10n: Initial German translation
>>       l10n: Update German translation
>
> Junio C Hamano <gitster@pobox.com> writes:
>> Both branches pulled; I found it somewhat iffy to *add* new language support
>> on the maintenance track, but decided to let it pass this time.
>> 
>> A new lang.po file is very unlikely to introduce regression to anybody
>> else, so it probably is OK.
>
> Objection.
>
> Jan "jast" Krüger and me had most of the following "in the works", and
> couldn't get it shaped up before the pull request went out.  Any
> translation mistakes are mine, we drafted it in German.
> ...
> To put it bluntly, we have significant concerns with your translation so
> far.  That's usually not a problem in OSS -- release early and release
> and release often -- but the maint release would require you to get it
> Right(tm) the first time.

While I can understand your frustration and trust you enough to believe
the issue you are raising for the *.po contents that were merged are very
real, it is too late for this round. What happened has happened already.

Sorry about that.

But I have to be able to trust that such differences are resolved between
the i18n coordinator and the l10n teams before a pull request comes to me.
That's the only way we can scale the process.

> Of course now that it has been released, we'll also have to file patches
> in the true open source spirit.  Sigh.

There is nothing to "Sigh" about.  Mistakes happen, and we learn from it.

Thanks.

Re: Please pull git-po master branch

[Jiang Xin]

2012/5/3 Junio C Hamano <gitster@pobox.com>:
> Thomas Rast <trast@student.ethz.ch> writes:
>
>> Hi Xin (is that how you are properly addressed?)
Yeah, as a Chinese, surname is always before given name.

>> Junio C Hamano <gitster@pobox.com> writes:
> There is nothing to "Sigh" about.  Mistakes happen, and we learn from it.

What I have learned from this:

 * Only pull reqests with updates of already exists language are accepted
   for the 'maint' branch of git-po. If a new l10n language support wants to
   be added to 'maint' branch or to the RC version, it must be fully
   discussed int this list.

 * Pull requests with a initial XX.po (untranslated) and updated TEAMS file
   will not merge to the master branch, but merge to a work in progress
   branch, such as WIP/XX.

   In order to coordinate works of potential contributors for a new l10n
   language, l10n team leader (the 1st contributor send me a pull request)
   will send a pull requst with a untranslated XX.po and update TEAMS
   file with URL of the dedicated repository for the new language XX.
   Nobody can guarantee how long XX.po will 100% translated. If merge
   this initial commit too soon to the master branch, unfinished *.po will
   be released, like da.po from Byrial Jensen, nl.po from
   Vincent van Ravesteijn, and pt_PT.po from Marco Sousa.
   So create a WIP/XX branch may resolved this problem.

Update the po/README file as follows, does it make sense?

diff --git a/po/README b/po/README
index c1520..6e047 100644
--- a/po/README
+++ b/po/README
@@ -10,19 +10,36 @@ coordinates our localization effort in the l10
coordinator repository:

         https://github.com/git-l10n/git-po/

-As a contributor for a language XX, you should first check TEAMS file in
-this directory to see whether a dedicated repository for your language XX
-exists. Fork the dedicated repository and start to work if it exists.
+As a contributor for a language XX, you should first check whether a
+dedicated repository for your language XX already exists.
+
+ * Check po/TEAMS file in the master branch of git-po to see whether a
+   dedicated repository for your language XX exists.
+
+ * If a work in progress branch 'WIP/XX' exists in the l10n coordinator
+   repository, check po/TEAMS file in it.
+
+When you find the dedicated repository, fork it and start to work.

 If you are the first contributor for the language XX, please fork this
-repository, prepare and/or update the translated message file po/XX.po
-(described later), and ask the l10n coordinator to pull your work.
+repository, make a initial commit with the po/XX.po file (based on the
+po/git.pot in the master branch, and untranslated is fine) and a updated
+po/TEAMS file (indent with TABS, no SPACES), and ask the l10n
+coordinator to pull your work.
+
+The l10n coordinator will prepare a new branch, WIP/XX, for your language,
+so other contributors can find your team easily.

 If there are multiple contributors for the same language, please first
 coordinate among yourselves and nominate the team leader for your
 language, so that the l10n coordinator only needs to interact with one
 person per language.

+After translations on po/XX.po is 100% complete, l10n team leader for
+language XX should send a pull request again. If the translations pass
+the basic syntax check, the l10n coordinator will merge your work to
+the master branch of git-po, and delete the WIP/XX branch.
+
 The overall data-flow looks like this:

     +-------------------+            +------------------+
@@ -52,11 +69,20 @@ Maintaining the po/git.pot file

 The po/git.pot file contains a message catalog extracted from Git's
 sources. The l10n coordinator maintains it by adding new translations with
-msginit(1), or update existing ones with msgmerge(1).  In order to update
-the Git sources to extract the messages from, the l10n coordinator is
-expected to pull from the main git repository at strategic point in
-history (e.g. when a major release and release candidates are tagged),
-and then run "make pot" at the top-level directory.
+msginit(1), or update existing ones with msgmerge(1).
+
+The two branches (maint and master) in git-po are used for tracking l10n
+of the counterparts of git.git. The update of po/git.pot for these two
+branches are slight different.
+
+ * When there are significant i18n updates in git.git master branch, the
+   l10n coordinator will pull from the master branch of the main git
+   repository, and then run "make pot" at the top-level directory.
+
+ * When there are significant i18n updates in git.git maint branch, update
+   the po/git.pot file like the above. Then, the l10n coordinator should
+   merge updates in the maint branch back to the master branch, and choose
+   local po/git.pot as a conflict resolution.

 Language contributors use this file to prepare translations for their
 language, but they are not expected to modify it.
@@ -68,7 +94,8 @@ Initializing a XX.po file
 (This is done by the language teams).

 If your language XX does not have translated message file po/XX.po yet,
-you add a translation for the first time by running:
+you add a translation (based on the po/git.pot file in the master branch)
+for the first time by running:

     msginit --locale=XX

@@ -116,6 +143,14 @@ in the po/ directory, where XX.po is the file you
want to update.
 Once you are done testing the translation (see below), commit the result
 and ask the l10n coordinator to pull from you.

+Please note:
+
+ * commits to the master branch will go into the next release;
+ * commits to the maint branch will go into the next "maintenance
+   release"; and
+ * commits to the maint branch will merge back to the master branch by the
+   l10n coordinator.
+

-- 
Jiang Xin

Re: Please pull git-po master branch

[Junio C Hamano]

Jiang Xin <worldhello.net@gmail.com> writes:

> What I have learned from this:
>
>  * Only pull reqests with updates of already exists language are accepted
>    for the 'maint' branch of git-po. If a new l10n language support wants to
>    be added to 'maint' branch or to the RC version, it must be fully
>    discussed int this list.
>
>  * Pull requests with a initial XX.po (untranslated) and updated TEAMS file
>    will not merge to the master branch, but merge to a work in progress
>    branch, such as WIP/XX.
>
>    In order to coordinate works of potential contributors for a new l10n
>    language, l10n team leader (the 1st contributor send me a pull request)
>    will send a pull requst with a untranslated XX.po and update TEAMS
>    file with URL of the dedicated repository for the new language XX.
>    Nobody can guarantee how long XX.po will 100% translated. If merge
>    this initial commit too soon to the master branch, unfinished *.po will
>    be released, like da.po from Byrial Jensen, nl.po from
>    Vincent van Ravesteijn, and pt_PT.po from Marco Sousa.
>    So create a WIP/XX branch may resolved this problem.

I am not sure if writing down bureaucratic-sounding and rigid rules is the
best first response to this kind of incident. It's a learning process for
all of us involved, and in early rounds like this, mistakes are bound to
happen, and the first response should be to admit it, i.e. "Sorry, there
was a miscommunication and gap in understanding among us. I as the i18n
coordinator should have double checked before responding to pull requests
to see if there was a consensus within the l10n team for the particular
language. I'll try to be more careful until we nail the procedure down and
everybody gets more comfortable with the process."

Obviously I was also at fault that I didn't double check with you to make
sure that the l10n teams involved were happy with what you are about to
feed me, and I was wrong to instead blindly have assumed that it was the
case.  I should have done so until I get to know you better that you would
always operate in such a careful fashion [*1*].

Once a sound process of human communication is in place, I do not think a
rigid rule like "no new language to 'maint'" is particularly necessary.


[Footnote]

*1* Yes, I am saying that I shouldn't have blindly trusted you, and
similarly, I expect you to learn not to blindly trust l10n people you work
with, until you know they know you expect that they sufficiently
coordinate among themselves within the l10n team for a single language
before sending you an integration request.  Don't take this in a wrong
way.  Trust will come after repeated interactions and learning the other
parties you are working with.

Re: Please pull git-po master branch

[Jiang Xin]

2012/5/3 Junio C Hamano <gitster@pobox.com>:
> I am not sure if writing down bureaucratic-sounding and rigid rules is the
> best first response to this kind of incident.

I think a WIP/XX branch is nessary in the early phase of new language XX.
If a contributor sent a pull request with a untranslated XX.po, and said,
"Please pull this initial commit to master branch, so that other contributors
may notice a team of XX already exists, and won't translate it twice."
It does make sense, but what if this contributor gives up at last for some
reasons, and left a zero translated XX.po in po/ directory?

Create a WIP/XX branch and merge it back to master branch when the
translation is 100% (or 90%) completed. The WIP/XX branch will be deleted
after that. The overall workflow does not changed, no extra work for l10n
teams, and leave po/README unchanged is OK.

> the first response should be to admit it, i.e. "Sorry, there
> was a miscommunication and gap in understanding among us. I as the i18n
> coordinator should have double checked before responding to pull requests
> to see if there was a consensus within the l10n team for the particular
> language. I'll try to be more careful until we nail the procedure down and
> everybody gets more comfortable with the process."

Yes. I'm sorry about that. I think disallow new l10n support to the maint
branch and later rc phase will solve this problem.


-- 
Jiang Xin

Re: Please pull git-po master branch

[Thomas Rast]

Jiang Xin <worldhello.net@gmail.com> writes:

>  * Pull requests with a initial XX.po (untranslated) and updated TEAMS file
>    will not merge to the master branch, but merge to a work in progress
>    branch, such as WIP/XX.

Please don't take my complaint as a request to completely over-engineer
the process, that will just make it more work for everyone and scare
away potential translators.

I think it's sufficient to

* not put _completely new_ translations in maint

This one is actually very similar to the rule for code: maint does not
usually get new features either.  (The only exception I'm aware of is
when maint needs to learn to "speak" a new format introduced in newer
versions.)

* not submit pull requests late in the rc phase

With a similar reasoning.  Because there are usually several -rc tags,
doing this will ensure that the new translations get fairly wide
exposure with interested developers.

So more or less what we do for code, too.


Of course there's the flip side that I should have watched i18n more
closely (as evidenced by me being a loudmouth now).

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