Thread

1. Mark class_descr strings for translation

   Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2026-07-03T06:37:42Z

   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.
   
   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
   

2. Re: Mark class_descr strings for translation

   Ewan Young <kdbase.hack@gmail.com> — 2026-07-03T08:19:18Z

   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
   
   
   
   

3. Re: Mark class_descr strings for translation

   Álvaro Herrera <alvherre@kurilemu.de> — 2026-07-07T11:51:51Z

   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/
   
   
   
   

4. Re: Mark class_descr strings for translation

   Peter Eisentraut <peter@eisentraut.org> — 2026-07-07T12:39:02Z

   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.
   
   
   
   
   

5. Re: Mark class_descr strings for translation

   Álvaro Herrera <alvherre@kurilemu.de> — 2026-07-07T16:50:27Z

   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/
   
   
   
   

6. Re: Mark class_descr strings for translation

   Kyotaro Horiguchi <horikyota.ntt@gmail.com> — 2026-07-08T07:00:52Z

   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