On Thu, Sep 2, 2010 at 23:04, Jonathan Nieder <jrnieder@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html