Re: more i18n/l10n issues

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Hackers <pgsql-hackers(at)postgresql(dot)org>, Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: more i18n/l10n issues
Date: 2003-10-12 21:59:37
Message-ID: Pine.LNX.4.44.0310122343470.27310-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> -m and -M
>
> The utility we designed and possibly any other that wants to process the
> output will find it easier to process a more regularly formed output
> instead of one that was embellished for human viewing. The reason for
> having one with and one without headings is that in some circumstances
> the utility designer may want to use the headers to make her/his table
> headers and others may prefer to have pre-defined table headers. The
> guy who wrote our window used -M while I would have liked him to use -m
> (but -M was faster to do and he was on a hurry).

But the headers output by -m are not useful for human viewing. Also, we
don't have any ideas what "utility designers" may want, we only know what
your tool wants. So unless you need both -m and -M, I propose that we
remove the option with headers and make -m output the list without
headers.

> -G
>
> The -G (using the Unix convention of negating things with capital
> letters) is what we use. This option is probably what will be used for
> generating the postgresql.conf default file automatically.
> As we were not adding a facility for our use but for other tool
> developers as well and we thought that some may want to process it in
> different ways we made it an option. We don't object making it a side
> effect of using -m or -M.

If you aren't using the group-by-category option, then I propose that we
remove it. We haven't heard any proposals about generating
postgresql.conf, or about any other tool developers, so it's pure fantasy
at this point. I don't like comitting to features based on fantasies.

> > Also, --help-config 'foo' outputs all parameters matching 'foo' somewhere
> > in the string, not only 'foo'. I think that is a misdesign.
> >
>
> It works like locate (or slocate). I believe some other Unix utilities
> do the same. Unix commands are mostly 'misdesigned' I admit.

If I enter "ls foo", it shows me only foo. If I enter "rm foo", it only
removes foo. Works perfectly well. If you want a wildcarding behavior,
it should be explicit. Also note that locate provides a way to make the
search string anchored, whereas your design does not. How does you tool
work if the user wants to take a look at the option "geqo"? It will then
show all options that contain "geqo". There is no way to look at only one
option and that seems wrong. So I propose that the match-anywhere
behavior be removed.

> > Also, in many cases where there is a long description, it was copied out
> > of the documentation, with the short description being the first sentence
> > and the long description being the rest. The result is that in some cases
> > the long description doesn't make sense in isolation. I would like that
> > to be clarified.
> >
>
> This is a GNU trick to avoid repeating the same text (from the short
> description) in the long description. I believe it is from Richard
> Stallman's time. It is used in several GNU tools, for instance the GNU
> GDB debugger (which uses just one field and makes the first sentence or
> line the short description). The idea is that the long description is
> formed by the concatenation of the two.

If you want to pull tricks like that, you need to tell us about it.
Right now, some of that doesn't work anymore, because some of the short
and long descriptions had to be reworked to make sense in isolation.

I think what I would like to do for the next release is to rip out all of
this and store the information about the configuration parameters in some
external file and generate code, documentation, and help from that. Then
we can have a short and a long description without any tricks.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2003-10-12 22:12:19 Re: http://www.pgsql.com/register/submit.php
Previous Message Marc G. Fournier 2003-10-12 19:12:36 NOTICE: Servers down on Monday, Oct 13th