more i18n/l10n issues

On Sun, Sep 28, 2003 at 03:36:50PM -0400, Alvaro Herrera wrote:

Now for something completely different:

Oh, there's another thing about the --help-config option. This option
includes an, er, option to display the items that belong to a given
group. So you could say

/tmp/pgsql-es/bin/postgres --help-config -g 'Security'

and the list of parameters that belong to a group that has the word
Security on it would be displayed.

However, the -l option lists the groups with the translated names, and
of course those names do not match on -g specification.

This little patch allows both versions to match, translated and
untranslated.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Crear es tan dif�cil como ser libre" (Elsa Triolet)

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

Now for something completely different:

The postmaster executable shows --help display perfectly localized.
However I just noted that postgres --help output (the standalone
backend) does not; is it not i18n'ed, or is some sort of missetup?

postgres.c's usage() isn't localized. Dunno whether it should be or
not, given that we don't normally expect users to invoke it.

However, if I try postgres --help-config the localized display is shown,
but postmaster --help-config says

$ LC_MESSAGES=C /tmp/pgsql-es/bin/postmaster --help-config
FATAL: --help-config requires a value

--help-config is only a postgres option. We could possibly make it a
postmaster option too, but I'm not sure there's any need for it.

regards, tom lane

Alvaro Herrera writes:

Oh, there's another thing about the --help-config option. This option
includes an, er, option to display the items that belong to a given
group. So you could say

/tmp/pgsql-es/bin/postgres --help-config -g 'Security'

and the list of parameters that belong to a group that has the word
Security on it would be displayed.

However, the -l option lists the groups with the translated names, and
of course those names do not match on -g specification.

I'm quite unhappy about the --help-config option. It was developed
without discussion, it was installed hastily, we don't have any
information about that interactive configuration application it's supposed
to target, it's not documented, it's full of unfinished business, it
certainly doesn't make the code easier to maintain because all the
documenation is duplicated, but not one-to-one. At this point, I wouldn't
spend a lot of time trying to make sense of it. We can revisit it again
in the next release and investigate how we can eliminate the duplication
of effort between the documentation and the code.

This little patch allows both versions to match, translated and
untranslated.

That doesn't make much sense to me. It might be that a translated word is
equal to an English word but has a different meaning. It's also weird
that you cannot search for a complete word, e.g. "syslog", it's going to
print out all the parameters that contain "syslog". Again, I don't think
we should worry about that now or we'll end up spending too much time on
this.

--
Peter Eisentraut peter_e@gmx.net

On Mon, Sep 29, 2003 at 12:27:01AM +0200, Peter Eisentraut wrote:

Alvaro Herrera writes:

[fixes for --help-config]

I'm quite unhappy about the --help-config option. It was developed
without discussion, it was installed hastily, we don't have any
information about that interactive configuration application it's supposed
to target, it's not documented, it's full of unfinished business, it
certainly doesn't make the code easier to maintain because all the
documenation is duplicated, but not one-to-one. At this point, I wouldn't
spend a lot of time trying to make sense of it.

If you put it that way :-) I'll leave it alone. I hope it can be
enhanced in the next release. I'm not sure of it usefulness anyway;
the documentation seems good enough.

This little patch allows both versions to match, translated and
untranslated.

That doesn't make much sense to me. It might be that a translated word is
equal to an English word but has a different meaning.

You are probably right. In this case may I suggest sticking the
gettext() on top of the first parameter to strstr(), so only translated
versions are found? This makes for at least moderately sane behavior.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Y una voz del caos me habl� y me dijo
"Sonr�e y s� feliz, podr�a ser peor".
Y sonre�. Y fui feliz.
Y fue peor.

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

If you put it that way :-) I'll leave it alone. I hope it can be
enhanced in the next release. I'm not sure of it usefulness anyway;
the documentation seems good enough.

Some guys at Red Hat wanted it to support an admin tool that should see
the light of day Real Soon Now. Peter's right that it could be improved
though; in particular I would not care to defend its i18n behavior.
I've left it undocumented partly because I figure we'll be changing it.

regards, tom lane

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 29 September 2003 01:28
To: Alvaro Herrera
Cc: Peter Eisentraut; Hackers
Subject: Re: [HACKERS] more i18n/l10n issues

Alvaro Herrera <alvherre@dcc.uchile.cl> writes:

If you put it that way :-) I'll leave it alone. I hope it can be
enhanced in the next release. I'm not sure of it

usefulness anyway;

the documentation seems good enough.

Some guys at Red Hat wanted it to support an admin tool that
should see the light of day Real Soon Now. Peter's right
that it could be improved though; in particular I would not
care to defend its i18n behavior. I've left it undocumented
partly because I figure we'll be changing it.

Hi Guys,

I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth & nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaster without any discussion? I
realise they pay the wages of at least one of the developers many of us
depend on, but surely they should have to justify their modifications as
the rest of us do?

Regards, Dave.

Dave Page writes:

I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth & nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaster without any discussion?

It was not a nice thing to do.

Could whoever is responsible for this admin tool at Red Hat please specify
exactly what data they need out of this interface, so we have a chance to
make the interface a little more future-proof now and possibly remove some
of the unneeded clutter that is giving translators problems? Surely that
would be in everyone's interest, because if we're already set on changing
the feature again pretty soon, it won't do that admin tool much good.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Dave Page writes:

I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth & nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaster without any discussion?

It was not a nice thing to do.

Could whoever is responsible for this admin tool at Red Hat please specify
exactly what data they need out of this interface, so we have a chance to
make the interface a little more future-proof now and possibly remove some
of the unneeded clutter that is giving translators problems? Surely that
would be in everyone's interest, because if we're already set on changing
the feature again pretty soon, it won't do that admin tool much good.

I'm just wondering what this new admin tools is about, what's so
different about it compared to existing ones making the re-invention of
the wheel necessary...

Regards,
Andreas

Peter Eisentraut <peter_e@gmx.net> writes:

Dave Page writes:

I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth & nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaster without any discussion?

It was not a nice thing to do.

Gimme a break, guys. There *was* discussion, eg here,
http://archives.postgresql.org/pgsql-hackers/2003-06/msg01092.php
and the patch was posted for review, see this thread:
http://archives.postgresql.org/pgsql-patches/2003-06/msg00420.php

I'll admit that I applied the patch with more than usual speed, but that
was because we were right up against our self-imposed feature freeze
deadline for 7.4, and I didn't see any big objections. The biggest
gripe left over at the end of the above-mentioned patches thread was that
the message texts were unpolished, but as even Peter agreed, that could
be fixed later. So MHO is let's fix them now.

Could whoever is responsible for this admin tool at Red Hat please specify
exactly what data they need out of this interface, so we have a chance to
make the interface a little more future-proof now and possibly remove some
of the unneeded clutter that is giving translators problems?

The point was to allow a GUI utility to be built that would help in
editing postgresql.conf. It couldn't assume the postmaster is already
running, so just extending the pg_config view wouldn't answer, and
duplicating knowledge of all the GUC variables in a separate tool
would have created maintenance headaches. I would like to think that
the patch would eventually allow us to generate postgresql.conf.sample
automatically from the guc.c tables, and thereby reduce the number of
files to maintain, but that didn't get done yet. The reason for having
both "long" and "short" descriptions of the variables was that I foresaw
the "short" versions as becoming the per-line comments in
postgresql.conf. The "long" descriptions were what the GUI tool wants.

regards, tom lane

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 29 September 2003 15:23
To: Peter Eisentraut
Cc: Dave Page; Alvaro Herrera; Hackers
Subject: Re: [HACKERS] more i18n/l10n issues

Peter Eisentraut <peter_e@gmx.net> writes:

Dave Page writes:

I find this a little worrying because if we want a feature

or tweak

for pgAdmin we usually have to fight tooth & nail to

justify getting

it committed (which is not a bad thing), however 'some guys at Red
Hat' are getting switches added to the postmaster without any
discussion?

It was not a nice thing to do.

Gimme a break, guys. There *was* discussion, eg here,
http://archives.postgresql.org/pgsql-hackers/2003-06/msg01092.php
and the patch was posted for review, see this thread:
http://archives.postgresql.org/pgsql-patches/2003-06/msg00420.php

My apologes - I was basing my comments on someone else's assertion that
there was no discussion.

Regards, Dave.

Should we allow SHOW ALL to show these variable descriptions?

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

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Dave Page writes:

I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth & nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaster without any discussion?

It was not a nice thing to do.

Gimme a break, guys. There *was* discussion, eg here,
http://archives.postgresql.org/pgsql-hackers/2003-06/msg01092.php
and the patch was posted for review, see this thread:
http://archives.postgresql.org/pgsql-patches/2003-06/msg00420.php

I'll admit that I applied the patch with more than usual speed, but that
was because we were right up against our self-imposed feature freeze
deadline for 7.4, and I didn't see any big objections. The biggest
gripe left over at the end of the above-mentioned patches thread was that
the message texts were unpolished, but as even Peter agreed, that could
be fixed later. So MHO is let's fix them now.

Could whoever is responsible for this admin tool at Red Hat please specify
exactly what data they need out of this interface, so we have a chance to
make the interface a little more future-proof now and possibly remove some
of the unneeded clutter that is giving translators problems?

The point was to allow a GUI utility to be built that would help in
editing postgresql.conf. It couldn't assume the postmaster is already
running, so just extending the pg_config view wouldn't answer, and
duplicating knowledge of all the GUC variables in a separate tool
would have created maintenance headaches. I would like to think that
the patch would eventually allow us to generate postgresql.conf.sample
automatically from the guc.c tables, and thereby reduce the number of
files to maintain, but that didn't get done yet. The reason for having
both "long" and "short" descriptions of the variables was that I foresaw
the "short" versions as becoming the per-line comments in
postgresql.conf. The "long" descriptions were what the GUI tool wants.

regards, tom lane

---------------------------(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) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

And maybe show the descriptions in pg_settings too?

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

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Dave Page writes:

I find this a little worrying because if we want a feature or tweak for
pgAdmin we usually have to fight tooth & nail to justify getting it
committed (which is not a bad thing), however 'some guys at Red Hat' are
getting switches added to the postmaster without any discussion?

It was not a nice thing to do.

Gimme a break, guys. There *was* discussion, eg here,
http://archives.postgresql.org/pgsql-hackers/2003-06/msg01092.php
and the patch was posted for review, see this thread:
http://archives.postgresql.org/pgsql-patches/2003-06/msg00420.php

I'll admit that I applied the patch with more than usual speed, but that
was because we were right up against our self-imposed feature freeze
deadline for 7.4, and I didn't see any big objections. The biggest
gripe left over at the end of the above-mentioned patches thread was that
the message texts were unpolished, but as even Peter agreed, that could
be fixed later. So MHO is let's fix them now.

Could whoever is responsible for this admin tool at Red Hat please specify
exactly what data they need out of this interface, so we have a chance to
make the interface a little more future-proof now and possibly remove some
of the unneeded clutter that is giving translators problems?

The point was to allow a GUI utility to be built that would help in
editing postgresql.conf. It couldn't assume the postmaster is already
running, so just extending the pg_config view wouldn't answer, and
duplicating knowledge of all the GUC variables in a separate tool
would have created maintenance headaches. I would like to think that
the patch would eventually allow us to generate postgresql.conf.sample
automatically from the guc.c tables, and thereby reduce the number of
files to maintain, but that didn't get done yet. The reason for having
both "long" and "short" descriptions of the variables was that I foresaw
the "short" versions as becoming the per-line comments in
postgresql.conf. The "long" descriptions were what the GUI tool wants.

regards, tom lane

---------------------------(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) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

The point was to allow a GUI utility to be built that would help in
editing postgresql.conf. It couldn't assume the postmaster is already
running, so just extending the pg_config view wouldn't answer, and
duplicating knowledge of all the GUC variables in a separate tool
would have created maintenance headaches. I would like to think that
the patch would eventually allow us to generate postgresql.conf.sample
automatically from the guc.c tables, and thereby reduce the number of
files to maintain, but that didn't get done yet. The reason for having
both "long" and "short" descriptions of the variables was that I foresaw
the "short" versions as becoming the per-line comments in
postgresql.conf. The "long" descriptions were what the GUI tool wants.

I have been wondering if moving to XML for config files might be a good
idea - and if there are going to be GUIs that write them that gives some
more impetus to the idea.

This occurred to me as I was writing the token replacement stuff for
initdb.c, and I realised how fragile it was - a misplaced space and you
are hosed.

Or would it be overkill?

cheers

andrew

Bruce Momjian <pgman@candle.pha.pa.us> writes:

And maybe show the descriptions in pg_settings too?

There was discussion of doing that, but it didn't get done in time
(and it's too late now for 7.4 unless you want an initdb). I wouldn't
mind putting it on TODO for 7.5.

I think the SHOW ALL output should be kept to one line per variable,
which'd preclude adding "long" descriptions, but we could think about
adding the "short" ones. (I have no similar worry about pg_settings
because one can easily choose which columns one looks at.)

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

And maybe show the descriptions in pg_settings too?

There was discussion of doing that, but it didn't get done in time
(and it's too late now for 7.4 unless you want an initdb). I wouldn't
mind putting it on TODO for 7.5.

Bruce, you can put my name next to that TODO.

I think the SHOW ALL output should be kept to one line per variable,
which'd preclude adding "long" descriptions, but we could think about
adding the "short" ones. (I have no similar worry about pg_settings
because one can easily choose which columns one looks at.)

This one too.

Joe

Joe Conway wrote:

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

And maybe show the descriptions in pg_settings too?

There was discussion of doing that, but it didn't get done in time
(and it's too late now for 7.4 unless you want an initdb). I wouldn't
mind putting it on TODO for 7.5.

Bruce, you can put my name next to that TODO.

I think the SHOW ALL output should be kept to one line per variable,
which'd preclude adding "long" descriptions, but we could think about
adding the "short" ones. (I have no similar worry about pg_settings
because one can easily choose which columns one looks at.)

This one too.

Added to TODO:

* Have SHOW ALL and pg_settings show descriptions for server-side
variables(Joe)

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

Alvaro Herrera writes:

#: utils/misc/guc.c:647
msgid "collect statistics about executing commands"

Is this really "statistics" about the executing commands?

Looks like it.

#: utils/misc/guc.c:892
msgid ""
"The number must be a positive integer. If 0 is specified then effort * "
"log2(poolsize) is used"

Is it missing the final dot?

Added.

#: commands/tablecmds.c:2029
msgid "column \"%s\" is in a primary key"

So, is it in A primary key, or THE primary key?

The message doesn't mention a table, so "the primary key" would just stand
without reference. I think both have merits.

#: commands/tablecmds.c:4093
msgid "relation \"%s\" already has a TOAST table"

This is the one place where I found it could be table instead of
relation, because it's checked explicitly in the code.

True. I've also changed a few messages around that one.

The postmaster executable shows --help display perfectly localized.
However I just noted that postgres --help output (the standalone
backend) does not; is it not i18n'ed, or is some sort of missetup?

It was not set up for gettext, but it is now.

--
Peter Eisentraut peter_e@gmx.net

Andrew Dunstan <andrew@dunslane.net> writes:

I have been wondering if moving to XML for config files might be a good
idea - and if there are going to be GUIs that write them that gives some
more impetus to the idea.

Or would it be overkill?

Seems like overkill. What would it buy us, other than making it a lot
more painful to edit the config files manually?

regards, tom lane

Andrew Dunstan writes:

I have been wondering if moving to XML for config files might be a good
idea - and if there are going to be GUIs that write them that gives some
more impetus to the idea.

What I would like to see done is keeping the GUC data, that is, the name,
the properties, and the description, in some certralized store and
generate code and documentation from that. It could be done with XML,
SGML, m4 -- I don't care.

--
Peter Eisentraut peter_e@gmx.net