Subject: translator comments for GUC descriptions useful?

From: Peter Eisentraut <[email-masked]>
Date: Fri, 7 Nov 2025 09:53:38 +0100

Hi all,

I've done some work recently in the source code to make the GUC C 
structs automatically generated.  That now allows changing the output 
format more easily.

One random idea I had is that we could automatically generate 
"translator" comments on the short and long description strings of GUC 
parameters.  So the PO entries could then look like this:

#. translator: GUC huge_pages_status short description
#: utils/misc/guc_tables.c:5020
msgid "Indicates the status of huge pages."
msgstr ""

(and analogously for the long description).

This would be trivial to implement now (see below for an example).

Would this be useful?

I suppose the only possible disadvantage is that it would use more 
vertical space.

(Any related ideas while we're here?)

diff --git a/src/backend/utils/misc/gen_guc_tables.pl 
b/src/backend/utils/misc/gen_guc_tables.pl
index 601c34ec30b..25aa98debed 100644
--- a/src/backend/utils/misc/gen_guc_tables.pl
+++ b/src/backend/utils/misc/gen_guc_tables.pl
@@ -62,6 +62,7 @@ sub print_table
         printf $ofh "\t\t.name = %s,\n", dquote($entry->{name});
         printf $ofh "\t\t.context = %s,\n", $entry->{context};
         printf $ofh "\t\t.group = %s,\n", $entry->{group};
+       printf $ofh "\t\t/* translator: GUC %s short description */\n", 
$entry->{name};
         printf $ofh "\t\t.short_desc = gettext_noop(%s),\n",
           dquote($entry->{short_desc});
         printf $ofh "\t\t.long_desc = gettext_noop(%s),\n",

---

From: "Pavlo Golub" <[email-masked]>
Date: Fri, 07 Nov 2025 09:16:42 +0000

Hi!
>Hi all,
>
>I've done some work recently in the source code to make the GUC C structs automatically generated.  That now allows changing the output format more easily.
>
>One random idea I had is that we could automatically generate "translator" comments on the short and long description strings of GUC parameters.  So the PO entries could then look like this:
>

The more context translator has, the better!

>
>
>I suppose the only possible disadvantage is that it would use more vertical space.
>
>diff --git a/src/backend/utils/misc/gen_guc_tables.pl b/src/backend/utils/misc/gen_guc_tables.pl
>+       printf $ofh "\t\t/* translator: GUC %s short description */\n", $entry->{name};

--
Hoc est vivere bis, vita posse priore frui.
Nullus est in vitae sensus, ipsa vera est sensus.

---

From: Álvaro Herrera <[email-masked]>
Date: Fri, 7 Nov 2025 10:57:23 +0100

On 2025-Nov-07, Peter Eisentraut wrote:

> One random idea I had is that we could automatically generate "translator"
> comments on the short and long description strings of GUC parameters.  So
> the PO entries could then look like this:
> 

I like this -- yes, please.

> I suppose the only possible disadvantage is that it would use more vertical

I don't think this is a problem.  Translators are likely using GUI
software (at least those that aren't using Vim or Emacs).

> (Any related ideas while we're here?)

Maybe extract each GUC name and grep all errmsg/errdetail/errhint
strings to make sure the name isn't used verbatim (but only via %s
expansion).  (Not really sure to what extent this idea is related to
yours, but it's what I got while looking at guc_parameters.dat.)

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/

---

From: SAS <[email-masked]>
Date: Wed, 12 Nov 2025 10:02:37 +0100

Hello,
Le 07/11/2025 à 09:53, Peter Eisentraut a écrit :
> Hi all,
>
> I've done some work recently in the source code to make the GUC C structs 
> automatically generated.  That now allows changing the output format more 
> easily.
>
> comments on the short and long description strings of GUC parameters.  So the 
> PO entries could then look like this:
>

I really like the idea.

(...)

Best,

-- 
Dr Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
+33 617 11 37 42

---

From: Peter Eisentraut <[email-masked]>
Date: Fri, 28 Nov 2025 16:18:49 +0100

> (and analogously for the long description).

I have committed this.  (It's only in the master branch right now, so it 
won't be active until the messages git repository is branched, usually 
in February.)