At Mon, 10 Jul 2023 09:04:42 +0800, Japin Li <japinli@hotmail.com> wrote in
>
> On Sat, 08 Jul 2023 at 12:48, Michael Paquier <michael@paquier.xyz> wrote:
> > On Fri, Jul 07, 2023 at 07:23:47PM +0800, Japin Li wrote:
> >> + appendStringInfoString(&errhint, "\"stderr\"");
> >> +#ifdef HAVE_SYSLOG
> >> + appendStringInfoString(&errhint, ", \"syslog\"");
> >> +#endif
> >> +#ifdef WIN32
> >> + appendStringInfoString(&errhint, ", \"eventlog\"");
> >> +#endif
> >> + appendStringInfoString(&errhint, ", \"csvlog\", and \"jsonlog\"");
> >
> > Hmm. Is that OK as a translatable string?
>
>
> Sorry for the late reply! I'm not sure. How can I know whether it is translatable?
At the very least, we can't generate comma-separated lists
programatically because punctuation marks vary across languages.
One potential approach could involve defining the message for every
potential combination, in full length.
Honestly, I'm not sold on the idea that we need to exhaust ourselves
providing an exhaustive list of usable keywords for users here. I
believe that it is unlikely that these keywords will be used in
different combinations each time without looking at the
documentation. On top of that, consider "csvlog" as an example, -- it
doesn't work as expected if logging_collector is off. Although this is
documented, we don't give any warnings at startup. This seems like a
bigger issue than the unusable keywords. (I don't mean to suggest to
fix this, as usual.)
In short, I think a simple message like '"xxx" cannot be used in this
build' should suffice for keywords defined but unusable, and we should
stick with "unknown" for the undefined ones.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center