Обсуждение: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Devrim GÜNDÜZ
Дата:
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
Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Michael Meskes
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Robert Haas
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Michael Meskes
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Robert Haas
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Alvaro Herrera
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Peter Eisentraut
Дата:
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.
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Magnus Hagander
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Alvaro Herrera
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Magnus Hagander
Дата:
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/
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Michael Meskes
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Magnus Hagander
Дата:
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/
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Michael Meskes
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Alvaro Herrera
Дата:
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
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Magnus Hagander
Дата:
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/
Re: Re: [COMMITTERS] pgsql: Fixed string in German translation that causes segfault.
От
Alvaro Herrera
Дата:
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