On Mon, Jun 20, 2011 at 22:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut <peter_e@gmx.net> wrote:
>>> A better way might be that translators simply work on a clone of the
>>> source repository, which is then merged (as in, git merge) at release
>>> time. There are some issues with that to figure out, but it sounds like
>>> the obviously right thing, from an interface point of view.
>
>> I don't think we want to track every single translation update as
>> commits in the main repository - we don't do that for non-translation
>> stuff... If it's a squash-merge, that's a different thing, of
>> course...
>
>> Other than that, yes, keeping translations in git branches seems like
>> a good interface.
>
> My recollection is that the current setup was created mainly so that
> translators wouldn't need to be given commit privileges on the main
> repo. Giving them a separate repo to work in might be all right, but
> of course whoever does the merges would have to be careful to only
> accept changes made to the .po files and not anything else.
That should be easy enough to script - have the system automatically
merge the branches requied with "--squash", and then make sure that no
non-.po files are modified.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
