At Mon, 10 Jul 2023 09:04:42 +0800, Japin Li <japi...@hotmail.com> wrote in > > On Sat, 08 Jul 2023 at 12:48, Michael Paquier <mich...@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
