Excerpts from Tom Lane's message of lun jun 20 16:44:20 -0400 2011:
> 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.
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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support