On Mon, Jun 20, 2011 at 22:44, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut <pete...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
