Some more comments:

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

Is this really "statistics" about the executing commands?


#: 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?


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

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


#: 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.  I haven't looked
very hard though, there may be others, but I've seen the last message
cleanups have changed some of them.


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?

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

So, for some things postmaster is localized, but others are not
supported; and for some things postgres is localized, but for others
it's not.  Is this some sort of planned behavior, inconsistency, or
plain oversight?

Thanks,

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Endurecerse, pero jamï¿½s perder la ternura" (E. Guevara)

Sun, 28 Sep 2003 15:36:50 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
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)
Sun, 28 Sep 2003 16:26:57 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: more i18n/l10n issues
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

Sun, 28 Sep 2003 16:34:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more i18n/l10n issues 
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


Mon, 29 Sep 2003 00:27:01 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: more i18n/l10n issues
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.

Sun, 28 Sep 2003 19:43:36 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: 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.

			regards, tom lane

Sun, 28 Sep 2003 20:27:55 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more i18n/l10n issues 
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


Mon, 29 Sep 2003 19:53:05 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: more i18n/l10n issues