FAQ

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

Search Discussions

  • Michael Meskes at Jun 20, 2011 at 12:32 pm

    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
  • Robert Haas at Jun 20, 2011 at 1:15 pm

    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
  • Michael Meskes at Jun 20, 2011 at 1:54 pm

    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
  • Robert Haas at Jun 20, 2011 at 4:58 pm

    On Mon, Jun 20, 2011 at 9:54 AM, Michael Meskes 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
  • Alvaro Herrera at Jun 20, 2011 at 5:14 pm

    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
  • Peter Eisentraut at Jun 20, 2011 at 8:21 pm

    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.
  • Magnus Hagander at Jun 20, 2011 at 8:24 pm

    On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut 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.
  • Tom Lane at Jun 20, 2011 at 8:44 pm

    Magnus Hagander writes:
    On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut 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
  • Alvaro Herrera at Jun 20, 2011 at 9:00 pm

    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 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
  • Magnus Hagander at Jun 20, 2011 at 9:01 pm

    On Mon, Jun 20, 2011 at 22:44, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> writes:
    On Mon, Jun 20, 2011 at 22:20, Peter Eisentraut 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.
  • Michael Meskes at Jun 21, 2011 at 8:20 am

    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
  • Magnus Hagander at Jun 21, 2011 at 11:36 am

    On Tue, Jun 21, 2011 at 10:20, Michael Meskes 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.
  • Michael Meskes at Jun 21, 2011 at 12:18 pm

    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
  • Alvaro Herrera at Jun 21, 2011 at 1:36 pm

    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 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
  • Magnus Hagander at Jun 21, 2011 at 3:02 pm

    On Tue, Jun 21, 2011 at 15:36, Alvaro Herrera 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 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.
  • Alvaro Herrera at Jun 21, 2011 at 3:19 pm

    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
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 20, '11 at 12:03p
activeJun 21, '11 at 3:19p
posts17
users7
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase