Excerpts from Tom Lane's message of lun jun 20 16:44:20 -0400 2011: > Magnus Hagander <[email protected]> writes: > > On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut <[email protected]> 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.
Yep. > 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. Honestly it doesn't seem all that good of an idea to me. We would have to merge changes from upstream PG repo into pgtranslation and the history would look awful on the translation side. I prefer something similar to the current system, where the two repos are kept separate and the files from pgtranslation are imported wholesale before each release, without any kind of merge. That keeps both histories clean. Maybe we could have a way to prevent commits to the .po files that don't come from the pgtranslation repository; probably we could have something with Git hooks for this (so you have to set an environment variable before being allowed the push, which wouldn't occur accidentally, or something like that.) (I admit I don't look that frequently into pgtranslation history, though.) -- Álvaro Herrera <[email protected]> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
