Please pull git-po master branch

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

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.

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

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

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

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

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.

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.

That's a basic problem when messages are translated.

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

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

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?

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

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

Am Mittwoch, 2. Mai 2012, 21:14:05 schrieb Ralf Thielow:

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

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

---
 git-stash.sh |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 4e2c7f8..e614eb7 100755
@@ -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

Am Mittwoch, 2. Mai 2012, 15:49:22 schrieb Thomas Rast:

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

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.

---
 git-gui/po/de.po |    4 ++--
 po/de.po         |    6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

index 44c5ddc..9458f6e 100644
@@ -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 <[email protected]>\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"

index a43f646..a7a39ed 100644
@@ -8,7 +8,7 @@ msgstr ""
 "Project-Id-Version: git 1.7.10\n"
 "Report-Msgid-Bugs-To: Git Mailing List <[email protected]>\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 <[email protected]>\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

Looks good.

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

Thanks

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

---
 po/de.po |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

index a7a39ed..d391632 100644
@@ -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

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

---
 po/de.po |   26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

index d391632..a1a765a 100644
@@ -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

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.

---
 po/de.po |   97 ++++++++++++++++++++++++++++----------------------------------
 1 file changed, 43 insertions(+), 54 deletions(-)

index a1a765a..f6df558 100644
@@ -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

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:

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

---

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

index 8813d2e..5011881 100644
@@ -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

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

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.

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

I removed the whitespace before the line break.

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

Thanks

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

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.

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

Thanks.

2012/5/3 Junio C Hamano <[email protected]>:

Yeah, as a Chinese, surname is always before given name.

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?

index c1520..6e047 100644
@@ -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

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.

2012/5/3 Junio C Hamano <[email protected]>:

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.

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

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