Thread: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.

On Mon, 2011-06-20 at 11:58 +0000, Michael Meskes wrote:
>
> Fixed string in German translation that causes segfault.
>
> Applied patch by Christoph Berg <cb@df7cb.de> to replace placeholder
> "%s" by correct string.

AFAIK this won't have any effect. This change needs to go to through
pgtranslation project.
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Mon, Jun 20, 2011 at 03:03:37PM +0300, Devrim GÜNDÜZ wrote:
> On Mon, 2011-06-20 at 11:58 +0000, Michael Meskes wrote:
> > 
> > Fixed string in German translation that causes segfault.
> > 
> > Applied patch by Christoph Berg <cb@df7cb.de> to replace placeholder
> > "%s" by correct string.
> 
> AFAIK this won't have any effect. This change needs to go to through
> pgtranslation project.

Oops, didn't know that. Does that mean the files in our main git are not the
canonical versions? 

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

2011/6/20 Michael Meskes <meskes@postgresql.org>:
> On Mon, Jun 20, 2011 at 03:03:37PM +0300, Devrim GÜNDÜZ wrote:
>> On Mon, 2011-06-20 at 11:58 +0000, Michael Meskes wrote:
>> >
>> > Fixed string in German translation that causes segfault.
>> >
>> > Applied patch by Christoph Berg <cb@df7cb.de> to replace placeholder
>> > "%s" by correct string.
>>
>> AFAIK this won't have any effect. This change needs to go to through
>> pgtranslation project.
>
> Oops, didn't know that. Does that mean the files in our main git are not the
> canonical versions?

Yep.  Peter overrides them just before each release.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
> Yep.  Peter overrides them just before each release.

Aren't there better ways to implement this, like git submodules? This
redundancy seem awkward to me. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

On Mon, Jun 20, 2011 at 9:54 AM, Michael Meskes <meskes@postgresql.org> wrote:
> On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
>> Yep.  Peter overrides them just before each release.
>
> Aren't there better ways to implement this, like git submodules? This
> redundancy seem awkward to me.

Dunno.  I just work here.  :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Excerpts from Michael Meskes's message of lun jun 20 09:54:36 -0400 2011:
> On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
> > Yep.  Peter overrides them just before each release.
> 
> Aren't there better ways to implement this, like git submodules? This
> redundancy seem awkward to me. 

There might be, but currently the translations are still using the CVS
machinery on pgfoundry.  This stuff predates our move to Git.  It's
possible that Peter already changed the msgstr in pgtranslation ...

Peter is working on moving that CVS stuff to Git, but AFAIR it will
happen once 9.1 has released.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On mån, 2011-06-20 at 13:13 -0400, Alvaro Herrera wrote:
> Excerpts from Michael Meskes's message of lun jun 20 09:54:36 -0400 2011:
> > On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
> > > Yep.  Peter overrides them just before each release.
> > 
> > Aren't there better ways to implement this, like git submodules? This
> > redundancy seem awkward to me. 
> 
> There might be, but currently the translations are still using the CVS
> machinery on pgfoundry.  This stuff predates our move to Git.  It's
> possible that Peter already changed the msgstr in pgtranslation ...
> 
> Peter is working on moving that CVS stuff to Git, but AFAIR it will
> happen once 9.1 has released.

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.

On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut <peter_e@gmx.net> wrote:
> On mån, 2011-06-20 at 13:13 -0400, Alvaro Herrera wrote:
>> Excerpts from Michael Meskes's message of lun jun 20 09:54:36 -0400 2011:
>> > On Mon, Jun 20, 2011 at 09:15:52AM -0400, Robert Haas wrote:
>> > > Yep.  Peter overrides them just before each release.
>> >
>> > Aren't there better ways to implement this, like git submodules? This
>> > redundancy seem awkward to me.
>>
>> There might be, but currently the translations are still using the CVS
>> machinery on pgfoundry.  This stuff predates our move to Git.  It's
>> possible that Peter already changed the msgstr in pgtranslation ...
>>
>> Peter is working on moving that CVS stuff to Git, but AFAIR it will
>> happen once 9.1 has released.
>
> 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.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

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.
        regards, tom lane

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

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/

On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
> 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.

IIRC this is exactly what git submodules are for. We could do a git archive
only for translations as a submodule for our main git. That way translators
would only clone the translation git, while we still have the translations in
the source tree in the main git. At least this is how I think it works.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

On Tue, Jun 21, 2011 at 10:20, Michael Meskes <meskes@postgresql.org> wrote:
> On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
>> 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.
>
> IIRC this is exactly what git submodules are for. We could do a git archive
> only for translations as a submodule for our main git. That way translators
> would only clone the translation git, while we still have the translations in
> the source tree in the main git. At least this is how I think it works.

AFAIK (but I could be wrong), git submodules requires the files to be
in *one* subdirectory. Our .po files are distributed all across the
backend. So we'd have to make (and backpatch) som rather large changes
in how these things are built in order to use that.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Tue, Jun 21, 2011 at 01:36:05PM +0200, Magnus Hagander wrote:
> AFAIK (but I could be wrong), git submodules requires the files to be
> in *one* subdirectory. Our .po files are distributed all across the
> backend. So we'd have to make (and backpatch) som rather large changes
> in how these things are built in order to use that.

Ah, good point.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Excerpts from Magnus Hagander's message of mar jun 21 07:36:05 -0400 2011:
> On Tue, Jun 21, 2011 at 10:20, Michael Meskes <meskes@postgresql.org> wrote:
> > On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
> >> 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.
> >
> > IIRC this is exactly what git submodules are for. We could do a git archive
> > only for translations as a submodule for our main git. That way translators
> > would only clone the translation git, while we still have the translations in
> > the source tree in the main git. At least this is how I think it works.
> 
> AFAIK (but I could be wrong), git submodules requires the files to be
> in *one* subdirectory. Our .po files are distributed all across the
> backend. So we'd have to make (and backpatch) som rather large changes
> in how these things are built in order to use that.

If git submodules are so cool that we still want to use them, maybe we
still can -- can a submodule be submodule of more than one module?  If
so, we could create one submodule for each subdir that the translations
are stored in (about 20 currently), and then have a pgtranslation
meta-project that binds them all together as submodules.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, Jun 21, 2011 at 15:36, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Excerpts from Magnus Hagander's message of mar jun 21 07:36:05 -0400 2011:
>> On Tue, Jun 21, 2011 at 10:20, Michael Meskes <meskes@postgresql.org> wrote:
>> > On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
>> >> 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.
>> >
>> > IIRC this is exactly what git submodules are for. We could do a git archive
>> > only for translations as a submodule for our main git. That way translators
>> > would only clone the translation git, while we still have the translations in
>> > the source tree in the main git. At least this is how I think it works.
>>
>> AFAIK (but I could be wrong), git submodules requires the files to be
>> in *one* subdirectory. Our .po files are distributed all across the
>> backend. So we'd have to make (and backpatch) som rather large changes
>> in how these things are built in order to use that.
>
> If git submodules are so cool that we still want to use them, maybe we
> still can -- can a submodule be submodule of more than one module?  If
> so, we could create one submodule for each subdir that the translations
> are stored in (about 20 currently), and then have a pgtranslation
> meta-project that binds them all together as submodules.

Can you? Yes. But I doubt that would be very convenient to work with
that many submodules in general. If that's what we're looking at, what
we have now seems a lot more convenient.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Excerpts from Magnus Hagander's message of mar jun 21 11:01:58 -0400 2011:
> On Tue, Jun 21, 2011 at 15:36, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:

> > If git submodules are so cool that we still want to use them, maybe we
> > still can -- can a submodule be submodule of more than one module?  If
> > so, we could create one submodule for each subdir that the translations
> > are stored in (about 20 currently), and then have a pgtranslation
> > meta-project that binds them all together as submodules.
> 
> Can you? Yes. But I doubt that would be very convenient to work with
> that many submodules in general. If that's what we're looking at, what
> we have now seems a lot more convenient.

Yeah, after reading the manpage, I think it would be pretty
inconvenient for us.  Maybe if we were starting from scratch it would
make more sense.

(The main pain point is that you can't have the meta-project I suggested
above: a submodule is un-updatable from the including tree, you have to
check it out separately.  So we would have to move all the po files
into a single dir, as you said.)

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support