Please review this pull request for maint branch with update of de.po

Please review this pull request for maint branch with update of de.po

[Jiang Xin]

Hi Junio and members of German l10n team,

Ralf send me two pull requests with improvement of Git German translation.
All look fine except that one commit (fbd994d) by Thomas hacks a file
"git-gui/po/de.po", which is outside of "po/" directory.

The following changes since commit bf505158d0292eed441fff1bc9157da19645ee91:

 Git 1.7.10.1 (2012-05-01 21:18:44 -0700)

are available in the git repository at:

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

for you to fetch changes up to c7e01d305fd50a216d990fcaf03da66a803a69df:

 Merge branch 'ralfth/git-po-de/maint' into maint (2012-05-08 06:20:33 +0800)

----------------------------------------------------------------

Jiang Xin (1):
     Merge branch 'ralfth/git-po-de/maint' into maint

Ralf Thielow (5):
     l10n: add new members to German translation team
     l10n: de.po: translate "track" as "beobachten"
     l10n: de.po: translate "remote" as "extern"
     l10n: de.po: collection of improvements
     l10n: de.po: unify translation of "ahead" and "behind"

Thomas Rast (4):
     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 |    2 +-
 po/TEAMS         |    3 +
 po/de.po         |  452 +++++++++++++++++++++++++++---------------------------
 3 files changed, 226 insertions(+), 231 deletions(-)

--
Jiang Xin


-- 
蒋鑫

北京群英汇信息技术有限公司
邮件: worldhello.net@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 010-51262007, 18601196889

Re: Please review this pull request for maint branch with update of de.po

[Junio C Hamano]

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

> Hi Junio and members of German l10n team,
>
> Ralf send me two pull requests with improvement of Git German translation.
> All look fine except that one commit (fbd994d) by Thomas hacks a file
> "git-gui/po/de.po", which is outside of "po/" directory.

Sorry, but I cannot take this tree for two reasons:

 - If the state of the tree needs to be confirmed by l10n team, and it is
   possible that you need to cancel this pull request based on their
   feedback, I cannot pull it from you right now; otherwise your corrected
   history won't fast-forward anymore.  So the message should either be
   "Please make sure I have what l10n teams wanted to send out" to them,
   or "I am confident that l10n teams are happy with this, please pull" to
   me, but cannot be both.

 - git-gui/ part of my tree is maintained without the rest of git.git/
   tree by Pat Thoyts, and an update needs to go through that tree. I
   cannot take a change directly to that part.  Doing so would make
   it impossible to update git-gui/ project independently.

Please redo your tree by having the originating author separate the
git-gui part out, make sure everybody on the l10n team is happy with the
result, and then throw me another pull request.  Also arrange the git-gui
patch to go through Pat.

By the way, a change to the 'master' track is exactly the same deal, but
I would suspect that typically you would want your pull request for 'master'
a superset of your 'maint', so please hold off throwing a pull request for
'master' while it still is possible that you might need to rewind and
rebuild your 'maint'.

Thanks.

Re: Please review this pull request for maint branch with update of de.po

[Thomas Rast]

[+cc Pat]

Junio C Hamano <gitster@pobox.com> writes:

>  - git-gui/ part of my tree is maintained without the rest of git.git/
>    tree by Pat Thoyts, and an update needs to go through that tree. I
>    cannot take a change directly to that part.  Doing so would make
>    it impossible to update git-gui/ project independently.
>
> Please redo your tree by having the originating author separate the
> git-gui part out, make sure everybody on the l10n team is happy with the
> result, and then throw me another pull request.  Also arrange the git-gui
> patch to go through Pat.

I suspected something like this might happen, but proposed a
simultaneous change anyway.  My bad.  Ralf, can you split it or should I
resend?

But for next time, can there be another solution?  It seems that this
process will make it very hard in general to keep the git-gui and core
git translations in sync.

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

Re: Please review this pull request for maint branch with update of de.po

[Ralf Thielow]

> I suspected something like this might happen, but proposed a
> simultaneous change anyway.  My bad.  Ralf, can you split it or should I
> resend?

Is it ok for you if I remove your change to git-gui completely
from the patch? Perhaps we can sync the translation to
git-gui within a complete new patch (-series). That implies
that Xin and I have to rewrite our history, don't?.
It's pretty much easier to add a new commit which
simply removes the change from git-gui.

Ralf

Re: Please review this pull request for maint branch with update of de.po

[Jiang Xin]

2012/5/8 Ralf Thielow <ralf.thielow@googlemail.com>:
> git-gui within a complete new patch (-series). That implies
> that Xin and I have to rewrite our history, don't?.

History of both master and maint branch of git-po has been
rewritten, and new git.pot is generated for both maint and
master branch. I see the tip commit of git.git maint branch is
"Start preparing for 1.7.10.2", and there is 1 new message,
so maybe no futher git.pot update for 1.7.10.2.

> It's pretty much easier to add a new commit which
> simply removes the change from git-gui.

Maybe you can work like this:

First, remove hacks on git-gui by a interactive rebase.

1. Start a interactive rebase against parent commit of fbd994d.

    $ git rebase -i fbd994d^

2. In the editor, change command for commit fbd994d
    from pick to edit; save and quit the edit.

3. The rebase process will stop at commit fbd994d.
    Revert hacks on "git-gui/po/de.po" by a checkout:

    $ git checkout HEAD^ -- git-gui/po/de.po

4. Amend your commit.

    $ git commit --amend

5. Continue the interactive rebase.

    $ git rebase --continue

Second, fetch the new maint branch from git-l10n/git-po
and do a rebase or merge. I prefer rebase, because
you won't have to write a merge commit log. ;-)

    $ git fetch https://github.com/git-l10n/git-po.git maint
    $ git rebase FETCH_HEAD

Then msgmerge git.pot to de.po, and translate 1 new message.

No forget reset your master branch completely before
merge the maint branch.

-- 
Jiang Xin

Re: Please review this pull request for maint branch with update of de.po

[Junio C Hamano]

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

> But for next time, can there be another solution?  It seems that this
> process will make it very hard in general to keep the git-gui and core
> git translations in sync.

That unfortunately is fundamental in the way git-gui and the core git are
related to each other, and the story is the same for gitk.

The arrangement to pull only in one direction comes from the initial
desire from the maintainers of these "merge -s subtree" merged projects.
These source trees are designed to be usable without being embedded inside
a source tree of the core git, and when people want to work only on one of
these projects, their clone will not have to carry any material from the
history of the git core side.  The git core side didn't _have_ to have
them as part of its tree, but because it makes distribution to end users
more convenient, and that was the reason why we have these as part of our
tree.

Theoretically, we could ignore the wish of git-gui/gitk projects and apply
patches that touch these two parts directly to the git core tree, and let
the maintainers of these projects deal with the consequences.  They can
cherry-pick only a part of your commit from the git core tree to their
trees while still retaining their independence, for example, and my next
merge from them will see "both sides added identically or made identical
changes", which is not a huge deal.  But that adds burden to integrators,
which is not a scalable solution when contributors can make the burden
smaller.

The downside is of course the two projects won't be synchronised, but that
is inherent---the contained projects do *not* want to be synchronised in
the first place.  The price these projects pay is that they cannot affect
what is outside of their trees (e.g. they cannot add test scripts to our
side to test the new feature in their new tree).

Another downside, once "merge -s subtree" is made, is that tracking
changes in such a semi-subproject in the context of the containing project
becomes harder, as we will continuously seeing what is essentially a
renaming merge.  But it still is manageable as long as the merge is in one
direction only.  When inspecting the history of the contained project, you
only need to find the last such merge to the containing project, and then
follow the history of its second parent, whose history will _not_ contain
anything from the containing project.

The recent contrib/subtree merge (not to be confused with "merge -s
subtree") follows quite an opposite approach from what was used for
git-gui/gitk.  It decided to cease to be an independent project to
eventually integrate it as a part of the core, and further development of
it will happen in the context of the layout of having the top of the last
of its tree at contrib/subtree.  Because it has involved a merge in the
"merge -s subtree" style once, it is harder to track its history beyond
that point, but by being the part of the larger tree from now on, we only
have to suffer once---it is inconvenient to inspect the history before the
merge, but that is a one-time transition pain.

Incidentally, that is why I would be _very_ reluctant to take further
merges for contrib/subtree if the merged history contain "git subtree"
merges that ran "merge -s subtree" in both ways.  It makes what is
supposedly just a one-time transition pain to continuous one.

Re: Please review this pull request for maint branch with update of de.po

[Ralf Thielow]

What about a README file like "/po" has?

Re: Please review this pull request for maint branch with update of de.po

[Junio C Hamano]

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

> What about a README file like "/po" has?

Sorry, but I cannot tell what you want to know about it.

Re: Please review this pull request for maint branch with update of de.po

[Ralf Thielow]

On Fri, May 11, 2012 at 9:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ralf Thielow <ralf.thielow@googlemail.com> writes:
>
>> What about a README file like "/po" has?
>
> Sorry, but I cannot tell what you want to know about it.
>

This was just an idea to do it in the same way.
What I want to say is that there is a README file in the po folder which
telling people that if they want to change something here, they have
to go through
the git.l10n repo to get changes into the git-core repo.
That's presumably the same situation here, isn't it?
Just an idea.

Re: Please review this pull request for maint branch with update of de.po

[Junio C Hamano]

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

> On Fri, May 11, 2012 at 9:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Ralf Thielow <ralf.thielow@googlemail.com> writes:
>>
>>> What about a README file like "/po" has?
>>
>> Sorry, but I cannot tell what you want to know about it.
>
> This was just an idea to do it in the same way.
> What I want to say is that there is a README file in the po folder which
> telling people that if they want to change something here, they have
> to go through
> the git.l10n repo to get changes into the git-core repo.
> That's presumably the same situation here, isn't it?

Hmph.  I thought we had something that was meant for contributors in
Documentation/SubmittingPatches, but apparently we don't.