Add PG version number to NLS files

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Cc: Martin Pitt <mpitt(at)debian(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Add PG version number to NLS files
Date: 2005-06-15 03:15:43
Message-ID: 200506150315.j5F3Fh502616@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


I have developed the following patch which adds PG_VERSION to the end of
language-specific file names. I used it for libpq too, rather than the
SONAME, because the language strings might change between versions while
the API/SONAME might not.

Would someone who uses NLS please test this? Thanks.

---------------------------------------------------------------------------

Bruce Momjian wrote:
>
> Is this a direction we want to explore --- using the SONAME as part of
> the translation domain?
>
> ---------------------------------------------------------------------------
>
> Martin Pitt wrote:
> -- Start of PGP signed section.
> > Hi!
> >
> > Bruce Momjian [2005-02-09 18:05 -0500]:
> > > > However, I just stumbled across another problem: libpq3 and the new
> > > > libpq4 use the same translation domain "libpq4", thus they cannot be
> > > > installed in parallel. Can you please change the domain to "libpq4" as
> > > > well? This should generally be done anyway, but at least we can live
> > > > with one breakage of this rule (for libpq3), so that we don't need to
> > > > mess with the old libpq3 package.
> > >
> > > Uh, what is the translation domain?
> >
> > In short, that is the unique name for a bunch of translations for a
> > particular application or group of related applications. The key point
> > is that the name of the file in
> > /usr/share/locale/<LOCALE>/LC_MESSAGES/<DOMAIN>.mo and the call
> >
> > bindtextdomain ("<DOMAIN>", NULL)
> >
> > must use the same <DOMAIN> so that libintl can find the mo file.
> > However, that means that all applications that are installed in
> > parallel need a distinct domain. Since the whole point of SONAMes is
> > to allow several different library API versions to be installed in
> > parallel, every library API (i. e. SONAME) should have an unique
> > domain, which can be achieved easiest by just appending the SONAME to
> > the translation domain.
> >
> > In my test packages I used the following patch:
> >
> > diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c postgresql-8.0.1/src/interfaces/libpq/fe-misc.c
> > --- postgresql-8.0.1-old/src/interfaces/libpq/fe-misc.c 2004-12-31 23:03:50.000000000 +0100
> > +++ postgresql-8.0.1/src/interfaces/libpq/fe-misc.c 2005-02-07 22:55:13.177419296 +0100
> > @@ -1133,7 +1133,7 @@
> > {
> > already_bound = 1;
> > /* No relocatable lookup here because the binary could be anywhere */
> > - bindtextdomain("libpq", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
> > + bindtextdomain("libpq4", getenv("PGLOCALEDIR") ? getenv("PGLOCALEDIR") : LOCALEDIR);
> > }
> >
> > return dgettext("libpq", msgid);
> > diff -ruN postgresql-8.0.1-old/src/interfaces/libpq/nls.mk postgresql-8.0.1/src/interfaces/libpq/nls.mk
> > --- postgresql-8.0.1-old/src/interfaces/libpq/nls.mk 2005-01-14 09:57:06.000000000 +0100
> > +++ postgresql-8.0.1/src/interfaces/libpq/nls.mk 2005-02-07 22:54:54.770217616 +0100
> > @@ -1,5 +1,5 @@
> > # $PostgreSQL: pgsql/src/interfaces/libpq/nls.mk,v 1.20 2005/01/14 08:57:06 petere Exp $
> > -CATALOG_NAME := libpq
> > +CATALOG_NAME := libpq4
> > AVAIL_LANGUAGES := af cs de es fr hr it ko nb pl pt_BR ru sk sl sv tr zh_CN zh_TW
> > GETTEXT_FILES := fe-auth.c fe-connect.c fe-exec.c fe-lobj.c fe-misc.c fe-protocol2.c fe-protocol3.c fe-secure.c
> > GETTEXT_TRIGGERS:= libpq_gettext pqInternalNotice:2
> >
> > Compared to the SONAME, changing the translation domain is relatively
> > uncritical, so if you don't want to change this upstream, I can
> > maintain this patch for Debian/Ubuntu. However, I heard that some RPM
> > guys plan a infrastructure similar to mine, and at that point they
> > will have precisely the same problems :-)
> >
> > Thanks for considering and have a nice day!
> >
> > Martin
> > --
> > Martin Pitt http://www.piware.de
> > Ubuntu Developer http://www.ubuntulinux.org
> > Debian GNU/Linux Developer http://www.debian.org
> -- End of PGP section, PGP failed!
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Attachment Content-Type Size
unknown_filename text/plain 5.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Qingqing Zhou 2005-06-15 03:23:20 Re: Autovacuum in the backend
Previous Message John Hansen 2005-06-15 03:14:17 Re: LGPL

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2005-06-15 05:55:59 Re: uptime function to postmaster
Previous Message Bruce Momjian 2005-06-15 01:34:30 Re: [HACKERS] Should *.backup files ever be removed from pg_xlog?