Re: Mark class_descr strings for translation

On Fri, Jul 3, 2026 at 2:37 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)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