Thread: Proceeding with gettext
Has it been established to satisfaction that a BSD-licensed gettext
implementation is available and working? (Note that we still need
xgettext and msgmerge from GNU, but this only on the maintainer side.)
Are there any other concerns about the use of the gettext API, the
available implementations, or how this will work together with PostgreSQL?
If Yes and No, respectively, I'd like to put this to use.
Besides the source code changes to mark all translatable strings (which
can be reduced if we make use of short cuts like "all calls to elog() are
candidates"), and eliminate English dependent coding (printf("%d row%s",
n, n!=1?"s":"");), most of this will be makefile work in the style of
Makefile.shlib to take care of building, installing, and maintaining the
message catalogs. Plus a lot of translation work, of course. :-)
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter, can you give a little sample of how an elog() call would look in
the new system? Thanks.
> Has it been established to satisfaction that a BSD-licensed gettext
> implementation is available and working? (Note that we still need
> xgettext and msgmerge from GNU, but this only on the maintainer side.)
>
> Are there any other concerns about the use of the gettext API, the
> available implementations, or how this will work together with PostgreSQL?
>
> If Yes and No, respectively, I'd like to put this to use.
>
> Besides the source code changes to mark all translatable strings (which
> can be reduced if we make use of short cuts like "all calls to elog() are
> candidates"), and eliminate English dependent coding (printf("%d row%s",
> n, n!=1?"s":"");), most of this will be makefile work in the style of
> Makefile.shlib to take care of building, installing, and maintaining the
> message catalogs. Plus a lot of translation work, of course. :-)
>
> --
> Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> Bruce Momjian writes:
>
> > Peter, can you give a little sample of how an elog() call would look in
> > the new system? Thanks.
>
> No change.
>
> elog() would call gettext() internally, so the code change there is
> localized to elog.c. For other function calls that contain translatable
> message strings it looks like (example from psql):
>
> fprintf(stderr, gettext("Invalid command \\%s. Try \\? for help.\n"), my_line);
>
> So obviously it would pay off if the communication of a program was
> encapsulated in a limited number of functions.
Sounds great!
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian writes:
> Peter, can you give a little sample of how an elog() call would look in
> the new system? Thanks.
No change.
elog() would call gettext() internally, so the code change there is
localized to elog.c. For other function calls that contain translatable
message strings it looks like (example from psql):
fprintf(stderr, gettext("Invalid command \\%s. Try \\? for help.\n"), my_line);
So obviously it would pay off if the communication of a program was
encapsulated in a limited number of functions.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut <peter_e@gmx.net> writes:
>> Peter, can you give a little sample of how an elog() call would look in
>> the new system? Thanks.
> No change.
Wouldn't there need to be changes in the %-escape usage in elog message
strings?
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
>> Wouldn't there need to be changes in the %-escape usage in elog message
>> strings?
> Are you referring to the possibility that the parameters need to appear in
> a different order in the translated message? This can be handled if the
> translator uses the %1$s style place holder in the translated string.
Oh, I see: the translated message can use that form, but the original
need not. Okay.
Are you planning to tackle any of the other elog-related stuff that's
been discussed in the past? (Automatic file/linenumber information,
relabeling the set of severity codes, that sort of thing?) Sooner or
later we're going to have to bite the bullet and edit every elog
instance in the system. I'm just wondering if that flag day is implicit
in this change, or if we can put it off awhile longer.
regards, tom lane
Tom Lane writes: > Peter Eisentraut <peter_e@gmx.net> writes: > >> Peter, can you give a little sample of how an elog() call would look in > >> the new system? Thanks. > > > No change. > > Wouldn't there need to be changes in the %-escape usage in elog message > strings? No, for the programmer nothing changes. Are you referring to the possibility that the parameters need to appear in a different order in the translated message? This can be handled if the translator uses the %1$s style place holder in the translated string. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Tom Lane writes: > Are you planning to tackle any of the other elog-related stuff that's > been discussed in the past? (Automatic file/linenumber information, > relabeling the set of severity codes, that sort of thing?) Planning... I don't think I'm interested in the file/line information, given the cruftyness it would require. I can find that information with find | xargs grep just fine. Error codes are high on my agenda, but the specification still needs to be finalized. > Sooner or later we're going to have to bite the bullet and edit every > elog instance in the system. I don't think I want to do that. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter