From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri, 03 Sep 2010 12:13:54 GMT
Subject: Re: [PATCH 10/25] gettextize: git-merge basic messages
Message-ID: <AANLkTimBbSz5TF5CBa0us5oLQ-t=S9HNdBSVifUUSiqt@mail.gmail.com>
In-Reply-To: <20100902230410.GA4850@burratino>

On Thu, Sep 2, 2010 at 23:04, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> I can't see why translations in the tree (in po/) should be any
>> trouble at all for us. What sort of issues do you see that the sed.git
>> model might solve?
>
> Only two: log noise and the problem of what to base patches on.
>
> As you noticed while gettextizing (which is pretty much a one-time
> thing), it is not much fun to do work on strings that aren't even
> going to be used.  So translators might want to work against "next",
> or at least "master".  How do the translations get back to "maint"?
> Someone has to backport them.  What happens when we merge back to
> "master"?
>
> Now multiply that by the number of translations.  Making messages
> merge up nicely with git tools as they drift from topic to topic if
> translators want to keep both "maint" and "master" translated would
> require at least a nice custom merge driver.
>
> As we noticed before, the .po files are partially automatically
> generated anyway.  Merging them as text makes about as much sense
> as merging Word-generated .rtf files as text.  To avoid wasting time,
> one wants to be able to work with their _content_.
>
> What is that content?
>
> It is a set of key/value pairs: for each string that appears in
> the codebase (maybe together with disambiguating translators' notes),
> what the translation is for it.  Merging that between branches of the
> code base is utterly trivial: take the union.  Actually "merging" as
> an operation here does not make sense.  It is not tied to the
> development history at all!
>
> Imagine v6.0.0 of git has message "foo".  v6.0.1 changes it to "bar"
> because "foo" is not actually true yet, v6.1.0 changes it back to
> "foo".  Imagine a linear development history.  Do we want translation
> diffs like this:
>
>  commit v6.0.0
>
>  +"foo" is "hello" in language X
>
>  commit v6.0.1
>
>  -"foo" is "hello" in language X
>  +"bar" is "goodbye" in language X
>
>  commit v6.1
>
>  -"bar" is "goodbye" in language X
>  +"foo" is "hello" in language X
>
> ?  But what really happened is this:
>
>  - add foo:hello to translation database
>  - add bar:goodbye to translation database
>
> I have been thinking about how to write a merge driver for .po files
> (and avoid the tedious merge problems that e.g. the dpkg project runs
> into periodically) but the idea of avoiding that altogether is very
> appealing to me.

Those issues might be a bit hard, but I still can't really see how
managing these files outside of git.git would make things easier.

You'd still need to do the merging of e.g. master -> maint
translations, you'd just have to do them outside of git.git, so you
wouldn't be able to do that using the normal merge facilities.

Maybe we can have a custom msgmerge merge driver (someone posted one
in #git-devel, but I've misplaced it), or maybe we should just use
msgmerge with --no-location.

But I'd like to coordinate things on this mailing list, and in
git.git, without some external service being mandatory.