public inbox for [email protected]help / color / mirror / Atom feed
Get rid of translation strings that only contain punctuation 9+ messages / 5 participants [nested] [flat]
* Get rid of translation strings that only contain punctuation @ 2026-04-22 00:29 David Rowley <[email protected]> 0 siblings, 3 replies; 9+ messages in thread From: David Rowley @ 2026-04-22 00:29 UTC (permalink / raw) To: PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> (Follow-on work from [1]) We've got a few parts of the code that translate strings that contain only a single punctuation character. I'm not a translator, but I suspect that these would be tricky to deal with as such short strings could be used for various different things, and if the required translation was to differ between requirements, then you're out of luck. I looked at: git grep -A 1 "msgid \", \"" and I see French is the only translation to do anything different with the ", " string, and only in psql. src/bin/psql/po/fr.po:msgid ", " src/bin/psql/po/fr.po-msgstr " , " This is used for suffixing "unique" or "unique nulls not distinct". I adjusted the logic there to get rid of the short translation string. Quite a few are new to v19: fd366065e (AmitK), 48efefa6c (AmitK), 0fc33b005 (PeterE) The relation.c one is from v18: 8fcd80258 (AmitK) The describe.c one is from v15: 94aa7cc5f (PeterE) Should we get rid of these? David [1] https://postgr.es/m/CAApHDvohYOdrvhVxXzCJNX_GYMSWBfjTTtB6hgDauEtZ8Nar2A@mail.gmail.com Attachments: [application/octet-stream] get_rid_of_single_punctuation_char_translation_strings.patch (4.7K, 2-get_rid_of_single_punctuation_char_translation_strings.patch) download | inline diff: diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c index eec09ba1ded..e5ef0fdae7d 100644 --- a/src/backend/commands/tablecmds.c +++ b/src/backend/commands/tablecmds.c @@ -20588,8 +20588,8 @@ ATExecAttachPartition(List **wqueue, Relation rel, PartitionCmd *cmd, exceptpuboids = GetRelationExcludedPublications(RelationGetRelid(attachrel)); if (exceptpuboids != NIL) { - bool first = true; StringInfoData pubnames; + char *sep = ""; initStringInfo(&pubnames); @@ -20597,18 +20597,9 @@ ATExecAttachPartition(List **wqueue, Relation rel, PartitionCmd *cmd, { char *pubname = get_publication_name(pubid, false); - if (!first) - { - /* - * translator: This is a separator in a list of publication - * names. - */ - appendStringInfoString(&pubnames, _(", ")); - } - - first = false; - - appendStringInfo(&pubnames, _("\"%s\""), pubname); + appendStringInfoString(&pubnames, sep); + appendStringInfo(&pubnames, "\"%s\"", pubname); + sep = ", "; } ereport(ERROR, diff --git a/src/backend/replication/logical/conflict.c b/src/backend/replication/logical/conflict.c index 2887dfb7150..8adbb60af6d 100644 --- a/src/backend/replication/logical/conflict.c +++ b/src/backend/replication/logical/conflict.c @@ -195,7 +195,7 @@ static void append_tuple_value_detail(StringInfo buf, List *tuple_values, bool need_newline) { - bool first = true; + char *prefix = ": "; Assert(buf != NULL && tuple_values != NIL); @@ -209,31 +209,12 @@ append_tuple_value_detail(StringInfo buf, List *tuple_values, if (!tuple_value) continue; - if (first) - { - /* - * translator: The colon is used as a separator in conflict - * messages. The first part, built in the caller, describes what - * happened locally; the second part lists the conflicting keys - * and tuple data. - */ - appendStringInfoString(buf, _(": ")); - } - else - { - /* - * translator: This is a separator in a list of conflicting keys - * and tuple data. - */ - appendStringInfoString(buf, _(", ")); - } - + appendStringInfoString(buf, prefix); appendStringInfoString(buf, tuple_value); - first = false; + prefix = ", "; } - /* translator: This is the terminator of a conflict message */ - appendStringInfoString(buf, _(".")); + appendStringInfoChar(buf, '.'); if (need_newline) appendStringInfoChar(buf, '\n'); diff --git a/src/backend/replication/logical/relation.c b/src/backend/replication/logical/relation.c index 0b1d80b5b0f..edf2b671ebc 100644 --- a/src/backend/replication/logical/relation.c +++ b/src/backend/replication/logical/relation.c @@ -239,7 +239,7 @@ static char * logicalrep_get_attrs_str(LogicalRepRelation *remoterel, Bitmapset *atts) { StringInfoData attsbuf; - int attcnt = 0; + char *sep = ""; int i = -1; Assert(!bms_is_empty(atts)); @@ -248,12 +248,9 @@ logicalrep_get_attrs_str(LogicalRepRelation *remoterel, Bitmapset *atts) while ((i = bms_next_member(atts, i)) >= 0) { - attcnt++; - if (attcnt > 1) - /* translator: This is a separator in a list of entity names. */ - appendStringInfoString(&attsbuf, _(", ")); - - appendStringInfo(&attsbuf, _("\"%s\""), remoterel->attnames[i]); + appendStringInfoString(&attsbuf, sep); + appendStringInfo(&attsbuf, ("\"%s\""), remoterel->attnames[i]); + sep = ", "; } return attsbuf.data; diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c index c4c3fbc4fe3..d6c26149991 100644 --- a/src/backend/utils/misc/guc.c +++ b/src/backend/utils/misc/guc.c @@ -3168,18 +3168,8 @@ parse_and_validate_value(const struct config_generic *record, hintmsg = config_enum_get_options(conf, _("Available values: "), - - /* - * translator: This is the terminator of a list of entity - * names. - */ - _("."), - - /* - * translator: This is a separator in a list of entity - * names. - */ - _(", ")); + ".", + ", "); ereport(elevel, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), diff --git a/src/bin/psql/describe.c b/src/bin/psql/describe.c index dd1179ef927..850dffbf158 100644 --- a/src/bin/psql/describe.c +++ b/src/bin/psql/describe.c @@ -2504,10 +2504,10 @@ describeOneTableDetails(const char *schemaname, printfPQExpBuffer(&tmpbuf, _("primary key, ")); else if (strcmp(indisunique, "t") == 0) { - printfPQExpBuffer(&tmpbuf, _("unique")); if (strcmp(indnullsnotdistinct, "t") == 0) - appendPQExpBufferStr(&tmpbuf, _(" nulls not distinct")); - appendPQExpBufferStr(&tmpbuf, _(", ")); + appendPQExpBufferStr(&tmpbuf, _("unique nulls not distinct, ")); + else + printfPQExpBuffer(&tmpbuf, _("unique, ")); } else resetPQExpBuffer(&tmpbuf); ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-22 00:51 Tom Lane <[email protected]> parent: David Rowley <[email protected]> 2 siblings, 1 reply; 9+ messages in thread From: Tom Lane @ 2026-04-22 00:51 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> David Rowley <[email protected]> writes: > We've got a few parts of the code that translate strings that contain > only a single punctuation character. I'm not a translator, but I > suspect that these would be tricky to deal with as such short strings > could be used for various different things, and if the required > translation was to differ between requirements, then you're out of > luck. Yeah. I concur with your feeling that a separate translatable string containing just a punctuation mark is probably the Wrong Thing. But just removing the translation marker doesn't fix the problem. You need more extensive restructuring so that what needs to be translated is a coherent message. We previously discussed the append_tuple_value_detail case [1], and I opined that the right fix was to change things so that what that function produces is a string that doesn't need translation because it matches SQL syntax for a row constructor. It doesn't look like that's happened yet. regards, tom lane [1] https://www.postgresql.org/message-id/227279.1775956328%40sss.pgh.pa.us ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-22 01:17 Peter Smith <[email protected]> parent: David Rowley <[email protected]> 2 siblings, 1 reply; 9+ messages in thread From: Peter Smith @ 2026-04-22 01:17 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> On Wed, Apr 22, 2026 at 10:30 AM David Rowley <[email protected]> wrote: > > (Follow-on work from [1]) > > We've got a few parts of the code that translate strings that contain > only a single punctuation character. I'm not a translator, but I > suspect that these would be tricky to deal with as such short strings > could be used for various different things, and if the required > translation was to differ between requirements, then you're out of > luck. > > I looked at: git grep -A 1 "msgid \", \"" and I see French is the only > translation to do anything different with the ", " string, and only in > psql. > > src/bin/psql/po/fr.po:msgid ", " > src/bin/psql/po/fr.po-msgstr " , " > > This is used for suffixing "unique" or "unique nulls not distinct". I > adjusted the logic there to get rid of the short translation string. > > Quite a few are new to v19: fd366065e (AmitK), 48efefa6c (AmitK), > 0fc33b005 (PeterE) > The relation.c one is from v18: 8fcd80258 (AmitK) > The describe.c one is from v15: 94aa7cc5f (PeterE) > > Should we get rid of these? > This question overlaps with another thread of mine [1]. There, I was told that a punctuation double-quote (") *should* be translated. OTOH, I did not see why the comma separator (,) should be translated -- my patch did so only to be the same as existing code. ====== [1] https://www.postgresql.org/message-id/CAHut%2BPui7RaQ8OfJEVn2ry-ykjnGc%2B3ujsFmcHDFw9FsXw_tRw%40mail... Kind Regards, Peter Smith. Fujitsu Australia ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-22 01:31 Tom Lane <[email protected]> parent: Peter Smith <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Tom Lane @ 2026-04-22 01:31 UTC (permalink / raw) To: Peter Smith <[email protected]>; +Cc: David Rowley <[email protected]>; PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> Peter Smith <[email protected]> writes: > On Wed, Apr 22, 2026 at 10:30 AM David Rowley <[email protected]> wrote: >> Should we get rid of these? > This question overlaps with another thread of mine [1]. > There, I was told that a punctuation double-quote (") *should* be translated. It should be, but it *has to be translated as part of a coherent message*. As the examples in [1] show, several languages translate opening and closing double-quotes differently. So if you write _("\"") there is zero hope of that being usefully translatable. This all goes back to the translatability guideline about not constructing messages out of parts [2]. If you've got a single punctuation mark as a separate string, you are violating both the letter and the spirit of that guideline, and that has consequences for translatability. regards, tom lane [1] https://www.postgresql.org/message-id/CAHut%2BPui7RaQ8OfJEVn2ry-ykjnGc%2B3ujsFmcHDFw9FsXw_tRw%40mail... [2] https://www.postgresql.org/docs/devel/nls-programmer.html#NLS-GUIDELINES ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-22 02:20 Peter Smith <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Peter Smith @ 2026-04-22 02:20 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: David Rowley <[email protected]>; PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> On Wed, Apr 22, 2026 at 11:31 AM Tom Lane <[email protected]> wrote: > > Peter Smith <[email protected]> writes: > > On Wed, Apr 22, 2026 at 10:30 AM David Rowley <[email protected]> wrote: > >> Should we get rid of these? > > > This question overlaps with another thread of mine [1]. > > There, I was told that a punctuation double-quote (") *should* be translated. > > It should be, but it *has to be translated as part of a coherent > message*. As the examples in [1] show, several languages translate > opening and closing double-quotes differently. So if you write _("\"") > there is zero hope of that being usefully translatable. > > This all goes back to the translatability guideline about not > constructing messages out of parts [2]. If you've got a single > punctuation mark as a separate string, you are violating both the > letter and the spirit of that guideline, and that has consequences > for translatability. > > regards, tom lane > > [1] https://www.postgresql.org/message-id/CAHut%2BPui7RaQ8OfJEVn2ry-ykjnGc%2B3ujsFmcHDFw9FsXw_tRw%40mail... > [2] https://www.postgresql.org/docs/devel/nls-programmer.html#NLS-GUIDELINES To my knowledge, we aren't violating that guideline because our substituted parts aren't words of a sentence; they are quoted names in a list e.g. Case#1: publication "XXX" has a problem Case#2: the following publications have a problem: "XXX", "YYY", "ZZZ" ~~~ Case#1 is easy. "publication \"%s\" has a problem" The quotes are part of the message, so they get translated as normal. Case#2 is more fiddly. "the following publications have a problem: %s" The substituted quoted-name list is constructed at runtime, but still, we require those quotes to be translated so that quoted-names in cases #1 and #2 look the same. ====== Kind Regards, Peter Smith. Fujitsu Australia ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-22 02:32 Tom Lane <[email protected]> parent: Peter Smith <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Tom Lane @ 2026-04-22 02:32 UTC (permalink / raw) To: Peter Smith <[email protected]>; +Cc: David Rowley <[email protected]>; PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> Peter Smith <[email protected]> writes: > Case#1: publication "XXX" has a problem > Case#2: the following publications have a problem: "XXX", "YYY", "ZZZ" Entirely aside from the mechanics of producing the output, I am not sure I buy that emitting that is a desirable goal. It seems to be based on an English-centric notion that singular and indefinitely-many plural are the only two categories. This is incorrect (see the documentation for ngettext()). Is there a good reason not to output a separate message for each publication? If we need to throw an ereport(ERROR) covering them all, maybe list them in separate sentences in a DETAIL message. regards, tom lane ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-22 03:26 Peter Smith <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Peter Smith @ 2026-04-22 03:26 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: David Rowley <[email protected]>; PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> On Wed, Apr 22, 2026 at 12:32 PM Tom Lane <[email protected]> wrote: > > Peter Smith <[email protected]> writes: > > Case#1: publication "XXX" has a problem > > Case#2: the following publications have a problem: "XXX", "YYY", "ZZZ" > > Entirely aside from the mechanics of producing the output, > I am not sure I buy that emitting that is a desirable goal. > It seems to be based on an English-centric notion that singular > and indefinitely-many plural are the only two categories. > This is incorrect (see the documentation for ngettext()). > Those case#1 and case#2 were just illustrative. The real code is using `errmsg_plural` and `errdetail_plural`, so I think that makes it ok for languages that have multiple forms of "plural". ====== Kind Regards, Peter Smith. Fujitsu Australia ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-22 12:13 Amit Kapila <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Amit Kapila @ 2026-04-22 12:13 UTC (permalink / raw) To: Tom Lane <[email protected]>; +Cc: David Rowley <[email protected]>; PostgreSQL Developers <[email protected]>; Peter Eisentraut <[email protected]> On Wed, Apr 22, 2026 at 6:21 AM Tom Lane <[email protected]> wrote: > > We previously discussed the append_tuple_value_detail case [1], and > I opined that the right fix was to change things so that what that > function produces is a string that doesn't need translation because > it matches SQL syntax for a row constructor. It doesn't look like > that's happened yet. > I'll look into your suggestions. -- With Regards, Amit Kapila. ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Get rid of translation strings that only contain punctuation @ 2026-04-23 09:38 Álvaro Herrera <[email protected]> parent: David Rowley <[email protected]> 2 siblings, 0 replies; 9+ messages in thread From: Álvaro Herrera @ 2026-04-23 09:38 UTC (permalink / raw) To: David Rowley <[email protected]>; +Cc: PostgreSQL Developers <[email protected]>; Amit Kapila <[email protected]>; Peter Eisentraut <[email protected]> On 2026-Apr-22, David Rowley wrote: > We've got a few parts of the code that translate strings that contain > only a single punctuation character. I'm not a translator, but I > suspect that these would be tricky to deal with as such short strings > could be used for various different things, and if the required > translation was to differ between requirements, then you're out of > luck. Yeah. > I looked at: git grep -A 1 "msgid \", \"" and I see French is the only > translation to do anything different with the ", " string, and only in > psql. Japanese also uses different punctuation characters, so I don't think we should get rid of translating these characters. Instead we should do what Tom says and integrate these characters into a larger string. I showed one example in a nearby thread from Peter Smith [1], and I think a couple of the spots you're patching can be easily done in the same way. As for the one in guc.c, I think what we should do is change config_enum_get_options() to have an API similar to GetPublicationsStr: instead of receiving prefix, suffix and separator, we should tell that function that we're constructing a list to be used in as an SQL value (GetConfigOptionValues), or one to be displayed to the user (parse_and_validate_value); and have the function add the separators and other decoration as needed, using the same technique. (The other prefix "Available values: " can be added by the caller, I think, and maybe the braces also, not sure.) [1] https://postgr.es/m/[email protected] -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ ^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2026-04-23 09:38 UTC | newest] Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-04-22 00:29 Get rid of translation strings that only contain punctuation David Rowley <[email protected]> 2026-04-22 00:51 ` Tom Lane <[email protected]> 2026-04-22 12:13 ` Amit Kapila <[email protected]> 2026-04-22 01:17 ` Peter Smith <[email protected]> 2026-04-22 01:31 ` Tom Lane <[email protected]> 2026-04-22 02:20 ` Peter Smith <[email protected]> 2026-04-22 02:32 ` Tom Lane <[email protected]> 2026-04-22 03:26 ` Peter Smith <[email protected]> 2026-04-23 09:38 ` Álvaro Herrera <[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