Re: [PATCH 10/25] gettextize: git-merge basic messages
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2016-06-15 22:49:28
On Thu, Sep 2, 2010 at 23:04, Jonathan Nieder [off-list ref] wrote:
quoted
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.