| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Serguei Mokhov" <mokhov(at)cs(dot)concordia(dot)ca> |
| Cc: | "Manfred Koizar" <mkoi-pg(at)aon(dot)at>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net> |
| Subject: | Re: pg_dump.options.diff |
| Date: | 2003-01-02 18:58:27 |
| Message-ID: | 1617.1041533907@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"Serguei Mokhov" <mokhov(at)cs(dot)concordia(dot)ca> writes:
> Looks good to me, but there is still a little inconvenience
> of multiline option descriptions, and the above won't handle
> it nicely.
True, a multiline description would have to look like
xo(_("-f, --file=FILENAME "),
_("-f FILENAME "),
_("output file name\n"
" more description"));
Which is not great, but it doesn't seem completely unworkable either.
And the translator can still adjust the column spacing without any
code changes.
> may be a whole generic option-formatting routine
> should be created; one for all the tools? ;-)
> Similar to explain_option() of Manfred,
> which will handle the mulitline, padding, and other stuff?
> (am being half serious here, but it could be an "option")
The trouble I see there is that the layout --- in particular the column
width --- would be embedded in such a routine and not alterable by
simply replacing message texts.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | snpe | 2003-01-02 19:07:56 | Re: [HACKERS] Cast your vote ... |
| Previous Message | Rod Taylor | 2003-01-02 18:50:51 | Re: Bug in pg_get_constraintdef (for deferrable |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-01-02 19:33:31 | Re: NOT NULL Fixes |
| Previous Message | Serguei Mokhov | 2003-01-02 18:39:48 | ru: translation updates -- backend and libpq |