Mark class_descr strings for translation

On Fri, Jul 3, 2026 at 2:37 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:

Hello,

While working on the translation, I encountered the following message.

pg_depend.c:809

if (!HeapTupleIsValid(tuple))
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("referenced %s was concurrently dropped",
get_object_class_descr(classId))));

As you can see, it is a user-facing message, which embeds the return
value from get_object_class_descr(), which returns
ObjectPropertyType.class_descr, which is described as "for internal
error messages" in objectaddress.c.

As a result, the resulting message in Japanese becomes rather
unnatural.

参照先の foreign-data wrapper は並行して削除されました

The attached patch marks the class_descr strings for translation, so
that the message can be translated. I'm not entirely sure whether this
is the right direction, but since class_descr is already used in
messages intended to be read by humans, even if they are not
necessarily user-facing, it seems reasonable to me.

+1 on the direction. The mechanism is right: since the strings live in
the static ObjectProperty[] array, xgettext can't pick them up at the
_() call site, so they have to be marked with gettext_noop() at the
array and translated with _() where they're consumed. Both halves of
the patch are needed, and they're paired correctly.

(FWIW the patch as attached has CRLF line endings, so it doesn't apply
with a plain git apply -- only with --ignore-whitespace. Probably a
mail-transport artifact; a resend with LF endings would help whoever
applies it.)

With that change, the message above becomes:

参照先の外部データラッパは並行して削除されました

One concern I have is that this may be somewhat easy to overlook,
since it requires remembering to wrap the return value in _() rather
than translating a string literal. That said, I don't expect this
pattern to be used very often, so I don't think it is a significant
problem.

By the way, I also noticed that we have two spellings, "foreign-data
wrapper" and "foreign data wrapper". I looked through the
documentation for the canonical spelling, but found both spellings
used on the same page, so I couldn't determine which one is preferred.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

--
Regards,
Ewan Young

On 2026-Jul-03, Kyotaro Horiguchi wrote:

diff --git a/src/backend/catalog/pg_depend.c b/src/backend/catalog/pg_depend.c
index 9a7a401aced..0d28d34412d 100644
--- a/src/backend/catalog/pg_depend.c
+++ b/src/backend/catalog/pg_depend.c
@@ -810,7 +810,7 @@ dependencyLockAndCheckObject(Oid classId, Oid objectId)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("referenced %s was concurrently dropped",
-							get_object_class_descr(classId))));
+							_(get_object_class_descr(classId)))));

I agree with the patch idea in general, but I'm not sure that this
string is really adequate. For instance, with this string we cannot
make "referenced" and "dropped" in the right gender declension depending
on the object type, and that will make the message look weird in some
languages -- specifically in Spanish but I'm guessing it can be a
problem in others as well.
"rol referenciado fue borrado concurrentemente"
"tabla referenciada fue borrada concurrentemente"
and so on.
(Most object types are feminine, but at least "role" and "operator" are
masculine.)

I propose we make this
"referenced object of type \"%s\" was concurrently dropped"

so that the declension of "referenced" and "dropped" refer to the gender
of the word "object". We'd no longer have a problem there:
"el objeto referenciado de tipo "tabla" fue borrado concurrentemente"
This reads a bit odd, but we no longer have a grammatical gender problem
there.

(We could leave out the quote marks, perhaps.)

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

On 07.07.26 13:51, Álvaro Herrera wrote:

On 2026-Jul-03, Kyotaro Horiguchi wrote:

diff --git a/src/backend/catalog/pg_depend.c b/src/backend/catalog/pg_depend.c
index 9a7a401aced..0d28d34412d 100644
--- a/src/backend/catalog/pg_depend.c
+++ b/src/backend/catalog/pg_depend.c
@@ -810,7 +810,7 @@ dependencyLockAndCheckObject(Oid classId, Oid objectId)
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("referenced %s was concurrently dropped",
-							get_object_class_descr(classId))));
+							_(get_object_class_descr(classId)))));

I agree with the patch idea in general, but I'm not sure that this
string is really adequate. For instance, with this string we cannot
make "referenced" and "dropped" in the right gender declension depending
on the object type, and that will make the message look weird in some
languages -- specifically in Spanish but I'm guessing it can be a
problem in others as well.
"rol referenciado fue borrado concurrentemente"
"tabla referenciada fue borrada concurrentemente"
and so on.
(Most object types are feminine, but at least "role" and "operator" are
masculine.)

I propose we make this
"referenced object of type \"%s\" was concurrently dropped"

so that the declension of "referenced" and "dropped" refer to the gender
of the word "object". We'd no longer have a problem there:
"el objeto referenciado de tipo "tabla" fue borrado concurrentemente"
This reads a bit odd, but we no longer have a grammatical gender problem
there.

(We could leave out the quote marks, perhaps.)

The class_descr is meant for internal messages only, for the reasons you
describe. The fact that there is now a non-internal message that uses
it is a bug and that should be fixed at that caller.

When I was working on generating the ObjectProperty tables
automatically, I was working toward getting rid of class_descr
altogether, because it's mostly not useful. (For internal error
messages, you might as well just print the actual catalog name.) I
don't think we should be working toward making this facility more
attractive now.

On 2026-Jul-07, Peter Eisentraut wrote:

The class_descr is meant for internal messages only, for the reasons you
describe. The fact that there is now a non-internal message that uses it is
a bug and that should be fixed at that caller.

Ummm, okay, but I'm not really looking forward to having two dozen
additional messages to translate that only differ in the object type.

I'll stand by to see what other ideas we can come up with, then :-)

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

At Tue, 7 Jul 2026 18:50:27 +0200, Álvaro Herrera <alvherre@kurilemu.de> wrote in

"rol referenciado fue borrado concurrentemente"
"tabla referenciada fue borrada concurrentemente"

Ah, I hadn't considered that.

On 2026-Jul-07, Peter Eisentraut wrote:

The class_descr is meant for internal messages only, for the reasons you
describe. The fact that there is now a non-internal message that uses it is
a bug and that should be fixed at that caller.

Ummm, okay, but I'm not really looking forward to having two dozen
additional messages to translate that only differ in the object type.

I'll stand by to see what other ideas we can come up with, then :-)

+1 from me.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center