public inbox for [email protected]help / color / mirror / Atom feed
Mark class_descr strings for translation 6+ messages / 4 participants [nested] [flat]
* Mark class_descr strings for translation @ 2026-07-03 06:37 Kyotaro Horiguchi <[email protected]> 0 siblings, 2 replies; 6+ messages in thread From: Kyotaro Horiguchi @ 2026-07-03 06:37 UTC (permalink / raw) To: [email protected] 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 ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Mark class_descr strings for translation @ 2026-07-03 08:19 Ewan Young <[email protected]> parent: Kyotaro Horiguchi <[email protected]> 1 sibling, 0 replies; 6+ messages in thread From: Ewan Young @ 2026-07-03 08:19 UTC (permalink / raw) To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected] On Fri, Jul 3, 2026 at 2:37 PM Kyotaro Horiguchi <[email protected]> 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 ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Mark class_descr strings for translation @ 2026-07-07 11:51 Álvaro Herrera <[email protected]> parent: Kyotaro Horiguchi <[email protected]> 1 sibling, 1 reply; 6+ messages in thread From: Álvaro Herrera @ 2026-07-07 11:51 UTC (permalink / raw) To: Kyotaro Horiguchi <[email protected]>; +Cc: [email protected] 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/ ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Mark class_descr strings for translation @ 2026-07-07 12:39 Peter Eisentraut <[email protected]> parent: Álvaro Herrera <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Peter Eisentraut @ 2026-07-07 12:39 UTC (permalink / raw) To: Álvaro Herrera <[email protected]>; Kyotaro Horiguchi <[email protected]>; +Cc: [email protected] 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. ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Mark class_descr strings for translation @ 2026-07-07 16:50 Álvaro Herrera <[email protected]> parent: Peter Eisentraut <[email protected]> 0 siblings, 1 reply; 6+ messages in thread From: Álvaro Herrera @ 2026-07-07 16:50 UTC (permalink / raw) To: Peter Eisentraut <[email protected]>; +Cc: Kyotaro Horiguchi <[email protected]>; [email protected] 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/ ^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Mark class_descr strings for translation @ 2026-07-08 07:00 Kyotaro Horiguchi <[email protected]> parent: Álvaro Herrera <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Kyotaro Horiguchi @ 2026-07-08 07:00 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; [email protected] At Tue, 7 Jul 2026 18:50:27 +0200, Álvaro Herrera <[email protected]> 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 ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-07-08 07:00 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-03 06:37 Mark class_descr strings for translation Kyotaro Horiguchi <[email protected]> 2026-07-03 08:19 ` Ewan Young <[email protected]> 2026-07-07 11:51 ` Álvaro Herrera <[email protected]> 2026-07-07 12:39 ` Peter Eisentraut <[email protected]> 2026-07-07 16:50 ` Álvaro Herrera <[email protected]> 2026-07-08 07:00 ` Kyotaro Horiguchi <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox